Понять основные практики, необходимые для проведения исследований, представить концепцию Discovery , чтобы показать, как быстро сформулировать гипотезу, методы проверки гипотез
Самый неэффективный способ протестировать бизнес-модель или идею продукта состоит в том, чтобы спланировать и создать полный продукт, чтобы увидеть, действительно ли существует предсказанный рынок для него. Частью проблемы является язык, который мы используем для описания процесса разработки продукта. Лучше перестать использовать слово «требования» при разработке продукта, по крайней мере, в контексте неопределенных функций. То, что у нас есть, это скорее гипотезы. Мы считаем , что конкретная бизнес-модель, продукт или функция окажутся ценными для клиентов. Но мы должны проверить наши предположения. Мы можем применить научный подход к проверке этих предположений, проведя эксперименты.
Мы измеряем воздействие через показатели экспериментов. Это тот момент, когда на сцену выходит хорошо подготовленный и проницательный процесс обнаружения продукта.
По своей сути, Product Discovery направлен на снижение неопределенности на основе данных в отношении проблем, которые стоит решить, и решений, которые стоит разработать, посредством серии нелинейных действий, проводимых межфункциональной командой.
В этом подходе есть два ключевых нововведения по сравнению с традиционной проектной работой. Во-первых, мы прекращаем использовать детальное планирование как способ управления рисками. Вместо этого мы находим клиентов и проводим "дешевые" эксперименты, чтобы выяснить, подходит ли наша предлагаемая бизнес-модель или продукт на самом деле и имеет ли ценность для них. Во- вторых, вместо того, чтобы создавать только один план, мы итерируем, проводя серию экспериментов, чтобы обнаружить соответствие продукта/рынка, поскольку мы ожидаем, что в условиях неопределенности наша первая идея вряд ли принесет плоды.
Это определение может показаться нелогичным, если у вас нет опыта проведения экспериментов в научном контексте. В экспериментальной науке результат измерения никогда не бывает просто одним значением. Это скорее представляет собой распределение вероятностей , представляющее диапазон возможных значений. Например, измерение моего положения с точностью до 1 метра гораздо ценнее, чем то же самое положение с точностью до 100 км. Смысл инвестирования в измерения в научном контексте состоит в том, чтобы уменьшить неопределенность в отношении фактического значения некоторой величины. Так, в частности, если мы выражаем наши оценки точными числами (в отличие от диапазонов), мы настраиваем себя на неудачу: вероятность того, что мы уложимся в дату через 6 месяцев точно с точностью до дня , практически равна нулю.
Вот несколько вопросов, которые вы можете задать себе, чтобы оценить свои исследовательские навыки:
Контролируемые онлайн-эксперименты
Каждая команда должна обладать полномочиями и необходимыми навыками для выдвижения гипотезы, разработки эксперимента, проведения A/B-тестирования и сбора полученных данных. Поскольку команды небольшие, это обычно означает, что они кросс-функциональны. Это не исключает наличия централизованных групп специалистов, которые могут оказывать поддержку продуктовым командам по запросу.
Финансирование не должно быть препятствием для проверки новых идей. Команды не должны требовать одобрения для расходования денег до определенного предела (например, лимита на месяц).
В растущей организации руководители должны постоянно работать над упрощением процессов и усложнением бизнеса, над повышением эффективности, автономии и возможностей мельчайших организационных единиц, а также над воспитанием новых лидеров внутри этих единиц.
Если мы собираемся применить тщательный экспериментальный подход, нам нужно изменить то, что мы считаем результатом нашей работы: не только проверенные идеи, но и информацию, которую мы получаем в ходе проведения экспериментов. Нам также необходимо изменить то, как мы думаем о разработке новых идей; в частности, важно работать небольшими партиями и проверять каждое предположение, стоящее за идеей, которую мы проверяем.
У некоторых людей возникают проблемы с поэтапным подходом к созданию продуктов. Распространенное возражение против экспериментального подхода заключается в том, что он приводит к локально оптимальным, но глобально субоптимальным решениям, и что он ставит под угрозу общую целостность продукта, убивая прекрасное целостное видение тысячей A/B-тестов.
Хотя, безусловно, можно получить уродливый, сверхсложный продукт, когда командам не удается применить целостный подход к пользовательскому опыту, это не является неизбежным результатом A/B-тестирования. Эксперимент не должен заменять видение вашего продукта. Скорее, это позволяет вам развивать свою стратегию и видение оперативно реагировать на реальные данные от клиентов используя ваши продукты в своей среде. A/B-тестирование не будет эффективным без видения и стратегии.
Есть еще два препятствия для использования экспериментального подхода к разработке продукта. Во-первых, планирование экспериментов сложно: мы должны предотвратить их взаимодействие друг с другом, применять оповещения для обнаружения аномалий и спроектировать их так, чтобы они давали достоверные результаты. В то же время мы хотим свести к минимуму объем работы, которую необходимо выполнить для сбора статистически значимых данных.
Наконец, научный подход к разработке продуктов и клиентов требует интенсивного сотрудничества между специалистами по продукту, дизайнерами и техническими специалистами на протяжении всего жизненного цикла каждого продукта.
Еще одной из наиболее распространенных проблем, возникающих при проведении исследований, является сосредоточенность команд, менеджеров по продуктам и организаций на управлении затратами, а не ценностью. Обычно это проявляется в чрезмерных усилиях, затрачиваемых на действия с нулевой добавленной стоимостью, такие как подробный предварительный анализ, создание бизнес-кейсов и т.д. Эти симптомы являются результатом сосредоточения внимания на максимальном использовании ("занятии наших дорогих людей") и сроках/бюджетах.
Эти препятствия являются причиной того, что мы настоятельно не рекомендуем людям применять инструменты, обсуждаемые в этой главе, без предварительного создания основ процессов управления продуктом.
Чек-лист вопросов: