# Принятие продуктовых решений

# Описание

Продакт-менеджер отвечает за принятие решений о том, что команда должна и не должна делать. Эти решения бывают как очень локальными – "В какой цвет покрасить кнопку?", так и глобальными – "Выходить ли с продуктом на рынок США?". Эта ветка описывает разные уровни принятия решений и артефакты, с помощью которых продакт-менеджер работает со своей командой и стейкхолдерами.

# Как ветки связаны

# Стратегия

Самый верхний уровень принятия решений – это продуктовая стратегия. При её разработке продакт-менеджер должен сделать следующее:

Поставить диагноз. Для этого нужно проанализировать внешнюю и внутреннюю ситуацию в компании – рынок, конкурентов, направления развития индустрии, собственные возможности и ресурсы. Результат этого шага – понимание того, куда нужно привести продукт в будущем, и что надо этому может помешать.
Выработать руководящую политику. Это набор высокоуровневых принципов и идей, за счёт которых вы справитесь со своим диагнозом.
Описать комплекс последовательных действий, которые реализуют вашу руководящую политику. Вы могли сталкиваться с ними под другим названием – стратегические инициативы.

Стратегия обычно редко пересматривается глобально, если диагноз был поставлен верно. Именно она в идеальном случае должна служить фундаментом для принятия всех остальных решений на более низких уровнях абстракции.

# Целеполагание

Цели – удобный инструмент для того, чтобы задать команде вектор движения на определённый промежуток времени, и в процессе понимать, насколько хорошо получается его придерживаться. Целеполагание может использоваться на разных уровнях – стратегическом, для выражения вашей политики или комплекса действий, или тактическом, для фокусировки команды на том, что важно делать именно сейчас.

Суровая реальность такова, что даже при наличии продуктовой стратегии менеджеру приходится постоянно следить и за другими вводными – резкими изменениями в индустрии или законодательстве, потребностями стейкхолдеров, внутренним состоянием проекта. Целеполагание позволяет явно договориться о том, что для команды или продукта является самым важным на выбранном отрезке времени. А это сильно упрощает итоговый процесс принятия продуктовых решений.

# Роадмап

Продуктовый роадмап – это документ, который показывает, что планирует сделать команда в будущем. В отличие от стратегии и целей, роадмап обязательно включает в себя конкретные фичи, которые планируется реализовать, поэтому его удобно использовать для синхронизации планов со стейкхолдерами. Чаще всего роадмап является внешним для команды документом – поэтому он оформляется таким образом, чтобы его было просто понять.

Роадмап позволяет понять, за счёт каких конкретно задач команда планирует реализовать поставленные ей цели.

# Бэклог

Бэклог – это упорядоченный список задач, которые поступают на вход команде разработки. Это главный интерфейс взаимодействия между всеми стратегиями, целями и роадмапами, и конкретными инженерами, которые в итоге создают продукт. От роадмапа его отличает гораздо больший уровень декомпозиции и описание в терминах, удобных для использования в команде. Бэклог включает в себя не только задачи, которые помогают добиться ключевых целей, но и задачи на поддержку или решение технического долга.

При работе с бэклогом продакт-менеджер отвечает за наполнение его ценными задачами, реализующими цели или роадмап, и за приоритизацию их друг относительно друга.

# Как работать с веткой

В идеальном мире алгоритм должен выглядеть вот так:

Появляется продуктовая стратегия
Выставляются стратегические цели для продукта с описывающими их метриками
Выставляются цели продукта на ближайший интервал времени, например, квартал
Составляется роадмап, включающий в себя крупные вещи, которые команде точно придётся делать в этом квартале
Продакт-менеджер постепенно узнает больше о пользователях и их запросах, наполняя бэклог для команды разработки и корректируя роадмап

Но мы живём не в идеальном мире, и чаще всего либо часть пунктов в алгоритме отсутствует полностью, либо выполняется не в том порядке. Это не всегда плохо. Например, вполне разумным может быть сначала выстроить работу с бэклогом, что позволит упростить процессы разработки в команде, а затем уже заняться более высокоуровневой проработкой, что в целом повысит качество принимаемых решений.