Цикл продуктовой стратегии

29 Янв 2021

Всем привет!

Роман Пихлер — эксперт Scrum и Agile-управления продуктом, автор таких книг, как «Управление продуктом в Scrum. Agile-методы для вашего бизнеса», «Scrum — успешное применение Agile-управления проектами» и др.

В данной статье Роман рассказывает о цикле продуктовой стратегии, фреймворке, который он создал для более эффективного управления продуктом.

Перевод оригинальной статьи

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

В данной статье я объясняю, как можно использовать цикл для объединения стратегии продукта, дорожной карты (product roadmap), ключевых показателей эффективности (KPIs), product backlog (список требований к функциональности продукта, упорядоченный по степени важности) и работу по разработке; а также, как обсуждать роль заинтересованных сторон и членов команды разработки в принятии эффективных стратегических решений по продукту.

Погрузитесь в цикл

Традиционно стратегия и исполнение рассматриваются как отдельные, последовательные части работы, выполняемые разными людьми. Например, продакт-менеджер может определить стратегию продукта, и одной или нескольким командам разработчиков будет поручено ее выполнение. Но пока присутствуют инновации, изменения и риски, этот подход неэффективен. Напротив, они должны быть тесно связаны: не только стратегия должна направлять исполнение, но и исполнение должно информировать об изменениях стратегии и помогать адаптировать ее.

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

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

Эффективная стратегия продукта должна отражать:

  • целевую аудиторию продукта
  • ценностное предложение
  • выдающиеся характеристики
  • бизнес-цели.

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

Именно поэтому на картинке выше рядом со «Стратегией продукта» находится небольшой цикл “Validation” (Проверка соответствия — валидация).

После того, как вы устранили ключевые риски и убедились, что выбрали правильные потребности, рынок, отличительные особенности и бизнес-цели, вы можете сделать следующий шаг — составить дорожную карту продукта на основе стратегии. Я рассматриваю дорожную карту как план продукта, в котором описывается, как вы намереваетесь реализовать стратегию, и какие конкретные преимущества или результаты должен обеспечить продукт в течение следующих, скажем, 12 месяцев, в зависимости от потребностей и бизнес-целей, заявленных в стратегии продукта. Я называю эти результаты продуктовыми целями (product goals).

Примеры подобных целей:

  • привлечение новых пользователей
  • повышение вовлеченности
  • устранение технических недоработок, чтобы продукт соответствовал будущим требованиям
  • получение дохода

Имея работающую дорожную карту продукта, двигайтесь дальше и не забудьте про product backlog. Для этого:

  1. Выберите следующую продуктовую цель, указанную в дорожной карте
  2. Определите функции и возможности, необходимые для ее достижения
  3. Зафиксируйте их в журнале очереди
  4. Создайте ровно столько готовых элементов бэклога, сколько необходимо, чтобы иметь возможность начать предстоящий спринт и разработать реальный продукт.

Поскольку итеративный процесс обычно лучше всего подходит для создания нового продукта или крупного обновления продукта, я добавил еще один небольшой цикл между «Бэклогом» и «Продуктом» — «Development / Разработка»

После того, как начнется разработка, измерьте прогресс разработки, например, с помощью диаграммы сгорания выпуска. При выпуске начальной или новой версии продукта, используйте KPIs для измерения производительности продукта. Они должны включать метрики, необходимые для определения того, была ли достигнута выбранная цель продукта, и дополнительные индикаторы, которые помогут вам оценить, как работает ваш продукт, и работает ли стратегия. Примерами последних являются вовлеченность, удержание, качество продукта, мотивация команды, а в случае продукта, приносящего выручку — доход и затраты.

Используйте KPIs (хотя в данном случае лучше использовать OKRs (Objectives & Key results / Цели и Ключевые результаты) — примечание редактора) и данные о ходе разработки, чтобы просмотреть стратегию продукта и дорожную карту и при необходимости изменить их. Это может потребовать внесения небольших дополнительных корректировок. В то же время это может потребовать от вас поворота, значительного изменения стратегии, чтобы сделать продукт успешным. Возьмем YouTube в качестве известного примера. Продукт превратился из сайта знакомств в платформу для обмена видео.

Так вы завершили цикл и начали другой.

Привлекайте нужных людей

Систематическая связь стратегии и исполнения — ключевой фактор для создания эффективной стратегии продукта, но этого недостаточно. Лучшая продуктовая стратегия — бесполезна, если заинтересованные стороны и команда (-и) разработки не согласны с ней и не готовы реализовать принимаемые ею решения.

Чтобы максимально увеличить вероятность, что люди поймут и поддержат стратегические решения по продукту, я рекомендую вам привлекать ключевые заинтересованные стороны и представителей группы разработчиков к созданию и проверке стратегии продукта, разработке дорожной карты продукта, отслеживанию KPIs и прогресса разработки, а также обновлению планов. 

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

Отличный способ привлечь ключевые заинтересованные стороны и членов команды разработчиков — провести совместный семинар, будь то в онлайне или в офисе. Попросите своего Скрам-мастера или другого опытного фасилитатора помочь подготовить семинар и провести сессию. 

Это включает в себя установление основополагающих правил: выбор такого полезного правила принятия решений, как согласие, и обеспечение того, чтобы все были услышаны и никто не доминировал. (Вы можете найти больше советов по совместному принятию решений в моей книге «Как стать лидером в управлении продуктом»).

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

Заключительные мысли

«Все модели неверны, но некоторые полезны», — как однажды заметил Джордж Бокс. Каждая модель — это абстракция реальности. Поэтому она упрощает или игнорирует некоторые аспекты и может не учитывать некоторые детали. Исключением не является и цикл продуктовой стратегии, описанный в данной статье. На самом деле все немного сложнее.

Есть два аспекта, на которые я хотел бы обратить ваше внимание:

Во-первых, вы должны измерить прогресс разработки, как только команда разработчиков начнет преобразовывать элементы бэклога в приращение продукта. Когда у вас будет достаточно данных, чтобы увидеть четкую тенденцию — что обычно наблюдается после двух-трех спринтов — проверьте, может ли цель продукта быть достигнута вовремя и в рамках бюджета. Если это не так, вам, возможно, придется скорректировать дорожную карту, что может даже вызвать корректировку стратегии продукта. Точно так же, если в бэклоге продукта происходят значительные изменения, например, когда вы обнаруживаете, что ключевая функция не требуется или ее нужно заменить, вам следует учесть их влияние на дорожную карту и обновить ее как можно скорее.

Во-вторых, вы не должны забывать о постоянном поиске продуктов, что включает в себя частое отслеживание новых тенденций и конкурентов. Как я уже советовал ранее, тратьте не менее половины дня в неделю на непрерывные исследования и стратегическую работу, включая анализ актуальных тенденций и наблюдение за конкурентами. Это гарантирует, что мимо вас не пройдут никакие угрозы и возможности. Вы сможете реагировать на изменения заблаговременно и не окажетесь загнанными в угол.


Яндекс.Метрика