Найти тему
WTFwithService

Почему Product Discovery кажется ненужным (и что с этим делать)

Оглавление

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

Что такое Product Discovery?

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

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

-2

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

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

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

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

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

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

Процесс Discovery — это не линейная схема

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

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

WTF with SERVICE?!

Кто отвечает за Product Discovery?

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

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

Как работает Product Trio?

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

-3

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

Как понять, что Discovery завершён?

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

  1. Насколько ты уверен в своей гипотезе? Если уверенность высока, пора двигаться вперёд.
  2. Ты готов к риску? Чем выше риск, тем глубже нужно исследовать.
  3. Как быстро ты можешь делать итерации? Если ты способен быстро протестировать решение и адаптироваться, не нужно задерживаться на Discovery слишком долго.
  4. Насколько легко можно откатить решение? Если это «двусторонняя дверь» (решение легко изменить), можно двигаться быстрее.

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

Лакмусовая бумажка для Discovery: Сколько идей ты отказался реализовать?

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

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

Что делать дальше?

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

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

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

WTF with SERVICE?!