Автор данной статьи рассказывает, что такое Product Discovery и зачем он нужен. А также делится 13 способами, которые позволят выделить время команды на Product Discovery.
Автор статьи - Markus Müller.
Создание фичи или продукта - это самый дорогой способ его тестирования. Большинство продакт-менеджеров знают об этом, понимают ценность Product Discovery (“исследование продукта” - это процесс выяснения того, что же в конечном итоге предстоит создать - прим. ред.) и стремятся применить его на практике. Однако они застревают в бесконечной череде задач по поставке и управлению проектами.
Ниже приведены 13 способов, которые помогут вам выделить больше времени на Product Discovery, что в свою очередь позволит быстрее создавать лучшие продукты.
Давайте сначала проясним, что я имею в виду под Product Discovery. Это итеративный процесс, который состоит из исследований, экспериментов и концептуализации. Он позволяет уменьшить неопределенность вокруг возможности или идеи, чтобы убедиться, что правильная фича / продукт создана для правильной аудитории. Вот как можно визуализировать данный процесс:
При уменьшении масштаба исследование (discovery) и поставка (delivery) должны быть непрерывными и выполняться в параллельных циклах:
1. Понять и объяснить, почему Product Discovery имеет значение
Основная проблема Product Discovery: важно, но не срочно.
Product Discovery похож на здоровое питание или регулярные физические нагрузки. Если вы не занимаетесь этим регулярно, то не сразу заметите проблему, но как только вы ее заметите, изменить свои привычки будет нелегко. Например, вы можете игнорировать потребности клиентов в течение некоторого времени и притворяться, что ваш маркетинг не работает, ваше решение глючит, или какие-то фичи отсутствуют, пока у вас не закончатся деньги или вы не узнаете, что вы на самом деле не решили реальную проблему. Поставка, с другой стороны, является срочной и важной. Когда у ваших разработчиков нет работы, руководство нервничает из-за того, что самые дорогие сотрудники непродуктивны.
Ключевое изменение мышления для того, чтобы Product Discovery работал: эффекты (Outcome) над результатами действий (Output).
Большинство руководителей компаний спрашивают: "Как мы можем быстрее выпускать фичи?". Однако это неправильная постановка вопроса. Каждая фича, которую вы создаете, делает вашу организацию медленнее, потому что вы усложняете свою систему, которую вам придется поддерживать и внедрять для новых вещей, которые вы создадите. Таким образом, ключевой вопрос заключается в том, как сделать меньше функций (например, 7 вместо 10), но обеспечить, чтобы большее количество функций дало ожидаемый результат (например, 5 вместо 3). Методы Product discovery позволяют протестировать больше идей и повысить процент успеха тех, которые дойдут до реализации.
Другие важные принципы мышления Product discovery:
- Глубокое понимание основной проблемы (проблем) вместо привязанности к первому решению
- Выявление и устранение риска критических гипотез вместо немедленного принятия решения
- Непрерывные открытия вместо нерегулярных, длительных исследований
- Открытость к неудачам вместо страха ошибиться
- Совместные, межфункциональные открытия вместо изоляции и "эффекта гиппопотама" (HIPPOS - highest paid person’s opinion / мнение самого высокооплачиваемого сотрудника - прим. ред.).
Очень трудно найти время для Product discovery, если ваша исполнительная команда и лидер (лидеры) продукта не понимают, что такое Product discovery, почему это важно, и в конечном итоге имеют принципиально другое мышление по отношению к нему. Таким образом, нужно понять, почему исследование продукта и свойственное ему мышление важны. После того, как осознаете важность Product discovery, начните обучать других людей в вашей компании и экспериментируйте с методологиями исследования. Это будет медленно повышать осведомленность и готовность вкладывать время и деньги в Product discovery.
2. Включите Product Discovery в обсуждение дорожной карты
Вы не можете запустить Product discovery для каждой отдельной идеи/проблемы/возможности, которая есть у компании. Именно поэтому вам нужно сделать раннюю расстановку приоритетов, чтобы согласовать, какие возможности имеют больше шансов оказать влияние на ваши цели при разумных усилиях.Четко определите этап выявления возможностей в вашей дорожной карте и ограничьте количество возможностей, которые может выявлять одна команда одновременно. Это поможет вам сделать усилия по исследованию более заметными и управлять ресурсами в соответствии с ними.
3. Предоставьте команде возможность взять на себя ответственность за поставку
Дайте понять вашей исполнительной команде, что она отвечает за поставку, и что вы готовы оказать поддержку. Этот пункт имеет, пожалуй, самое большое влияние на высвобождение времени на исследование. Во многих компаниях продакт-менеджеры выступают в роли микроменеджеров проекта, которые заботятся о каждой детали поставки и поддерживают команду на протяжении всего процесса. Вы должны сосредоточиться на понимании проблем бизнеса и пользователей, которые вы должны представить команде в виде мощных эпиков (epics) и пользовательских историй (user stories), наряду с дополнительным контекстом ("почему"). Используйте команду для разработки концепции и тестирования решений. Убедитесь, что все понимают функциональные требования, необходимые для реализации этих решений. Вы не должны быть ответственным за технические тонкости и решения, если они не являются ключевым функциональным требованием. Например, если ваша новая фича - это публичный API, вы можете участвовать в его разработке. В большинстве других случаев вам лучше не вмешиваться.
Иногда нужно позволить вашей команде разработчиков столкнуться с ошибкой и позволить ей чему-то научиться из этого, даже если вы могли бы предотвратить ошибку. Если вы будете активно заботиться обо всех проблемах, это заставит команду почувствовать, что это не ее ответственность. Если вы видите, что команда столкнулась с проблемами и не может решить их, помогите ей разобраться в этом самостоятельно, задавая правильные вопросы: «Как мы можем упростить эту часть?» «Что является самым большим неизвестным?» «Что произойдет, если [факт] окажется неверным?».
Следующие 3 совета тесно связаны с этой темой, но идут на один уровень глубже.
4. Делегируйте операционное управление релизом
Наблюдение за всеми деталями релиза занимает очень много времени. Хотя вы, безусловно, должны участвовать в обсуждении релиза, особенно когда речь идет о развертывании более крупных инициатив, которые требуют тесного согласования с заинтересованными сторонами. Однако задача продакт-менеджера не заключается в том, чтобы обеспечить согласованность команды разработчиков или завершение интеграционного/регрессионного тестирования до релиза – поручите это своей команде.
Очень полезен простой канал Slack со всеми обновлениями релиза. Я предпочитаю различать три типа релизов:
- Мелкий (Hotfix): небольшие исправления, выпускаемые в продолжение незначительного или основного релиза. Полностью координируется командой.
- Незначительный (Minor): небольшие улучшения, исправления ошибок и изменения. Полностью координируется командой.
- Основной (Major): большие новые фичи/продукты. Один продакт-менеджер берет на себя руководство коммуникациями, а один разработчик - техническое руководство.
5. Делегируйте обеспечение качества
Обеспечение качества (Quality assurance/QA) - важный, но очень трудоемкий и сложный процесс. Вы, вероятно, узнали об этом на собственном опыте, когда заинтересованные стороны начали давить на вас после выпуска релиза с серьезными ошибками. После чего многие руководители проектов берут на себя роль аналитика QA. В некоторых компаниях есть отдельно выделенные специалисты по QA, в то время как в других компаниях эта обязанность возлагается на команду. Какой бы подход вы ни выбрали, технический руководитель (CTO) должен убедиться, что процессы, инструменты, численность персонала и менталитет для высококачественной поставки находятся на месте. Привлечение QA на ранних этапах (например, на этапе исследования и/или в самом начале новой инициативы) повысит качество и освободит ценное время для вас в дальнейшем. Стоит регулярно сверяться с QA и/или участвовать в тестировании основных критериев приемки стратегических фич, но нельзя брать на себя роль QA.
6. Сосредоточьте время на планировании и подготовке поставки
Если вы не уделите время правильному планированию, вы поплатитесь за это тем, что вопросы будут возникать постоянно, требуя вашего внимания. Вам придется бросить все, чтобы помочь команде “разблокировать” работу. Чем лучше работает процесс подготовки и планирования, тем больше вы сможете сфокусировать оставшийся спринт на Product discovery. Независимо от того, какой именно методологии вы следуете (Scrum, Kanban и т.д.), я предлагаю вам заняться подготовкой и планированием. Подготовка поможет вам в организации следующей сессии планирования, выявлении открытых вопросов, предотвращении чрезмерно объемных историй и доведении критериев принятия ваших историй до 80%. Я рекомендую разделить планирование продукта и техническое планирование. Во время планирования продукта вы согласовываете объем работ на следующий цикл, проходите через окончательные критерии приемки и согласовываете сложность ваших историй. При техническом планировании разработчики берут на себя ведущую роль, разбивая истории на технические задачи и согласовывая план выполнения на предстоящий цикл. В случае более крупных инициатив я обнаружил, что для завершения технического планирования разработчикам необходимо проводить отдельные последующие сессии. Обменивайтесь опытом с коллегами, читайте о лучших практиках и экспериментируйте со своим процессом, чтобы улучшить работу по планированию.
7. Делегирование дизайна продукта
Я консультировал бесчисленное количество руководителей, которые ожидают, что их менеджер по продукту возьмет на себя роль дизайнера продукта. Вы можете создавать электронные схемы, чтобы донести свои идеи. Вы, безусловно, можете выступать в роли тренера и лидера для младших дизайнеров. Однако хороший дизайн продукта - это работа на полную ставку. Хорошие дизайнеры берут на себя большую ответственность за исследования и пользовательское тестирование. Если у вас нет дизайнера или он недостаточно квалифицированный, вы обязаны сообщить об этом руководителю, так как вы не сможете оправдать ожидания, связанные с вашей ролью дизайнера продукта. Вы должны быть открыты для поддержки в области дизайна, но это означает, что вы пойдете на компромиссы в других частях вашей роли продакт-менеджера.
8. Обеспечьте регулярное проведение ретроспектив для повышения ответственности разработчиков
Регулярное проведение ретроспектив помогает улучшить подотчетность и расширить возможности команды разработчиков цикл за циклом. Ретроспектива позволяет команде сделать шаг назад от своего процесса и обсудить значимые улучшения. Это даст им возможность нести все большую ответственность за поставку, а вам - высвободить время для изучения новых тем. К сожалению, многие команды не проводят ретроспективу регулярно. Обсудите это с руководителем разработки, чтобы он помог наладить регулярное проведение ретроспектив (я рекомендую проводить ее каждые 2-3 недели). Более того, многие команды не могут определить четкие пункты действий и не выполняют их в начале следующего ретро. Участие фасилитатора в ретро-сессии поможет решить эту проблему.
9. Привлеките agile-коуча для поддержки команды поставки
Если вы чувствуете, что не справитесь с выполнением рекомендаций, описанных в данной статье, наймите agile-коуча для поддержки. Первый agile-коуч, которого мы наняли в N26, изменил ситуацию в нашей продуктовой команде. Мы не только улучшили работу по поставке, но и наконец-то смогли высвободить время для работы над идеями и исследованиями. Мы ждали, пока наша продуктовая организация вырастет до 4 команд, прежде чем нанять первого agile-коуча, но нужно было это сделать еще раньше. В зависимости от стажа вашей продуктовой команды и руководителей разработки, вы можете рассмотреть вопрос о найме внештатного agile-коуча, как только у вас появится более одной продуктовой команды. Agile-коуч, который может временно выполнять функции scrum-мастера, – это бесценная помощь команде. Однако я не думаю, что вам нужен постоянный scrum-мастер для каждой команды.
10. Не будьте единственным ответственным за Product discovery
Возложение всех обязанностей по поиску новых решений на себя в качестве продакт-менеджера не подходит для масштабирования и не приведет к оптимальным результатам. Вместо этого вам нужно взаимодополняющее трио специалистов по продукту, дизайну и разработке. Если ваш дизайнер продукта и разработчик также понимают важность Product discovery и свою роль в этом процессе, вы сможете обеспечить подотчетность и поддержку друг друга, чтобы высвободить время. В некоторых случаях к регулярной работе над Product discovery можно даже привлечь кого-то из отдела данных или маркетинга.
11. Внедрение планирования исследования для создания фокуса и согласования
Выделение времени на составление и планирование Product discovery требует определенных временных затрат, но дает ряд преимуществ. Качество и эффективность Product discovery повысятся. Кроме того, это поможет вам управлять ожиданиями и создать согласованность и заинтересованность. Планирование Product discovery - это более широкая тема, которая заслуживает отдельной статьи. Вкратце, соберите в одной комнате (или созвонитесь) всех сотрудников, которые могут быть ценными участниками процесса, и согласуйте следующие моменты вокруг возможности, которую вы хотите обнаружить:
12. Оптимизация операционки для предотвращения отвлечения внимания в последнюю минуту
Продуктовые команды должны регулярно пересматривать процесс планирования и поставки, чтобы стандартизировать и автоматизировать операционную деятельность по управлению проектами. Эти действия могут отнимать много времени и отвлекать, если они выполняются "в последнюю минуту". Два таких примера – перевод продукта для иноязычных пользователей и его отслеживание. Имейте четкий процесс определения, документирования, анализа и эффективного тестирования отслеживания. И начинайте думать об отслеживании, когда вы определяете требования. В противном случае вы либо забудете об этом и не сможете отследить успех вашей поставки, либо втиснете его в последнюю минуту.
Перевод и адаптация вашего продукта для иноязычных пользователей может быть очень трудоемким процессом, если вы не используете инструмент, который позволит вносить изменения несколькими щелчками мыши в живой системе без участия разработчика. Изменение формулировки занимает в 5 раз больше времени, если вам нужно создать и обработать заявку или загрузить и скачать файлы. Просто используйте специализированные инструменты, как phrase или smartling, и эта проблема не будет занимать ваше время.
13. Смиритесь с тем, что разработчики "не заняты"
Вместо того чтобы приступить к планированию чего-то непродуманного и рискованного, лучше быть открытым со своей командой и сказать им, что вам понадобится еще несколько дней. Преждевременное начало разработки новых фич приведет лишь к тому, что придется “тушить пожары”, или, что еще хуже, команда будет работать над тем, что в итоге окажется неактуальным. Agile подразумевает гибкость, поэтому вам не нужно ждать начала следующего спринта. При необходимости сдвиньте планирование на два дня назад. Не становитесь рабом своего процесса. Ваши разработчики могут использовать это время для работы над значимыми улучшениями. Они должны создать отдельный бэклог для технических улучшений, которые помогут команде стать быстрее и надежнее в будущем. Ваш Техлид будет управлять этим процессом и координировать его с вами.
Изучение и применение на практике:
Хотите научиться создавать востребованные продукты и продвигать их на рынке с помощью продуктовой методологии, актуальных инструментов и фреймворков?
Тогда можете оставить заявку на наш корпоративный тренинг по Product Management. Мы поможем вам найти прорывные идеи и быстро реализовать их до понятного рынку продукта
Если вы хотите стать Agile, тогда по ссылке ниже регистрируйтесь на очный тренинг “Agile Certified Professional”, который состоится 8-9 сентября в Москве!
Зарегистрироваться на тренинг!
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
