Почему игнорирование Product Discovery ведёт к провалу

Недавно я был на Product Camp и провёл кучу времени в общении с другими продактами. Знаешь, что меня удивило? Многие продакты либо очень мало уделяют Discovery, либо вообще пропускают этот этап. Это показалось мне тревожной тенденцией. В ходе разговоров стало ясно, что большинство считает Discovery чем-то вроде необязательной «галочки», которую можно просто проскочить. Люди уверены, что реальная работа начинается с разработки, а не с исследования. Но вообще-то это не так.

Чаще всего Product Delivery составляет 3/4 всей продуктовой работы, а Discovery остаётся той самой 1/4, которой часто пренебрегают. Хотя именно на этапе Discovery закладываются основы для успешного продукта: он позволяет глубже понять проблемы пользователей и найти оптимальные решения ещё до того, как начнётся разработка. Игнорируя этот этап, мы увеличиваем риски и вероятность того, что конечный продукт не оправдает ожидания. Если ты решил не читать дальше, то давай договоримся хотя бы об одном: лучше хоть какое-то Discovery, чем никакого.

Product Discovery — это процесс снижения рисков через исследование и тестирование гипотез. Его цель — убедиться, что ты решаешь важные проблемы наилучшим возможным способом до того, как начнёшь писать код.

Когда появляется новая идея, уровень неопределённости зашкаливает: неизвестно, насколько проблема значима для пользователя, является ли предложенное решение жизнеспособным с точки зрения бизнеса, и можно ли его вообще реализовать. Discovery помогает снизить эти риски до приемлемого уровня.

Основные элементы Product Discovery

1. Проверка гипотез: в Discovery важно убедиться, что:

• Проблема значима для пользователей (desirability).

• Решение поддерживает бизнес-модель и имеет потенциал для роста (viability).

• Оно технически осуществимо с учётом доступных ресурсов и технологий (feasibility).

Эти три штуки: желаемость, жизнеспособность и осуществимость (DVF) — основа успешного Discovery. Ты должен сфокусироваться на этих трёх аспектах, прежде чем запускать полную разработку.

Часто Discovery представляется как линейный процесс: сначала мы изучаем проблему, потом находим решение, тестируем гипотезы и идём в Delivery. На самом деле, всё сложнее. Discovery — это постоянный цикл дивергенции и конвергенции: ты расширяешь возможности, исследуешь разные пути, а затем сужаешь их, принимая решения.

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

Здесь начинается самое интересное - демократизация исследований. Discovery — это не задача отдельной исследовательской команды. За Discovery должна отвечать вся продуктовая команда. Почему? Потому что передача знаний между отдельными командами всегда рискованна. Информация теряется, детали упускаются, и к моменту, когда разработка начинается, оригинальная идея уже не кажется такой ясной.

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

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

Product Trio — это не отдельная команда, а часть кросс-функционального состава, который занимается как Discovery, так и Delivery. Это даёт гибкость и скорость в принятии решений и адаптации.

Задача Discovery — дать тебе уверенность в следующем шаге. Нет универсального показателя завершённости Discovery, но существуют контрольные точки:

1. Насколько ты уверен в своей гипотезе? Если уверенность высока, пора двигаться вперёд.

2. Ты готов к риску? Чем выше риск, тем глубже нужно исследовать.

3. Как быстро ты можешь делать итерации? Если ты способен быстро протестировать решение и адаптироваться, не нужно задерживаться на Discovery слишком долго.

4. Насколько легко можно откатить решение? Если это «двусторонняя дверь» (решение легко изменить), можно двигаться быстрее.

Главное — не застревать в Discovery бесконечно. Если ты не можешь набрать достаточно уверенности, чтобы перейти к разработке, возможно, стоит пересмотреть идею.

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

Умение сказать «нет» идее, которая кажется заманчивой, но не приносит ценности или не выполнима, — это также часть работы продакта. Непринятые решения экономят время и ресурсы, которые можно направить на более перспективные возможности.

Если ты хочешь сделать свой Discovery более эффективным, начни с малого: короткие, но глубокие интервью с пользователями, быстрая проверка гипотез, прототипы и тесты. Главное — помни, что даже минимальные усилия в Discovery могут спасти тебя от больших ошибок в Delivery.

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

Ну и, как всегда, если есть желание поговорить более предметно — всегда рад обсудить это за чашкой кофе, будь то онлайн или оффлайн. Забронировать колл со мной можно прямо здесь.