Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта - читать онлайн книгу. Автор: Мелисса Перри cтр.№ 42

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

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

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

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

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

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

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

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

• тема;

• гипотеза;

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

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

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

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

Эксперимент

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

Альфа

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

Бета

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

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

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

Согласование терминологии не только помогает общению с руководителями, но и приносит пользу другим частям бизнеса. Плохо составленные планы являются источником большого напряжения между продакт-отделом и отделом продаж. Если бы мне давали монетку каждый раз, когда менеджер по продукту говорил мне, что ненавидит отдел продаж, мне бы не пришлось писать эту книгу. Я бы купила себе остров где-нибудь в южной части Тихого океана, где пила бы из кокоса целыми днями. Но, увы, жалобы – это не настоящая валюта.

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

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

Операционный отдел

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

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