310. Иерархия бэклога
Когда я не работал в продуктовых IT-компаниях, я думал проблемы там от недостатка идей. Надо просто посоветовать и объяснить, как правильно сделать, и они сразу исправятся. Так думают многие пользователи, поэтому постоянно пишут предложения, что нужно улучшить.
Когда работаешь внутри продукта, то понимаешь, что проблема наоборот — в избытке идей. Их так много, что сделать даже треть — нереально. Все идеи записываются в бэклог, это главный рабочий инструмент продуктолога. А на деле — гигантская помойка.
Главная ошибка начинающих продактов — делать задачи по принципу «это нужно и полезно». Задач много, все они так или иначе полезные и нужные. Легко потратить силы команды на мелочи и не достичь ничего значимого. Когда две команды перетягивают канат, побеждают те, что действует синхронно и осмысленно, а не те, кто «старался и устал».
Сохранять сфокусированность мне помогает иерархия бэклога и следующие принципы:
1. Стратегия. Должно быть понимание, в какую сторону развивается продукт в ближайшие пару лет. Надо сформулировать 1-3 North stars — ключевых метрик/целей. Пример: «Повысить ежемесячную выручку до 100М».
2. Эпики. Мыслить надо не фичами, а эпиками. Это значимое достижение, которое можно сделать за несколько месяцев. Например: «Подключить иностранные платежи». Каждый эпик должен внятно переоформить в какую-то North star. Мы планируем по 2-3 эпика на квартал.
3. Задачи. Каждая задача должна принадлежать какому-то эпику. Если пришла идея, которую хочется сделать, но она не попадает в запланированный эпик — не делайте ее. Конечно, есть мелочи, которые приходится делать вне очереди, но я слежу, чтобы доля задач «без эпика» была не более 10-20%.
Обычно в продуктовом бэклоге сотни и даже тысячи задач. Очень сложно с таким количеством работать. Эпиков же получается штук пятьдесят. Работать с 50 идеями проще, чем с 1000.
Если прилетает какая-то идея от пользователя, от исследований или просто осенило — я ищу для этого подходящий эпик и записываю туду. Когда эпик попадет на проработку и дизайн, эта идея будет учтена или отброшена.
Когда я не работал в продуктовых IT-компаниях, я думал проблемы там от недостатка идей. Надо просто посоветовать и объяснить, как правильно сделать, и они сразу исправятся. Так думают многие пользователи, поэтому постоянно пишут предложения, что нужно улучшить.
Когда работаешь внутри продукта, то понимаешь, что проблема наоборот — в избытке идей. Их так много, что сделать даже треть — нереально. Все идеи записываются в бэклог, это главный рабочий инструмент продуктолога. А на деле — гигантская помойка.
Главная ошибка начинающих продактов — делать задачи по принципу «это нужно и полезно». Задач много, все они так или иначе полезные и нужные. Легко потратить силы команды на мелочи и не достичь ничего значимого. Когда две команды перетягивают канат, побеждают те, что действует синхронно и осмысленно, а не те, кто «старался и устал».
Сохранять сфокусированность мне помогает иерархия бэклога и следующие принципы:
1. Стратегия. Должно быть понимание, в какую сторону развивается продукт в ближайшие пару лет. Надо сформулировать 1-3 North stars — ключевых метрик/целей. Пример: «Повысить ежемесячную выручку до 100М».
2. Эпики. Мыслить надо не фичами, а эпиками. Это значимое достижение, которое можно сделать за несколько месяцев. Например: «Подключить иностранные платежи». Каждый эпик должен внятно переоформить в какую-то North star. Мы планируем по 2-3 эпика на квартал.
3. Задачи. Каждая задача должна принадлежать какому-то эпику. Если пришла идея, которую хочется сделать, но она не попадает в запланированный эпик — не делайте ее. Конечно, есть мелочи, которые приходится делать вне очереди, но я слежу, чтобы доля задач «без эпика» была не более 10-20%.
Обычно в продуктовом бэклоге сотни и даже тысячи задач. Очень сложно с таким количеством работать. Эпиков же получается штук пятьдесят. Работать с 50 идеями проще, чем с 1000.
Если прилетает какая-то идея от пользователя, от исследований или просто осенило — я ищу для этого подходящий эпик и записываю туду. Когда эпик попадет на проработку и дизайн, эта идея будет учтена или отброшена.