Pepelen
Продакт-менеджмент с нуля

Lesson

Discovery до delivery: сначала проблема, потом решение

Объяснить разницу между discovery (понять проблему) и delivery (построить решение) и почему нельзя начинать с фич.

1 / 6

Discovery и delivery: два режима работы продакта

Discovery и delivery: два режима работы продакта

Работа продакт-менеджера делится на два принципиально разных режима. Discovery — это понять проблему: провести интервью с пользователями, понаблюдать за их поведением, проанализировать данные. Delivery — это построить и поставить решение: написать спецификацию, запустить разработку, выпустить фичу. Правило простое: сначала discovery, потом delivery. Нельзя качественно строить решение, если вы не поняли, что именно болит у пользователя и болит ли вообще. Каждый час разработки — это деньги и время. Если вы строите не то, вы тратите их впустую. Главный анти-паттерн новичка — «прыжок к решению»: команда сразу обсуждает, какую фичу сделать, не потратив времени на проверку, реальна ли проблема и важна ли она для пользователей. Это выглядит как продуктивность, но часто заканчивается продуктом, который никто не использует. Признаки, что вы «прыгнули к решению»: обсуждаете детали реализации до того, как поговорили с пользователями; ваша «проблема» сформулирована как фича («нам нужна кнопка X»); у вас нет данных о том, как часто пользователи сталкиваются с этой ситуацией.
Lesson notes
Discovery и delivery: два режима работы продакта
Работа продакт-менеджера делится на два принципиально разных режима. Discovery — это понять проблему: провести интервью с пользователями, понаблюдать за их поведением, проанализировать данные. Delivery — это построить и поставить решение: написать спецификацию, запустить разработку, выпустить фичу. Правило простое: сначала discovery, потом delivery. Нельзя качественно строить решение, если вы не поняли, что именно болит у пользователя и болит ли вообще. Каждый час разработки — это деньги и время. Если вы строите не то, вы тратите их впустую. Главный анти-паттерн новичка — «прыжок к решению»: команда сразу обсуждает, какую фичу сделать, не потратив времени на проверку, реальна ли проблема и важна ли она для пользователей. Это выглядит как продуктивность, но часто заканчивается продуктом, который никто не использует. Признаки, что вы «прыгнули к решению»: обсуждаете детали реализации до того, как поговорили с пользователями; ваша «проблема» сформулирована как фича («нам нужна кнопка X»); у вас нет данных о том, как часто пользователи сталкиваются с этой ситуацией.
Discovery до delivery: сначала проблема, потом решение — Продакт-менеджмент с нуля