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