Без сильной и уверенной стратегии в управлении продуктом делать нечего. Любой начинающий менеджер продукта должен стремиться развивать в себе умения и навыки, которые помогут выстраивать стратегию как великие и дальновидные полководцы. Важными составляющими создания эффективной стратегии являются умение качественно планировать, определять приоритеты идей и задач и оценивать их.
Помните правила великого Кутузова, который четко и ясно видел стратегические цели? Он считал, что стратегия должна всегда превалировать над тактикой. Для победы вполне допустимо пожертвовать отдельной битвой, ведь «главное не крепость взять, а войну выиграть».
В управлении продуктом все решается мирным путем, однако управленцам следовало бы многому поучиться у полководца. Этот материал будет полезен тем, кто стремится стать гуру в стратегическом планировании и научиться грамотно приоритизировать.
Все начинается с четкой и гибкой стратегии. Определение стратегии в самом начале жизненного цикла продукта происходит по принципу «must have». Хорошая стратегия должна удовлетворять потребности ваших клиентов и помогать им реагировать на внутренние потребности компании. Если у вас нет четкой стратегии, то о приоритизации функций думать рано.
Когда менеджеры продуктов разрабатывают свои стратегии, они определяют основные характеристики продукта и особенности клиента, необходимые для достижения успеха.
Любая стратегия направлена на достижение конкретной цели. Это реальный маршрут от точки A в точку Б.
Эффективная стратегия должна включать в себя следующее:
Любая продуктовая стратегия состоит из 4 частей:
Product vision или видение продукта включает информацию о возможностях рынка, целевых клиентах, позиционировании продукта, конкурентном анализе и рыночном плане. Успех продукта в конечном итоге достигается, если продукт выходит на новых пользователей и доставляет им определенную ценность.
Цели должны быть измеримыми и актуальными, четко определяться конкретными метриками. Они помогают менеджерам продуктов установить, чего они хотят достичь в следующем квартале или другом временном отрезке (увеличить доходы, расширить присутствие в новых странах, повысить мобильную адаптацию и т. д.)
Метрики позволяют измерять ход и прогресс достижения целей. Среди множества доступных метрик, очень важно выбрать подходящие именно для вашего продукта.
Здесь должны быть доступно расписаны все этапы и шаги по достижению стратегии.
Одним из эффективных способов планирования является система, которую предлагает Itamar Gilad — опытный консультант в области управления продуктами и успешный спикер. В своем подробном материале на Hackernoon он описывает полезность и ценность GIST-планирования и предлагает внедрять его в работу вместо традиционных product roadmap.
К сожалению, часто планы быстро расходятся с реальностью. Дорожные карты и диаграммы Ганта (Gantt Charts), безусловно, полезны, но в них нет места для маневренности.
Дорожные карты позволяют работать только с несколькими крупными проектами, поэтому приходится расставлять приоритеты и выбрасывать многие потенциально хорошие идеи. В иерархических компаниях идеи-победители приходят от руководства. В более демократических компаниях добиться признания идеи сложнее, поэтому питчинг и умение убеждать и продавать стали обязательными навыками менеджеров продукта.
Использование системы планирования GIST помогает решить эту проблему: вы получаете легкие планы с возможностью изменений. Они уменьшают расходы на управление, улучшают производительность команды и, в конечном итоге, позволяют добиться более качественного продуктового решения.
Авторская система GIST состоит из четырех элементов. Она называется по первым буквам ее основных блоков:
Каждый из них имеет разные горизонты планирования и частоту изменений и ими можно управлять с помощью разных инструментов, но вместе они составляют основу планирования.
Цели описывают стратегию компании с точки зрения желаемых результатов: где мы хотим быть? когда и как мы узнаем о том, что мы их достигли? Всякий раз, когда кто-либо в организации задается вопросом: «Почему мы делаем этот проект?», цель должна давать ясный ответ.
Идеи — это гипотетический способ достижения целей. Гипотетический потому, что у вас может быть много идей для достижения заданной цели, но только 1–3 из них приведут к положительному результату (а часто соотношение и того хуже). Причем у крутых менеджеров продуктов коэффициент не больше. Поэтому GIST исключает, что вы:
Вместо этого, предполагается, что вы:
Большой проект разбивается на мелкие проекты, которые длятся не более 10 недель и выполняются по очереди. Например:
Детализированный статичный прототип → Интерактивный прототип → MVP → Dogfood → Beta → Launch.
Каждый такой проект — это эксперимент, который проверяет идею. То есть с каждым проектом вы получаете все более полную версию идеи и проверяете ее на более широкой аудитории в течение все более длительного времени.
Конечный продукт, как правило, намного лучше, чем тот, который вы себе представляли изначально. Неработающие идеи отсеиваются рано, а идеи, которые работают, получают больше инвестиций.
Возможность придумать идею и уже через пару недель внедрить ее в продукт — очень сильно вдохновляет. Вы никогда больше не захотите делать громоздкие проекты.
Каждый проект разбивается на задачи. Эта часть системы планирования отлично помогают визуализировать Agile-ориентированные инструменты для планирования, Kanban-доски, и современные технологии для управления проектами.
На этом уровне вам скорее всего ничего не придется менять.
Планирование с помощью GIST многоуровневое и итеративное:
GIST-планирование может показаться сложным и избыточным, особенно для небольших проектов, поэтому возможно применять его упрощенную версию.
Step projects действительно полезны для крупных проектов, потому что они помогают как можно скорее подтвердить идеи и не тратить огромные суммы на полную разработку идей. Для мелких проектов это не всегда уместно. К примеру, в разработке мобильных приложений вы можете действовать без Step Projects.
Поэтому после того, как вы выбрали лучшие идеи с помощью приоритезации, вы готовите задачи для их реализации, собираете требования, записываете спецификации и отправляете их в разработку. В конце спринта вы можете собирать данные и отзывы пользователей. Эта иерархия выглядит так:
Упрощенный процесс выглядит довольно привлекательным: вы просто ставите цели, выбираете соответствующие метрики для контроля и собираете идеи, которые могут улучшить эти метрики. Затем определяются приоритеты, применяется скоринг фич и, наконец, записывается задача для фич-победителей. Фичи разбиваются на задачи, которые отправляются в разработку.
Разобраться с важностью и срочностью фич и задач помогают разные способы и подходы приоритизации.
Первый подход, на котором остановимся, представляет собой фреймворк, который считается достаточно эффективным и мощным и не занимают много времени и усилий – 2x2 матрица. Это простая и быстрая система определения приоритетов.
Классический подход, основанный на матрице Эйзенхауэра, состоит из двух осей. Выбрав рамки, вы можете установить свои собственные критерии и оценить идеи, фичи и задачи продукта. Например, такие методы приоритизации, как Value vs Effort, Value vs Risk, Value vs Cost могут быть легко визуализированы с помощью этой структуры.
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
Метод ICE — это простой способ определить приоритетность функций продукта без дополнительных требований. Все, что вам нужно, это рассчитать баллы за идею, согласно формуле:
Метод ICE Scoring предполагает использование шкалы от 1 до 10 чтобы все факторы сбалансировано влияли на итоговый балл. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.
Метод RICE – еще один интересный способ приоритизации идей и фич продукта. Аббревиатура включает 4 фактора: Reach (охват), Impact (влияние), Confidence (уверенность в вашей оценке охвата, влияния и трудозатрат), Effort (трудозатраты).
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.
Вам необходимо ранжировать предлагаемые функции с помощью Reach, Impact, Confidence and Effort и использовать окончательный результат, чтобы решить, что должно быть реализовано вначале.
Яркий пример оценки фич – метод Weighted Scoring. Этот метод позволяет вам рассматривать фичи, ранжировать их с помощью специального фреймворка по ряду критериев и использовать оценки, которые вы сами придумали. Это недорогой и удобный способ определить относительную ценность любого количества задач, над которыми вы можете работать.
Критерии оценки выбираются индивидуально. Они могут быть выбраны на основе четко определенных целей продукта и метрик. Например:
С точки зрения затрат можно оценить следующее:
Любая оценка идей или фич на этапе планирования всегда является субъективной в условиях сильной неопределенности. Оценка идей в группах позволяет сделать процесс более точным благодаря открытому обсуждению. Тем не менее, важно следовать основному правилу — перед оценкой вам нужно детально обсудить идею и попытаться коснуться различных аспектов.
Только после того, как группа обсудила эту идею, вы можете перейти к оценке. Такой принцип у метода Planning Poker, который в оригинале использовался для оценки задач для спринтов, а сейчас часто применяется менеджерами и для оценки идей.
Planning Poker или Покер планирования впервые был описан Джеймсом Греннингом в 2002 году.
Для проведения необходимо подготовить список обсуждаемых фич и несколько колод карт. Список фич или пользовательские истории описывают разрабатываемое ПО. Карты в колодах должны быть пронумерованы. Чаще всего это карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Некоторыми организациями используются обычные игровые карты, включающие туз, 2, 3, 5, 8 и короля.
Все оценивающие выбирают одну карту для представления их оценки. В то же время открываются все карты. Если все оценивающие выбрали одно и то же значение, это и станет оценкой. Если нет, то все обсуждают свои оценки.
К радости менеджеров продуктов, сегодня существует множество специальных техник и фреймворков для работы с приоритетами. Об этом написано много; перечислим некоторые из них:
Если способ приоритизации выбран и реализован успешно, то все довольно просто: все задачи идут в разработку по Scrum или Kanban, а менеджеру продукта остается отслеживать их прогресс и наслаждаться успешно реализуемой стратегией.
Возможно, первые результаты работы со стратегией и технологиями приоритизации сразу не сделают вас Кутузовым или Наполеоном в управлении продуктами, но однозначно повысят ваш профессиональный уровень и придадут уверенности в дальнейших делах.
А какие ваши секреты работы с продуктовой стратегией? Считаете ли вы умение приоритизировать основополагающим в работе менеджера продукта?
Помните правила великого Кутузова, который четко и ясно видел стратегические цели? Он считал, что стратегия должна всегда превалировать над тактикой. Для победы вполне допустимо пожертвовать отдельной битвой, ведь «главное не крепость взять, а войну выиграть».
В управлении продуктом все решается мирным путем, однако управленцам следовало бы многому поучиться у полководца. Этот материал будет полезен тем, кто стремится стать гуру в стратегическом планировании и научиться грамотно приоритизировать.
Стратегия продукта – основа деятельности управленцев
Все начинается с четкой и гибкой стратегии. Определение стратегии в самом начале жизненного цикла продукта происходит по принципу «must have». Хорошая стратегия должна удовлетворять потребности ваших клиентов и помогать им реагировать на внутренние потребности компании. Если у вас нет четкой стратегии, то о приоритизации функций думать рано.
Когда менеджеры продуктов разрабатывают свои стратегии, они определяют основные характеристики продукта и особенности клиента, необходимые для достижения успеха.
Что такое стратегия?
Любая стратегия направлена на достижение конкретной цели. Это реальный маршрут от точки A в точку Б.
Эффективная стратегия — это комплекс действий, которые заслуживают доверия, они согласованы и направлены на преодоление больших препятствий на пути достижения конкретной цели
Ричард Румельт
Эффективная стратегия должна включать в себя следующее:
- Достижение конкретных целей
- Конкретные действия согласно конкретному плану
- Преодоление самого большого препятствия — должен быть четкий «диагноз» самой большой проблемы, которая должна быть решена.
Любая продуктовая стратегия состоит из 4 частей:
Видение продукта
Product vision или видение продукта включает информацию о возможностях рынка, целевых клиентах, позиционировании продукта, конкурентном анализе и рыночном плане. Успех продукта в конечном итоге достигается, если продукт выходит на новых пользователей и доставляет им определенную ценность.
Цели продукта
Цели должны быть измеримыми и актуальными, четко определяться конкретными метриками. Они помогают менеджерам продуктов установить, чего они хотят достичь в следующем квартале или другом временном отрезке (увеличить доходы, расширить присутствие в новых странах, повысить мобильную адаптацию и т. д.)
Метрики
Метрики позволяют измерять ход и прогресс достижения целей. Среди множества доступных метрик, очень важно выбрать подходящие именно для вашего продукта.
Конкретный план действий
Здесь должны быть доступно расписаны все этапы и шаги по достижению стратегии.
Одним из эффективных способов планирования является система, которую предлагает Itamar Gilad — опытный консультант в области управления продуктами и успешный спикер. В своем подробном материале на Hackernoon он описывает полезность и ценность GIST-планирования и предлагает внедрять его в работу вместо традиционных product roadmap.
Планирование по системе GIST
Проблематика
К сожалению, часто планы быстро расходятся с реальностью. Дорожные карты и диаграммы Ганта (Gantt Charts), безусловно, полезны, но в них нет места для маневренности.
Дорожные карты позволяют работать только с несколькими крупными проектами, поэтому приходится расставлять приоритеты и выбрасывать многие потенциально хорошие идеи. В иерархических компаниях идеи-победители приходят от руководства. В более демократических компаниях добиться признания идеи сложнее, поэтому питчинг и умение убеждать и продавать стали обязательными навыками менеджеров продукта.
Решение
Использование системы планирования GIST помогает решить эту проблему: вы получаете легкие планы с возможностью изменений. Они уменьшают расходы на управление, улучшают производительность команды и, в конечном итоге, позволяют добиться более качественного продуктового решения.
Авторская система GIST состоит из четырех элементов. Она называется по первым буквам ее основных блоков:
- Goals (цели)
- Ideas (идеи)
- Step-projects (проекты)
- Tasks (задачи)
Каждый из них имеет разные горизонты планирования и частоту изменений и ими можно управлять с помощью разных инструментов, но вместе они составляют основу планирования.
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. На эти фичи вообще не стоит обращать внимания.
Метод ICE Scoring
Метод ICE — это простой способ определить приоритетность функций продукта без дополнительных требований. Все, что вам нужно, это рассчитать баллы за идею, согласно формуле:
- Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
- Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
- Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.
Метод 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 и использовать окончательный результат, чтобы решить, что должно быть реализовано вначале.
Скоринг фич
Яркий пример оценки фич – метод 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 и короля.
Все оценивающие выбирают одну карту для представления их оценки. В то же время открываются все карты. Если все оценивающие выбрали одно и то же значение, это и станет оценкой. Если нет, то все обсуждают свои оценки.
- Выбирается модератор, который не участвует в обсуждении.
- Менеджер продукта представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков.
- Участники выбирают по одной карте и кладут их рубашкой вверх. Каждый участник называет свою карту и переворачивает её.
- Участникам с высокими и низкими оценками имеют право высказаться и обосновать оценку.
- Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус.
- В процессе может использоваться таймер для обеспечения структурированности обсуждения.
Другие методы и техники приоритизации
К радости менеджеров продуктов, сегодня существует множество специальных техник и фреймворков для работы с приоритетами. Об этом написано много; перечислим некоторые из них:
- Метод Value vs Cost
- Популярная модель Kano
- Метод приоритизации MoSCoW
- Методология Buy a Feature
- Технология Feature buckets
- Игровая техника KJ Method
Что в итоге?
Если способ приоритизации выбран и реализован успешно, то все довольно просто: все задачи идут в разработку по Scrum или Kanban, а менеджеру продукта остается отслеживать их прогресс и наслаждаться успешно реализуемой стратегией.
Возможно, первые результаты работы со стратегией и технологиями приоритизации сразу не сделают вас Кутузовым или Наполеоном в управлении продуктами, но однозначно повысят ваш профессиональный уровень и придадут уверенности в дальнейших делах.
А какие ваши секреты работы с продуктовой стратегией? Считаете ли вы умение приоритизировать основополагающим в работе менеджера продукта?
