10 ступеней цикла управления продуктом

Всем привет!

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

Автор статьи – Ryan Lysne

Содержание:

1. Введение
2. Шаг 1: Идеи продуктов и фич
3. Шаг 2: WBD: working backwards document / "работать, начиная с конца"
4. Шаг 3: Расстановка приоритетов
5. Шаг 4: Распределение историй клиентов
6. Шаг 5: Документ бизнес-требований
7. Шаг 6: Технический дизайн и структура
8. Шаг 7: Техническая реализация и тестирование
9. Шаг 8: Поток клиентов и пользовательское тестирование (UAT)
10. Шаг 9: Финальные исправления и проведение экспериментов
11. Шаг 10: Тестирование, обратная связь от клиентов, анализ
12. Кто отвечает за каждый этап процесса?
13. Какие повторяющиеся механизмы следует использовать для поддержания процесса на должном уровне?
14. С какими потенциальными подводными камнями вы можете столкнуться и как снизить эти риски?
15. Научитесь создавать продукты в Product Lab
16. Как захватить рынок и взломать рост продукта?

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

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

Цикл управления продуктом (Product Management Cycle), который будет описан в данной статье, не является единственно верным – несомненно, существуют альтернативы и специфические модификации, необходимые в зависимости от отрасли или ситуации. Каждая организация может по-разному упорядочивать или группировать виды деятельности, что совершенно нормально. Главное – создать надежные механизмы для каждого из этапов: установить четкую ответственность, определить цели и ожидаемые результаты, а также регулярно проверять и совершенствовать их. Я обобщил 10 этапов на рисунке 1 ниже, который станет основой для этой статьи.

Итак, что же мы должны создать для клиентов? Существует множество вариаций потенциальных циклов управления продуктом, которые можно использовать для:

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

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

1. ежегодное планирование стратегии и инвестиций
   
2. ежеквартальное планирование приоритетов
   
3. мониторинги состояния и планирование спринтов раз в две недели

Важно делиться вашими идеями и возможностями с заинтересованными сторонами, включая клиентов (особенно в сфере B2B), внутренних и внешних партнеров, поставщиков и руководство. Что касается возможностей для новых продуктов, то реальный вопрос, на который мы пытаемся ответить, заключается в следующем: что является наиболее ценным опытом, который мы можем предоставить клиентам? И какой наиболее ценный опыт мы можем предоставить нашим ключевым заинтересованным сторонам.

Ценность определяется организацией и, вероятно, отличается для различных отраслей или на этапе зрелости роста организации. Как правило, я рекомендую использовать в качестве наилучшего показателя FCF (Free Cash Flow – прирост долгосрочного свободного денежного потока – прим. ред.). FCF включает в себя как краткосрочную транзакционную стоимость (включая рекламу), так и долгосрочную стоимость в виде подписки, долгосрочного вовлечения/конверсии или "раскрытия" ценности в других частях компании (т.е. возможности перекрестных продаж/повышения продаж или открытия новых продуктов и услуг). FCF является двигателем роста, который ориентирован на инвесторов и не будет жертвовать долгосрочной выгодой ради краткосрочных улучшений. Одним из важнейших, но очень сложных для прогнозирования понятий является инкрементальность. Мы провели бесчисленное количество экспериментов, в ходе которых выяснили, что новый продукт генерирует ценность, но может сместить ценность из другого места или даже кардинально изменить поведение клиента. Новый опыт может не дать должный прирост, а поскольку продукты и услуги организации становятся все более сложными, необходимо постоянно учитывать это в уравнении ценности. Не менее важно учитывать это и в маркетинговой деятельности.

Несколько механизмов, которые вы можете применить при разработке новых идей для клиентов и заинтересованных сторон:

Прямая обратная связь с клиентами
Прямая обратная связь с клиентами – это наиболее четкие и откровенные комментарии о вашем продукте.

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

2. Фокус-группы/заметки клиентов: этот механизм полезен для более глубокого изучения того, почему клиент делает то, что он делает (или не делает). Вы можете узнать, почему клиент любит ту или иную фичу, почему он не использует другие фичи, почему он перестал пользоваться продуктом и т.д. Этот шаг не направлен на получение статистической значимости и упорядочивание главных проблем, а скорее на составление списка главных проблем с гипотезой об их решении. Здесь также полезно ведение заметок, в которых вы просите клиента записывать каждый раз, когда он делает X, почему он это делает, чего он пытался достичь и что он хотел бы изменить. Это может быть полезно для выявления автоматических или подсознательных моделей поведения.

