Войти в систему
Войти с помощью соц. сетей:
Для многих компаний создание полноценной команды роста скорее утопия, чем реальность. Причин этому огромное множество — от особенностей бизнеса до банального нежелания руководства менять устоявшиеся процессы.
Цели по росту ложатся на продакт-менеджера, и задача в такой ситуации — выстроить системную работу над проверкой гипотез. Научный подход и решения, принимаемые на основе данных, помогут управляемо двигаться к целям, вместо того чтобы вслепую наращивать функционал продукта.
Вот несколько советов, с помощью которых можно проверять больше продуктовых гипотез.
Совет может показаться банальным, но, как ни странно, отсутствие времени — главная причина, которая мешает добиваться результата. Продакт-менеджер погрязает в операционной рутине, едва успевая выполнять задачи по взаимодействию со стейкхолдерами, составлению дорожной карты, описанию функционала и многому другому, что входит в ежедневный график работы. В таких условиях проверка гипотез становится эпизодическим актом и происходит только в моменты, когда удается разгрести завал в текущей работе. Об управляемом росте речь не идет.
Чтобы выстроить полноценную работу, нужно зафиксировать в календаре конкретный объем времени, который будет посвящен только гипотезам. Он варьируется в зависимости от ситуации, но занимает не меньше 20%. Один полный день в неделю или два дня по четыре часа — стартовый минимум, который позволит сделать процесс управляемым.
Многие менеджеры не видят смысла в том, чтобы поддерживать порядок в работе с гипотезами, потому что относятся к ним как к эфемерным идеям, большинство из которых не будет реализовано. До тех пор, пока гипотеза не сформулирована достаточно четко, так и есть. Но, как только вы заведете единые правила формулирования и выделите конкретный документ для записи, гипотезы обретут куда больший вес.
Есть разные способы формулирования гипотез. Например, шаблон «если… то…». В первой части вы пишете, что конкретно предполагаете сделать, во второй — какого результата вы ждете. Если вы записываете гипотезы по такому шаблону в одном документе, вам гораздо проще будет сравнивать их между собой и выбирать лучшие.
Генерация гипотез часто бывает индивидуальной работой продакт-менеджера. Это упущение, которое сильно мешает построить системный процесс. Старайтесь привлекать команду, не только когда возникают конкретные задачи по проверке, но и на предварительных этапах. Сделайте задачу по генерации гипотез общей для всех, включая аналитиков, разработчиков и тестировщиков. Вы удивитесь, насколько неожиданные и оригинальные идеи будут приходить от ваших коллег.
Поначалу команда может предлагать и записывать гипотезы в свободной форме, а вы будете переформулировать их по шаблону. Если это станет регулярной практикой, люди сами научатся формулировать гипотезы в едином стиле. Добавив к задаче по генерации также оценку и обсуждение, вы сможете усилить вовлеченность команды в работу. У разработчиков больше не будут возникать вопросы, зачем вы просите их вставлять в их прекрасный код очередные костыли, которые его испортят.
Многие гипотезы можно проверить, не меняя ничего в продукте. Существует несколько способов сделать это:
В основе гипотезы могут лежать причинно-следственные связи, существование которых можно доказать или опровергнуть, исследуя ретроспективные данные о продукте.
Проверить гипотезы, связанные с изменениями в интерфейсе, можно, изучив некоторое количество пользовательских сессий или проанализировав поведение пользователей через вебвизор.
То, что в России принято называть кастдев (CustDev, от Customer development). Общаясь с пользователями продукта и задавая им правильные вопросы (не о будущем), вы можете отсеивать многие гипотезы без изучения кода. Важно понимать, что с помощью интервью вы не получите статистически значимые результаты, но найдете подтверждение или опровержение выдвинутым гипотезам. Это поможет решить: продолжать развивать идею или перестать тратить на нее время и ресурсы.
Компания eBay проверила гипотезу о функционале индикатора количества оставшихся товаров через тестовую e-mail-рассылку. Zynga измеряла востребованность несуществующих игр, тестируя кликабельность рекламных баннеров. По аналогии с ними вы можете проверять гипотезы за пределами вашего продукта.
Худший способ проверить гипотезу — реализовать 100% функционала и посмотреть, что получится. Вы потратите много времени, ресурсов и энергии команды на задачу, которая принесет ожидаемый результат с вероятностью не больше 30%. Таково среднее количество подтверждающихся гипотез.
Если разработки не избежать, вы, как менеджер продукта, должны стремиться минимизировать усилия команды:
Команда приложения «Tutu.ru Автобусы» решала задачу повышения актуальности расписаний. Чтобы проверить гипотезу о том, что пользователи станут присылать фотографии через приложение, они не стали создавать функционал загрузки и обработки, а сделали e-mail-рассылку. В письме они предложили пользователям присылать фотографии расписаний через любой удобный мессенджер, и оставили контакты. Сотни людей прислали фотографии, понимая, что этим помогают сделать приложение лучше. Так команда продукта смогла подтвердить, что функционал действительно будет востребован и принесет пользу бизнесу.
О важности проверки гипотез для достижения целей по росту бизнеса знает каждый менеджер продукта. Но в России существует не так много компаний, которые занимаются этим системно.
Не бойтесь брать на себя инициативу и менять устоявшиеся корпоративные уклады. Эксперименты с процессами работы команды приносят бизнесу не меньше пользы, чем непосредственно эксперименты в продукте. Начав проверять больше продуктовых гипотез, делая это системно и регулярно, вы вплотную приблизитесь к созданию кросс-функциональной команды роста и в будущем сможете стать ее лидером.
Войти с помощью соц. сетей: