Hygger corporate blog
Development Management
Project management
Product Management
November 2018 21

Как правильно готовить продуктовую стратегию? Руководство для менеджеров продуктов

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

Помните правила великого Кутузова, который четко и ясно видел стратегические цели? Он считал, что стратегия должна всегда превалировать над тактикой. Для победы вполне допустимо пожертвовать отдельной битвой, ведь «главное не крепость взять, а войну выиграть».

image

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

Стратегия продукта – основа деятельности управленцев


Все начинается с четкой и гибкой стратегии. Определение стратегии в самом начале жизненного цикла продукта происходит по принципу «must have». Хорошая стратегия должна удовлетворять потребности ваших клиентов и помогать им реагировать на внутренние потребности компании. Если у вас нет четкой стратегии, то о приоритизации функций думать рано.

Когда менеджеры продуктов разрабатывают свои стратегии, они определяют основные характеристики продукта и особенности клиента, необходимые для достижения успеха.

Что такое стратегия?


Любая стратегия направлена ​​на достижение конкретной цели. Это реальный маршрут от точки A в точку Б.

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

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

  • Достижение конкретных целей
  • Конкретные действия согласно конкретному плану
  • Преодоление самого большого препятствия — должен быть четкий «диагноз» самой большой проблемы, которая должна быть решена.

image

Любая продуктовая стратегия состоит из 4 частей:

Видение продукта


Product vision или видение продукта включает информацию о возможностях рынка, целевых клиентах, позиционировании продукта, конкурентном анализе и рыночном плане. Успех продукта в конечном итоге достигается, если продукт выходит на новых пользователей и доставляет им определенную ценность.

Цели продукта


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

Метрики


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

Конкретный план действий


Здесь должны быть доступно расписаны все этапы и шаги по достижению стратегии.

Одним из эффективных способов планирования является система, которую предлагает Itamar Gilad — опытный консультант в области управления продуктами и успешный спикер. В своем подробном материале на Hackernoon он описывает полезность и ценность GIST-планирования и предлагает внедрять его в работу вместо традиционных product roadmap.

Планирование по системе GIST


Проблематика


К сожалению, часто планы быстро расходятся с реальностью. Дорожные карты и диаграммы Ганта (Gantt Charts), безусловно, полезны, но в них нет места для маневренности.

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

Решение


Использование системы планирования GIST помогает решить эту проблему: вы получаете легкие планы с возможностью изменений. Они уменьшают расходы на управление, улучшают производительность команды и, в конечном итоге, позволяют добиться более качественного продуктового решения.

Авторская система GIST состоит из четырех элементов. Она называется по первым буквам ее основных блоков:

  • Goals (цели)
  • Ideas (идеи)
  • Step-projects (проекты)
  • Tasks (задачи)

Каждый из них имеет разные горизонты планирования и частоту изменений и ими можно управлять с помощью разных инструментов, но вместе они составляют основу планирования.

image

G – goals (цели)


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

I — Ideas (идеи)


Идеи  — это гипотетический способ достижения целей. Гипотетический потому, что у вас может быть много идей для достижения заданной цели, но только 1–3 из них приведут к положительному результату (а часто соотношение и того хуже). Причем у крутых менеджеров продуктов коэффициент не больше. Поэтому GIST исключает, что вы:

  • “убьете” идеи заранее
  • оставите идеи даже если у них сейчас очень низкий приоритет
  • не выделите идеи от ТОП-менеджмента
  • не следуете моде

Вместо этого, предполагается, что вы:

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

S — Step projects (проекты)


Большой проект разбивается на мелкие проекты, которые длятся не более 10 недель и выполняются по очереди. Например:

Детализированный статичный прототип → Интерактивный прототип → MVP → Dogfood → Beta → Launch.

Каждый такой проект — это эксперимент, который проверяет идею. То есть с каждым проектом вы получаете все более полную версию идеи и проверяете ее на более широкой аудитории в течение все более длительного времени.

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

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

T – Tasks (задачи)


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

Планирование с помощью GIST многоуровневое и итеративное:

  • Цели обычно устанавливаются с прицелом на один год или нескольких лет.
  • Идеи постоянно собираются и приоритизируются. Важно не переставать искать новые идеи.
  • Проекты определяются в начале квартала. Команда выбирает цели и идеи, которые она хочет выполнить в этом квартале, и соответственно определяет проекты.
  • Задачи разбиваются на 1–2х недельные итерации в соответствии с вашим методом разработки и корректируются ежедневно.

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

Как упростить GIST?


Step projects действительно полезны для крупных проектов, потому что они помогают как можно скорее подтвердить идеи и не тратить огромные суммы на полную разработку идей. Для мелких проектов это не всегда уместно. К примеру, в разработке мобильных приложений вы можете действовать без Step Projects.

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

  • цели сформулированы на четверть вперед, это достаточно просто.
  • метрики — вы выбираете ключевые метрики, которые покажут ваше движение к целям и на которые вы будете влиять с помощью идей. Отличный пример – OMTM (One metric that matter) или AARRR (Pirates metrics).
  • идеи – это гипотезы о том, как повысить ваши метрики.
  • фичи/задачи — конкретные задачи для разработчиков и других членов команды для реализации идей.

Упрощенный процесс выглядит довольно привлекательным: вы просто ставите цели, выбираете соответствующие метрики для контроля и собираете идеи, которые могут улучшить эти метрики. Затем определяются приоритеты, применяется скоринг фич и, наконец, записывается задача для фич-победителей. Фичи разбиваются на задачи, которые отправляются в разработку.

Сила приоритизации


Разобраться с важностью и срочностью фич и задач помогают разные способы и подходы приоритизации.

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

Матрица 2x2 для определения приоритетов


Классический подход, основанный на матрице Эйзенхауэра, состоит из двух осей. Выбрав рамки, вы можете установить свои собственные критерии и оценить идеи, фичи и задачи продукта. Например, такие методы приоритизации, как Value vs Effort, Value vs Risk, Value vs Cost могут быть легко визуализированы с помощью этой структуры.

В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):

  • Сперва мы разрабатываем Quick Wins. Это фичи, которые приносят больше всего ценности, но которые можно быстро и легко реализовать.
  • Далее – Big Bets. Эти фичи могут принести много ценности, но их сложно реализовать.
  • Потом – Maybes – задачи или фичи, которые не дадут много ценности, но их легко внедрить. Их можно оставить на потом.
  • Наконец, Time Sinks. На эти фичи вообще не стоит обращать внимания.

image

Метод ICE Scoring


Метод ICE — это простой способ определить приоритетность функций продукта без дополнительных требований. Все, что вам нужно, это рассчитать баллы за идею, согласно формуле:
image

  • Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
  • Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
  • Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.

Метод ICE Scoring предполагает использование шкалы от 1 до 10 чтобы все факторы сбалансировано влияли на итоговый балл. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.

Метод RICE Scoring


Метод RICE – еще один интересный способ приоритизации идей и фич продукта. Аббревиатура включает 4 фактора: Reach (охват), Impact (влияние), Confidence (уверенность в вашей оценке охвата, влияния и трудозатрат), Effort (трудозатраты).
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.

  • Reach (Охват). Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
  • Impact (Влияние). Влияние показывает какой вклад приносит эта фича продукту. Ценность понимается по-разному в каждом продукте. Например, в B2B SaaS продукте фичи могут получать высокое значение, если они улучшают trial-to-paid конверсию, помогать привлечь новых пользователей, добавляют ценности продукту и отстраивают от конкурентов и др.
  • Confidence (Уверенность в оценке). Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
  • Effort (Трудозатраты). Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.

Вам необходимо ранжировать предлагаемые функции с помощью Reach, Impact, Confidence and Effort и использовать окончательный результат, чтобы решить, что должно быть реализовано вначале.

image

Скоринг фич


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

Критерии оценки выбираются индивидуально. Они могут быть выбраны на основе четко определенных целей продукта и метрик. Например:

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

С точки зрения затрат можно оценить следующее:

  • время и стоимость разработки
  • время и стоимость реализации
  • эксплуатационные расходы

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

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

Принцип Planning Poker


Planning Poker или Покер планирования впервые был описан Джеймсом Греннингом в 2002 году.

Для проведения необходимо подготовить список обсуждаемых фич и несколько колод карт. Список фич или пользовательские истории описывают разрабатываемое ПО. Карты в колодах должны быть пронумерованы. Чаще всего это карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Некоторыми организациями используются обычные игровые карты, включающие туз, 2, 3, 5, 8 и короля.

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

image

  • Выбирается модератор, который не участвует в обсуждении.
  • Менеджер продукта представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков.
  • Участники выбирают по одной карте и кладут их рубашкой вверх. Каждый участник называет свою карту и переворачивает её.
  • Участникам с высокими и низкими оценками имеют право высказаться и обосновать оценку.
  • Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус.
  • В процессе может использоваться таймер для обеспечения структурированности обсуждения.

Другие методы и техники приоритизации


К радости менеджеров продуктов, сегодня существует множество специальных техник и фреймворков для работы с приоритетами. Об этом написано много; перечислим некоторые из них:


Что в итоге?


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

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

А какие ваши секреты работы с продуктовой стратегией? Считаете ли вы умение приоритизировать основополагающим в работе менеджера продукта?

+10
6.6k 94
Comments 1
Top of the day