Что делает продакт в Фейсбуке? Часть 1, Часть 2, Часть 3 Нем | No Flame No Game

Что делает продакт в Фейсбуке?
Часть 1, Часть 2, Часть 3

Немного отвлекусь от основного топика - в комментариях на предыдущий пост развернулась интересная дискуссия на тему: "кажется, что продакт должен больше заниматься Product Discovery, а не Product Delivery".

Давайте разберемся

Для начала, дадим определение:
- product discovery - это "что мы делаем": на каких пользовательских проблемах мы фокусируемся и какое из потенциальных решений лучше всего закрывает проблему
- product delivery - это "как мы делаем": непосредственно, разработка и запуск решения.

(В ФБ у нас немного другой фреймворк, Understand-Identify-Execute, но это не особо важно, набор активностей примерно похож).

Обе эти стадии должны присутствовать в разработке любого продукта - тут сомнений нет. Вопрос в том, как это организовать с точки зрения разделения обязанностей: должна ли это делать одна команда или две разные. И вот здесь я категорически не согласна со второй опцией.

1. Discovery и Delivery - это две части одного процесса, конечная цель которого - увеличить ценность для пользователя с максимальным ROI. Конечно, есть отдельный тип исследовательских команд, которые исключительно фокусируются на прототипировании и поиске новых идей для бизнеса, но это совершенно другая история. Если мы говорим про типичную продуктовую команду, то процесс discovery и delivery часто происходит параллельно, а то и пересекается - все зависит от уровня уверенности и риска в конкретной гипотезе (вот неплохая статья на эту тему). Невозможно достичь Product Market Fit, не запустив продукт на реальных пользователей. Это значит, что даже если мы потратили месяцы на discovery, в процессе delivery мы узнаем еще миллион новых вещей, которые приведут к новым итерациям, переоценке сроков и рисков, а также trade offs.

Задача продакта - не "обязательно делать discovery", а смотреть на процесс полноценно от начала до конца и балансировать ресурс команды. Иногда более оптимально сократить время на процесс discovery и начать разработку с целью получить определенный сигнал от пользователей.

2. Для конечного качества продукта "как" не менее важно, чем "что". Почему при таком количестве похожих продуктов и фич одни взлетают, а другие нет? Многие из них решают одни и те же проблемы и даже выбирают похожие решения. Смысл продакт-менеджмента не в том, чтобы придумать идею с потенциалом (давайте это оставим консультантам), а чтобы максимизировать создание ценности на единицу времени. Если бы Apple раздавал всем бесплатные айфоны, у них, конечно, не было бы отбоя от желающих - но это был бы нерабочий бизнес. Задача продакта - направить каждый доллар, который заплатит пользователь, на решение самых важных для него проблем. Именно поэтому невозможно представить обсуждение "как" без участия продакта: понятно, что есть некоторые функциональные требования еще до начала разработки, но, как обсуждалось выше, по ходу дела появляются дополнительные инсайты и новая информация - на все это нужно реагировать и принимать решения.

Верно и обратное: ребята, которые обычно занимаются разработкой, обязательно должны быть вовлечены на стадии "что". Если у нас есть фича А, которая решает очень важную проблему, но воплощение займет 2 года, и фича Б, которая решает чуть менее важную проблему, но займет 2 месяца, довольно очевидно, как надо расставить приоритеты. Гораздо чаще же случается ситуация, когда разрыв в сроках не такой большой, и на оценку начинают влиять риски, зрелость технологий, качество кодовой базы и так далее. Чем раньше мы можем привлечь разработчиков к обсуждению проблем, тем больше времени мы сэкономим, не проверяя заведомо провальные идеи.