3. Опросы клиентов: после того как вы получили представление о главных проблемах из фокус-групп/заметок, можно опросить клиентов, чтобы приблизиться к статистической значимости для упорядочивания главных возможностей.

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

5. Панель/бета-приложения: полезно получать ранние отзывы о продуктах, особенно при создании более сложных фич или услуг, на которые уйдут месяцы. Чтобы получить такую обратную связь, вы можете создать панель клиентов (особенно если у вас есть крупные и важные клиенты) или бета-приложение, где увлеченные вашим продуктом клиенты готовы попробовать новые фичи. Очевидно, что эти данные следует воспринимать с долей скептицизма, поскольку их источник необъективен, но они дадут вам ценные данные.

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

Косвенная обратная связь с клиентами
Косвенная обратная связь, в отличие от прямой, – это менее четкие и правдивые комментарии о вашем продукте.

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

Рекомендую воздержаться от прямого сравнительного анализа – по моему опыту, в подавляющем большинстве случаев вы тратите нерационально много времени на сбор данных, сравнение их с вашими собственными данными и попытки преодолеть или понять смысл различий, что почти всегда приводит к тупику и напрасным усилиям. Очень заманчиво (особенно для высшего руководства или инвесторов) попытаться понять, "почему мы не достигли показателей X?". Но дьявол всегда кроется в деталях, а эти детали обычно недоступны. У нас было достаточно проблем с сопоставлением наших собственных внутренних данных!

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

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

9. Агрегаторы данных: полезно искать агрегаторов, которые собирают данные последовательным образом. Эти данные также не являются "чистыми" и, скорее всего, не сопоставимы с вашими внутренними данными, но анализ различий и тенденций может быть полезным. Таким образом, абсолютные данные не являются полезными, в отличие от дельт и изменений. Агрегаторы данных, например, data.ai (бывший App Annie), Sensor Tower, Appfigures, Quantum Metric, отслеживают поведение покупателей приложений для iOS и Android и могут предоставить информацию о том, какие приложения они скачивают чаще всего, о показателе удержания различных приложений, относительном размере и о том, как они изменились со временем. Помимо сайтов, отслеживающих приложения, Similarweb и Statista располагают информацией по самым разным темам, которую можно использовать для определения размеров рынка.

Идеи от команды или заинтересованных сторон

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

Замысел состоит в том, чтобы дать возможность команде участвовать в процессе генерации идей относительно легким способом. Идея может возникнуть на основе собранных ими данных, опыта использования другого приложения или рекомендации друга. Единственным критерием является то, что идея должна быть основана на данных. Вначале обычно рассматривается документ, указывающий на достоинства идеи, далее все члены команды проводят обсуждение, включая начинающих разработчиков. Если идея будет выбрана, мы предложим ее создателю сотрудничать с продакт-менеджером, чтобы воплотить идею в полностью разработанный PRFAQ – press release frequently asked questions (подробнее об этом – в шаге 2 ниже).

Три других механизма, которые мы используем (как и многие другие компании):

1) мозговой штурм, позволяющий команде объединиться для создания прототипа любой идеи, которая кажется им интересной;

2) креативные дни: дважды в год мы выделяем один спринт, чтобы дать команде возможность поработать над чем угодно – от очистки кода до работы над новой идеей;

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

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

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

После того, как вы определились с главными идеями продукта или фичи, вам необходимо детально проработать минимальный клиентский опыт (краткосрочный и долгосрочный), бизнес-план, стратегию регистрации, данных и метрик, а также риски, с которыми вы можете столкнуться, и способы их снижения. Все это может быть записано в документе, который мы называем WBD (working backwards document /"работать, начиная с конца") – документ, в котором сформулирован полный опыт от начала до конца, который мы предоставим клиентам, почему клиентам понравится продукт, как они будут использовать продукт и где они смогут его найти. Уровень глубины этого документа может быть разным, но он примерно коррелирует с объемом инвестиций.

Затем мы предоставляем полностью разработанный пресс-релиз и сопровождающие его часто задаваемые вопросы (PRFAQ – press release frequently asked questions). На верхнем уровне пресс-релиз обычно не превышает одной страницы, написанной для описания того, каким будет опыт на момент запуска, почему он понравится клиентам икак они будут его использовать. Часто задаваемые вопросы обычно занимают от трех до пяти страниц, а весь документ не превышает шести страниц, хотя можно добавить приложение с макетами пользовательского интерфейса (т.е. пошаговыми скриншотами пользовательского опыта) или другую необходимую информацию. Нельзя не подчеркнуть, насколько важно заблаговременно документировать опыт клиента и ключевые бизнес-решения до начала процесса разработки программного обеспечения. Создание такого документа позволяет донести стратегию до заинтересованных сторон, включая участников вашей собственной команды. Он позволяет определить поток клиентов и заранее обсудить ключевые решения.

Используя документ WBD, вы можете зафиксировать все предполагаемые функциональные возможности, которые клиент и/или заинтересованные стороны хотели бы реализовать с помощью данного продукта. Обычно это пишется с точки зрения получателя ценности продукта. Например, мы создали продукт, который предоставляет экспертные статьи о продуктах для клиентов, ищущих информацию об обзорах продуктов (помимо отзывов клиентов). Мы встроили одну из версий этого продукта в результаты поиска Amazon, например, если покупатель искал "лучшие телевизоры", мы выводили виджет в поиске (точнее, мы предлагали поиску Amazon возможность вывести статью). Один из клиентов сказал: "Как покупатель, я хотел бы видеть экспертные статьи об интересующих меня продуктах, когда я ищу товар. Я хотел бы видеть продукт, рейтинг, у какого издателя есть обзор на этот продукт, и "кусочек" информации из статьи, чтобы определить, хочу ли я продолжать искать". Это позволило нам предложить клиентам различные интерфейсы продуктов. Другой вариант использования: "Как клиент, я хотел бы видеть три лучшие статьи, связанные с продуктом, который я искал". Вы должны учесть мнение всех заинтересованных сторон, связанных с этим продуктом. В приведенном выше случае издатели являются очевидной заинтересованной стороной. Поэтому одним из вариантов использования было: "Как издатель, я хочу, чтобы мой бренд был ясен для клиента". Пример от команды партнеров может звучать так: "Как команде поиска, нам нужен ранжированный набор виджетов статей, отправленных через наш API в течение X миллисекунд". Вы можете рассматривать другие команды, такие как юридическая, финансовая, PR, операционная и другие группы в качестве заинтересованных сторон, на основе которых вы можете создавать сценарии использования.

Затем вы можете расставить приоритеты всех вариантов использования, чтобы сформировать минимальный жизнеспособный продукт (MLP – minimal loveable product). Некоторые организации используют термин "минимально жизнеспособный продукт (MVP – minimal viable product)" в качестве первой итерации продукта. Этот термин активно обсуждался в Amazon, и было решено, что минимальная планка – это продукт, который понравится клиентам. Потом мы обсуждаем, какие фичи должны быть частью MLP, который затем станет набором фич, реализованных в первую очередь. Чтобы облегчить определение приоритетов фич, вы можете использовать тесты на удобство использования, чтобы получить данные о том, что клиенты считают важным, а что – приятным.

Задача документа бизнес-требований – быть глубже, чем документ WBD, и внести ключевой вклад в техническое проектирование. Этот документ будет описывать:

• Почему мы создаем этот продукт – почему этот продукт понравится клиентам и в чем заключается его бизнес-обоснование;
  
• Глубокое погружение в клиентский опыт. У вас должен быть полный поток клиентов и макеты для каждого этапа пути клиента – которые будут основаны на самых важных фичах, определенных на предыдущем этапе. Затем это можно использовать для формулирования предполагаемой функциональности и результатов для клиента. Обычно во время этого процесса в команде и с заинтересованными сторонами проводится несколько обсуждений дизайна и фич.
  
• Понимание того, как будут решаться проблемы и ошибки.
  
• Подробную стратегию эксперимента, дизайн и любые критические элементы, которые необходимо учесть (например, как будет осуществляться запуск эксперимента, чтобы обеспечить равное разделение между разработкой и контролем?).
  

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

Важно привлекать техническую команду на протяжении всего цикла разработки продукта. Если вы привлекаете техническую команду на этапе 6, то существует очень высокая вероятность того, что MLP будет отличаться (и будет лучше для клиентов) с их участием. У них будет понимание, вопросы и опыт, которые помогут определить, что можно создать для клиентов, что рискованно, а также возможность задать вопросы о том, почему клиентам понравится продукт. В то время как продакт-менеджер отвечает за выполнение шагов 1-5 (и впоследствии совместно отвечает за шаги 8-10), техническая команда берет на себя ответственность за шаги 6 и 7.

На этом этапе продакт-менеджеру важно получить рабочий график окончательного технического дизайна. Чтобы достичь этого, команда пишет черновики дизайна, рассматривает их с главными и senior-разработчиками и при необходимости привлекает команды партнеров. Они также включают план тестирования и разработки, чтобы успеть исправить все ошибки. Команда должна обсудить вопросы эксплуатационного/технического совершенства, а также дизайн и начало тестирования. Для обеспечения эксплуатационного/технического совершенства технической команде потребуется время для документирования, тестирования задержек, безопасности, конфиденциальности, обеспечения отказоустойчивости (т.е. тестирования нагрузки) и определения эксплуатационных показателей для понимания потребительского опыта и того, где и в какой степени он терпит неудачу.

Вопрос для команды заключается в том, сколько из этого она выполняет заранее, до начала тестов? Есть несколько основных компонентов, которые нельзя откладывать на потом: безопасность, конфиденциальность, доступность и операционные показатели. Усилия по обеспечению отказоустойчивости особенно важны для сценариев с высоким трафиком, но если продукт не будет запущен (потому что не пройдет тест), то эти инвестиции могут оказаться напрасными. В результате стоит различать, что важно для эксперимента с потребительским опытом, а что – для высокой посещаемости.

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

2) Продакт-менеджер также будет отвечать за пользовательское тестирование (UAT – user acceptance testing), в ходе которого вы проходите клик за кликом, чтобы убедиться, что опыт пользователя происходит так, как ожидается, в каждой локали (в программировании – набор параметров, включая набор символов, язык пользователя, страну, часовой пояс, а также другие предустановки, которые пользователь ожидает увидеть в пользовательском интерфейсе – прим. ред.) и на каждом языке.

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

Параллельно с шагом 7, продакт-менеджер берет на себя руководство потоком клиентов и UAT (UAT – user acceptance testing). Обычно проводится "проверка на наличие ошибок", когда члены команды проходят через весь процесс, нажимая на все, что только можно, чтобы:

1) убедиться, что все происходит так, как ожидается – не только правильность потока, но и правильность задержки и любых обратных действий;
2) попытаться сломать процесс и "пройти туда и обратно" по всему продукту, как это сделал бы клиент.

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

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

1) дают результат, который отражает "волю клиента". Лучше позволить клиенту самому решать, каким будет продукт и добавляет ли он ценность его опыту;

2) производят большее количество фич: вы показываете клиенту больше того, что он использует сегодня. Разнообразие фич на этапе тестирования поможет определить истинный набор фич.

Тесты автоматически и точно определяют фичи. Они являются золотым стандартом для определения инкрементного поведения клиентов. Однако за тестирования приходится платить, и в некоторых случаях очень дорого. Кроме того, нелегко получить действительно статистически значимые и правильные результаты. Существует множество способов, с помощью которых ваш тест может привести к смещению и, следовательно, к неверным результатам, например, проблемы с запуском тестирования, смещение клиентов, смещение опыта (например, если есть проблемы с задержкой или контролем). В некоторых случаях проводить тестирование не имеет смысла. Может быть, вы уже запустили продукт в 10 из 15 стран. Или, возможно, вы улучшаете производительность своего продукта (например, задержку), и в этом случае, возможно, не нужно проводить тест.

