Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

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

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

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

План и отдел продаж

Невозможно говорить о коммуникации, не упомянув о плане. Когда я произношу слово «план», менеджеры сразу же кривятся. Компании испытывают трудности в этой области, потому что в прошлом они создавали диаграммы Ганта, а эти диаграммы в основном гласят: «Эту функцию мы разработаем к 18 января, а эту – к 20 марта». Зачастую план уже утвержден и не подлежит изменениям. Все это приводит к неприятностям, ведь получается, что вы пообещали, а выполнить обещание не можете.

Вместо того чтобы воспринимать план как диаграмму Ганта, вы должны рассматривать его как объяснение стратегии и текущей стадии развития вашего продукта. Это объединяет стратегические цели с темами работ и вытекающими из них результатами. Для этого план должен постоянно обновляться, особенно на уровне команды. Вот почему в Produx Labs мы называем их «живым планом».

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

Одним из замечательных ресурсов для определения того, как составить план, является книга К. Тодда Ломбардо и Брюса МакКарти «Карта продукта: перезапуск». Это глубокое практическое руководство по созданию отличных планов для вашей компании. Обычно они состоят из нескольких ключевых частей:

• тема;

• гипотеза;

• цели и метрики успеха;

• этап разработки;

• любые важные вехи.

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

Эксперимент

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

Альфа

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

Бета

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

Фаза общедоступности (Generally Available (GA))

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