В этой статье Евгения Черкашина, CEO humex и партнер практики Discovery в red_mad_robot, расскажет, зачем тестировать гипотезы и использовать метрики и как выстраивать работу в команде
Эту статью написал участник сообщества
Евгения Черкашина
CEO humex и партнер практики Discovery в red_mad_robot
Редакция «Бизнес-секретов» бережно сохранила авторский стиль, орфографию и пунктуацию — наши модераторы ничего не меняли
Написать статьюВ этой статье Евгения Черкашина, CEO humex и партнер практики Discovery в red_mad_robot, расскажет, зачем тестировать гипотезы и использовать метрики и как выстраивать работу в команде
Эту статью написал участник сообщества
Евгения Черкашина
CEO humex и партнер практики Discovery в red_mad_robot
Редакция «Бизнес-секретов» бережно сохранила авторский стиль, орфографию и пунктуацию — наши модераторы ничего не меняли
Написать статьюСоздать цифровой продукт, который приносит пользу и бизнесу, и пользователям, — это задача, выполнить которую легче, используя продуктовый подход. Рассказываем в статье, что такое продуктовый подход и как с его помощью создавать востребованные продукты.
This is продуктовый подход
Управление продуктом зачастую путают с управлением проектом, хотя разница между ними значительна. В проекте всегда заранее описан итоговый результат и можно построить четкий план действий. При создании продукта есть конечная цель, а пути ее достижения, как и требования к функционалу, необходимо определить в процессе.
Когда команда управляет продуктом в парадигме проектного менеджмента — пытается заранее определить образ результата и построить к нему план, жестко управлять бюджетом и сроками, то она старается максимально снизить неопределенность на старте. Это приводит к тому, что команда не имеет возможности и ресурсов тестировать гипотезы. В итоге кратно возрастает риск того, что продукт не понравится пользователям и не достигнет поставленных бизнес-целей.
Продуктовый подход помогает команде оптимальным способом создать продукт, который несет ценность пользователям и эффективно решает задачи бизнеса. На первых этапах команда двигается итерациями, постепенно снижает неопределенность при помощи постоянного тестирования гипотез, оптимально расходует ресурсы и оперативно корректирует движение на основании полученной обратной связи.
Чтобы продуктовый подход заработал в вашей компании, недостаточно только освоить инструменты. Необходимо развивать продуктовый майндсет, который ориентирован на глубокое понимание потребностей пользователей и бизнеса. Такой образ мышления помогает фокусироваться на ценности и принимать решения, брать ответственность за итоговый результат и достигать цели с минимальными затратами ресурсов. Продуктовый майндсет помогает команде максимально быстро провести эксперименты и в минимальные сроки пройти путь от идеи до запуска продукта.
Ключевые элементы продуктового подхода
Расскажу, из каких элементов состоит продуктовый подход.
Ценностное предложение. По данным американской аналитической компании CB Insights, 34% стартапов проваливаются по одной простой причине — запускаемый ими продукт оказался не нужен рынку. Предприниматели зачастую так верят в собственную идею, что не уделяют должного внимания этапу discovery. Потенциальные пользователи могут быть не готовы к инновационным продуктам и прорывным решениям, либо продукт может оказаться неактуальным для аудитории.
Поэтому сначала необходимо найти актуальную для пользователя проблему и только потом придумывать решение. Многие совершают ошибку, когда пытаются сделать наоборот и подгоняют решение под проблему: такая стратегия заведомо обречена на провал. Важно определить актуальную для пользователей проблему, обязательно проверить силу этой проблемы и изучить сценарий, чтобы понимать, ищут ли ваши клиенты ее решение и готовы ли они за него платить.
Ценность продукта для пользователя складывается из актуальности потребности, самого решения и ресурсов и усилий, которые пользователю необходимо потратить, чтобы этим решением воспользоваться. Чем сильнее пользовательская проблема или потребность, тем больше он готов отдать, чтобы получить решение. Найти этот баланс — значит создать то самое ценностное предложение.
Продуктовые гипотезы и их тестирование. MAANG-компании (Amazon, Apple, Netflix и Google) в неделю тестируют более 500 гипотез. Количество в этом случае переходит в качество — 9 из 10 гипотез не проходят проверку, но одна успешная окупает все усилия и расходы. Джефф Безос говорил: «Наш успех в Amazon зависит от того, сколько экспериментов мы проводим в год, в месяц, в неделю, в день».
Все продуктовые решения принимаются на основании результатов экспериментов, тестов и исследований. Количество экспериментов = качество продуктовых решений. Тестирование гипотез позволяет командам проверить работоспособность решения, протестировать и уточнить сценарии, а также лучше изучить пользователей и их сценарии.
Простой алгоритм проверки гипотез продуктовые команды знают как HADI-цикл, который состоит из 4 шагов: формулируем гипотезу (если мы сделаем A, то в результате получим В) — проверяем ее (делаем А) — обрабатываем результаты тестирования (оцениваем результат) — делаем выводы (если результаты окажутся В, то гипотеза верна).
Метрики как инструмент управления. Управление непрерывным развитием продукта требует регулярного отслеживания продуктовых метрик, поэтому все усилия команды по реализации задач должны вести к достижению одновременно и тактических, и стратегических показателей. И здесь важно понимать связь с реальными действиями: если мы сделаем вот так, то какая конкретно метрика изменится и как это отразится на бизнесе.
Метрики являются индикатором правильности совершаемых действий и помогают скорректировать направление работы над продуктом. Они могут включать такие показатели, как: LTV (количество денег, которое приносит клиент за время использования продукта), Churn Rate (отток пользователей), CSI (индекс удовлетворенности клиентов), конверсия, количество заказов, DAU (количество активных пользователей в день), GMV (общий объем товарооборота) и другие.
Принятие решений в продукте должно основываться на данных и метриках, а не на личном мнении команды или стейкхолдеров. Система приоритизации бэклога помогает команде оценить потенциальное влияние внедрения нового функционала на целевые метрики, а также определить функционал, который необходимо протестировать, если нет уверенности в том, как он будет влиять.
Какой должна быть команда при продуктовом подходе
В первую очередь команда должна быть кросс-функциональной, с достаточным уровнем необходимых компетенций, чтобы самостоятельно принимать решения и создавать продукт. Желательно, чтобы финальные решения принимало максимально ограниченное количество человек. Это важно, чтобы двигаться с нужной скоростью и не застревать на каждом этапе с бесконечным количеством согласований.
Стоит избегать:
- слишком большой команды, где участники вовлечены на небольшой процент времени;
- много команд, которые должны выдать результат одновременно, — очень сложно сделать так, чтобы команды работали синхронно;
- ситуаций, когда одну фичу делают разные команды, — в точках передачи информации от одной команды к другой будут потери;
- удаленной команды в разработке продукта с большой офлайн-частью.
Если говорить о личных качествах, то ключевую роль играет наличие опыта работы в продуктовой команде и с гибкими методологиями. Также важна зрелость, высокий грейд и экспертиза, необходимые для решения сложных задач. Это позволит вам не столкнуться с барьерами, с которыми часто сталкиваются молодые продуктовые команды: со страхом и сопротивлением к неопределенности и новому процессу, желанием делать только идеальный продукт и гиперуверенностью в своей экспертизе.
Все, кто работает над продуктом, должны верить в него, чувствовать ответственность за конечный результат, понимать, какую проблему пользователя они решают и как их действия влияют на целевые метрики.
Product Owner и его роль
Продуктовый подход держится на людях в команде, а любой команде необходим тот, кто будет отвечать за продукт, управлять бэклогом и всегда думать про ценность для пользователя и бизнеса. Эту роль обычно выполняет Product Owner (PO). PO как отдельная роль появилась не так давно и часто на нее назначают человека, который раньше был в роли Project Manager (PM). Поскольку управление продуктом и управление проектом имеют ряд существенных отличий, роли также отличаются.
PO управляет жизненным циклом продукта от идеи до запуска и последующей поддержки. Он выстраивает приоритеты, формулирует гипотезы, проводит тестирования, управляет командой разработки и выясняет потребности пользователей. PO — это человек, который сфокусирован на стратегии, бизнесе, пользователях, рынке, метриках. Он оценивает эффективность продукта, чтобы определить, какие функции нужно добавить или улучшить.
PM управляет проектом, у которого есть понятная и конечная цель, для достижения которой существуют конкретные инструменты. Его задача — минимизировать риски и в заранее обозначенный срок обеспечить результат заданного объема и качества.
Обе роли нужны и важны в продуктовой команде, но не всегда их выполняют разные люди. На этапе запуска продукта команда должна быть небольшой и эффективной. В этом случае PO отвечает и за бизнес, и за управление проектом. Однако если на более поздних стадиях развития продукта объединить две роли в одном человеке, то будет страдать либо этап discovery, либо delivery. При росте команды важно не упустить момент, когда нужно выделить роли и построить эффективную организационную структуру. Также важно, чтобы PO умел доносить ценность продукта не только до пользователей и клиента, но и до членов команды.
Важно понимать, что продуктовый подход — это не какая-то магия или особое строение мышления. Это прежде всего опытная команда, правильно выстроенные процессы и подобранные инструменты. Именно эти составляющие помогают максимально снизить неопределенность, а значит — создать «тот самый» продукт.
