Product discovery: исследование продукта

Product discovery (продуктовое исследование, или дискавери) — это этап работы над продуктом, на котором команда выясняет, что вообще стоит строить, прежде чем начать это строить. Смысл дискавери в том, чтобы отделить идеи, за которые пользователи проголосуют деньгами и вниманием, от тех, что провалятся, — и сделать это дёшево, на исследованиях и прототипах, а не дорого, на готовом продукте. Product discovery отвечает на вопрос «делаем ли мы правильную вещь», тогда как последующая разработка (delivery) — на вопрос «делаем ли мы вещь правильно». Пропустить дискавери — значит рисковать месяцами работы над тем, что никому не нужно.

Что такое product discovery

Большинство продуктовых идей не работают. Это не пессимизм, а статистика: даже у сильных команд значительная часть гипотез не подтверждается. Проблема в том, что узнать об этом можно двумя способами — дёшево, проверив идею на исследовании, или дорого, выпустив её и увидев тишину в ответ. Product discovery — это выбор в пользу первого.

Ключевой сдвиг мышления: перестать спрашивать «как нам это построить» и начать с «а стоит ли это строить вообще». Команды-фабрики фич пропускают этот вопрос и меряют успех числом выпущенных функций. Команды, которые делают дискавери, меряют успех решёнными проблемами пользователя.

Дискавери — не отдельный отдел и не разовый ритуал, а постоянная привычка проверять предположения перед тем, как вкладываться. Он тесно связан с подходами customer development и поиском product-market fit: все они про то, чтобы убедиться в спросе до масштабной разработки.

Четыре риска, которые снижает дискавери

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

• •Риск ценности (value). Захотят ли люди этим пользоваться и платить? Решит ли это реальную проблему? Самый частый убийца продуктов — построили то, что никому не нужно.
• •Риск юзабилити (usability). Смогут ли люди разобраться, как этим пользоваться? Ценная функция, которую невозможно понять, бесполезна.
• •Риск реализуемости (feasibility). Способна ли команда это построить с имеющимися технологиями, данными, ресурсами?
• •Риск бизнеса (business viability). Вписывается ли решение в бизнес: экономику, юридические ограничения, стратегию, бренд?

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

Dual-track: два параллельных трека

Dual-track (двухтрековый подход) — это способ организовать работу так, чтобы исследование и разработка шли не по очереди, а параллельно. У команды два непрерывных потока:

• •Трек discovery — постоянно исследует, проверяет гипотезы, готовит проверенные идеи.
• •Трек delivery — берёт проверенные идеи и превращает их в работающий продукт.

Частая ошибка — понимать это как две последовательные фазы: сначала полгода исследуем, потом год строим. Смысл dual-track ровно обратный: оба трека работают одновременно и постоянно. Пока разработка строит проверенное, дискавери уже проверяет следующее. Идея переходит из трека в трек, только пройдя проверку.

Это защищает от двух крайностей: от «фабрики фич», которая строит без проверки, и от «аналитического паралича», который бесконечно исследует и ничего не выпускает. Треки питают друг друга: данные из delivery рождают новые вопросы для discovery.

Методы дискавери

Инструментов у дискавери много, и выбирают их под конкретный риск и вопрос:

• •Проблемные интервью. Разговор с пользователями о их задачах и трудностях. Проверяют риск ценности: существует ли проблема и насколько она болезненна. Главное — расспрашивать о реальном прошлом опыте, а не о гипотетическом будущем.
• •Прототипы. От бумажного наброска до кликабельного макета. Позволяют проверить идею и юзабилити, ничего не разрабатывая. Прототип за день дешевле фичи за месяц.
• •Юзабилити-тесты. Пользователь выполняет задачу на прототипе или продукте, вы смотрите, где спотыкается. Проверяют риск юзабилити.
• •Fake door и лендинги. Показываете кнопку или страницу несуществующей функции и смотрите, сколько людей кликнет. Дёшево проверяет спрос до разработки.
• •А/Б-тесты. Сравнивают варианты на реальном трафике. Проверяют гипотезы количественно, когда функция уже есть.
• •Анализ данных. Существующая аналитика подсказывает, где болит и какие гипотезы вообще стоит проверять.

Мастерство дискавери — не в знании всех методов, а в умении выбрать самый дешёвый способ проверить самое рискованное допущение.

Как снижать риск до разработки

Дешевле всего ошибка стоит на этапе дискавери. Отброшенная гипотеза — это не провал, а сэкономленные месяцы разработки того, что всё равно бы не взлетело.

Типичные ошибки

• •Дискавери как фаза, а не привычка. «Сначала полгода исследуем, потом строим». Настоящий дискавери идёт постоянно, параллельно разработке.
• •Проверка только ценности. Убедились, что нужно, но не проверили, реализуемо ли и вписывается ли в бизнес. Все четыре риска важны.
• •Интервью про будущее. «А купили бы вы?» даёт вежливые фантазии. Спрашивать надо о реальном прошлом поведении.
• •Строить, не проверив рискованное. Команда закрывает мелкие лёгкие вопросы и обходит главный, самый страшный, — а он и решает судьбу продукта.
• •Дискавери без критерия успеха. Тест провели, но заранее не договорились, что считать подтверждением, — и трактуют результат как хочется.
• •Паралич исследований. Бесконечно проверяют и ничего не выпускают. Дискавери — чтобы решать быстрее, а не чтобы прятаться от решений.

Итог

Product discovery — это дисциплина проверять, стоит ли строить, до того как вложены месяцы разработки. Работайте с четырьмя рисками, ведите дискавери и разработку параллельно по принципу dual-track и всегда бейте в самое рискованное допущение самым дешёвым тестом. Отброшенная на исследовании гипотеза — это не потеря, а экономия. Как продуктовые команды выстраивают дискавери и снижают риск на практике, разбирают на профильных деловых мероприятиях, где практики делятся живыми кейсами проверенных и провалившихся гипотез.