В дополнение к тестированию вам следует рассмотреть возможность сбора дополнительной обратной связи с клиентами. Теоретически, результаты теста должны сказать вам, нравится ли клиенту новый опыт – при условии, что у вас есть все необходимые метрики для точного измерения предпочтений клиента. Однако определять и анализировать каждую метрику в ходе тестирования довольно сложно и дорого. Мы провели тест в приложении Amazon с целью настройки потребительского опыта в зависимости от того, вошли ли они в приложение. Вход в приложение значительно улучшает опыт клиента – мы можем предоставить персонализированный опыт, основанный на его прошлом поведении, можем показать клиенту, что он уже купил, историю отслеживания заказа и т. д. Все показатели, полученные в ходе эксперимента, были в высшей степени положительными – они говорили нам о необходимости запуска этого нового опыта. Однако мы обратились к клиентам, которые участвовали в эксперименте, чтобы узнать их реакцию. Их ответ был довольно четким – им не понравилось. Клиентам приходилось делать это, чтобы совершать покупки, поэтому они были готовы пройти через все препятствия, чтобы получить то, что им нужно.

Также рекомендую записывать результаты тестирования и отзывы клиентов. Я всегда говорю своей команде, что единственный провал, которого мы можем достичь, – это не учиться. Мы можем не запускать новый продукт, основываясь на результатах тестирования и отзывах клиентов, но я считаю тест успешным, если мы узнаем больше о том, чего хотят клиенты и что мы можем сделать по-другому в будущем. Эти знания могут быть использованы на этапе 1 для разработки будущих фич продукта и новых программ.

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

Для полноты картины вы можете создать матрицу RACI для каждого этапа процесса. Этот фреймворк определяет, кто является ответственным за каждый шаг: есть только один человек, ответственный за владение шагом, и он уполномочен назначать задачи и сроки другим людям. Ответственный (Responsible) за задачу – это тот, кто несет ответственность за выполнение задачи. Подотчетный (Accountable) выполняет работу по заданию. В моих командах R и A (Accountable – Подотчетный), как правило, одни и те же люди. Это несколько спорно, поскольку матрица RACI предполагает, что R и A должны быть разными людьми.

Консультирующие (Consulted) лица – те, кто участвует в выполнении задачи до ее завершения. Это могут быть эксперты (например, главные разработчики, старшие конструкторы), которые могут предоставить обратную связь перед тем, как отметить выполнение задачи.

Информированные (Informed) о задаче или решении – это заинтересованные лица, которым необходимо понять результаты и внести изменения или дополнения.

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

Раз в две недели мы проводим обзор дорожной карты, где рассматриваем состояние каждого продукта, и если есть риски, они отражаются здесь. При необходимости мы назначаем последующие встречи для решения проблем: как устранить риск и/или вернуть проект в сроки. Техническая команда движется параллельно (например, планирование спринта раз в две недели, ретроспективы, ежедневные совещания), который облегчает выполнение шага 7.

Конечно, в цикле управления продуктом существует множество рисков:

1) Отказ от отношения к данным как к продукту.
Существует три типа данных, критически важных для каждого продукта:

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

Продакт-менеджеры должны относиться к этим данным так же, как и к самому опыту – работая в обратном направлении. Метрики – это просто сбор данных. Какие метрики позволяют определить, является ли опыт успешным? Оказывает ли пользовательский опыт ожидаемое воздействие? Затем вы работаете в обратном направлении, определяя критерии успеха по данным, которые вам нужны, как часто они вам нужны и какие срезы данных вам необходимы (по странам, по сегментам клиентов, по типам устройств, по операционным системам и т.д.), чтобы понять, как разные клиенты реагируют на продукт. Затем вы закладываете время на запись нужных данных, строите конвейеры для сбора данных и создаете приборные панели для отображения метрик. Часто при запуске продукта, возникает проблема, и все ищут друг у друга данные, чтобы лучше понять, что происходит с клиентом. Чтобы избежать этого, относитесь к данным так же, как к клиентскому опыту, и создайте специальные рабочие потоки для записи и надлежащего отображения данных.

2) Недооценка затрат на координацию.
Проще говоря, мы все не умеем оценивать, сколько времени потребуется на выполнение задачи. Суммируйте это по всем задачам, и продукт будет значительно задержан. Даниель Канеман и Амос Тверски описали заблуждение планирования в своей книге "Думай медленно… решай быстро", где подробно изложили свои аргументы и доказательства того, что люди склонны недооценивать количество времени, необходимое для выполнения будущей задачи, отчасти из-за того, что полагаются на слишком оптимистичные сценарии выполнения.

По моему опыту, риск значительно возрастает, если вы зависите от другой команды, или ваш продукт привлекает другую команду, вполне возможно, что возникнут проблемы, и их решение может занять значительное время. Мы сталкивались с этим бесчисленное количество раз, и каждая была немного разной. Главное во всех этих случаях – сначала определить, где могут возникнуть проблемы, а затем обеспечить как можно меньшую задержку между выявлением проблемы и доведением ее до руководства (при необходимости), чтобы добиться ее решения. Задайте следующий вопрос: имеют ли обе стороны полную информацию? Если нет, получите все необходимое как можно скорее и поделитесь ею. Если у вас есть полная информация, но вы все еще не согласны, передайте вопрос руководству. Это позволит свести к минимуму "мертвое" время, не приносящее ценности, и согласовать ожидания.

3) Культуры, не приемлющие плохих новостей и/или не имеющие механизмов для выявления рисков.
Мне приходилось слышать, как люди называют статус цели "арбузом", т.е. зеленый снаружи и красный внутри. Это сигнал о том, что культура не склонна к выявлению рисков и проблем. Конечно, естественная человеческая тенденция – не хотеть сообщать плохие новости, но если не решать эти проблемы с самого начала, это может принести гораздо больше проблем в будущем.

Сложно создать культуру, которая поощряет обнародование плохих новостей, и так легко создать противоположную культуру. С точки зрения команды, любой намек на то, что плохие новости будут восприняты негативно, приведет к поиску способов скрыть проблемы – или к поиску данных, которые показывают более радужную картину, чем то, что происходит на самом деле. Решение этой проблемы аналогично решению других культурных проблем: руководство должно показать пример и снова и снова подкреплять его. Культура строится кирпичик за кирпичиком, и каждый кирпичик – это основополагающий момент, когда лидер находит время, чтобы подтвердить и сформулировать, почему решения принимаются именно так, как они принимаются. В этом случае лидеры должны поощрять участников команды за то, что они преодолевают сложные ситуации, и напоминать им, почему это важно делать. Лидеры должны "быть в одной лодке" со своей командой, помогая им решать проблемы. Возможно, придет время поговорить о том, почему проблема была поднята поздно или неполноценно. Но в таком случае это будет еще одна проблема, которую нужно решить. А не игра в вину и стыд.

Если вы хотите освоить продуктовый подход, завести полезные знакомства и довести свой продукт от идеи до прототипа, то можете оставить заявку на наш тренинг по Product Management.

Вы научитесь:

1. Разбираться в юнит-экономике
Мыслить как предприниматель и понимать бизнес-контекст, управлять стратегией продукта, рассчитывать Unit-экономику, создавать Go-to-market-strategy

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

3. Проводить клиентские исследования
Проводить клиентские исследования/JTBD-исследовани, анализировать тренды, рынок, конкурентов и находить прорывные идеи и другие возможности, разрабатывать ценностное предложение

4. Запускать новые продукты
Создавать стратегию развития продукта, запускать новые продукты и решения от прототипа до MVP

5. Разрабатывать ценностное предложение
Определять продуктовые метрики и ориентироваться на них, ставить цели по OKR, создавать видение продукта, разрабатывать ценностное предложение, применять методологию Product Led Growth

6. Работать в команде
Взаимодействовать с продуктовой командой

Тренинг Product Led Growth на практике:

Как создавать продукты, которые будут сами себя продавать? Постройте стратегию, ориентированную на продукт, без привлечения холодных лидов и с минимальными вложениями в рекламу!

В результате обучения вы:

Узнаете:

• Как работают Marketing Led Growth, Sales Led Growth и Product Led Growth
  
• Какие компании смогли захватить рынок с помощью PLG и почему
  

Поймете:

• Как применить 5 факторов роста для привлечения клиентов
  
• Почему для масштабирования важен рост за счет продукта
  

Изучите:

• Продуктовые инструменты для достижения Product Led Growth
  
• Ключевые факторы для роста клиентов по PLG
  

Разработаете:

• 10Х преимущества своего продукта и условия для кратного роста по Product Led Growth