Я лид проджектов: где у продактов всё ломается

Мы собираем практику и смыслы продакт-менеджмента: от CustDev и JTBD до бэклога, онбординга и роста метрик. Даем простые чек-листы, рабочие примеры и разборы, чтобы вы быстрее принимали продуктовые решения. Без воды и хайпа — только то, что помогает делать продукт и карьеру сегодня.

проджектпродактдискавери

Я редкий гость в продуктовых каналах. Потому что я не продакт. Я лид проджектов - тот, к кому ваши решения приходят, когда их уже надо делать. И вот что я думаю с другой стороны.

Большинство продуктовых идей умирают не там, где вы думаете. Вы переживаете за дискавери. За то, правильную ли гипотезу взяли, ту ли метрику двигаете, верно ли поняли пользователя. Это важно, бесспорно. Но я из своего угла вижу другое. Идея чаще всего гибнет не на дискавери. Она гибнет на стыке. В момент передачи от продукта к деливери.

Расскажу, как это выглядит с моей стороны.

Приходит великолепная идея, она красивая, очень, верю вам. Что-то такое, выстраданное, с метриками и обоснованием. Но приходит как готовый монолит - вот это сделать, вот к такому сроку (да, и часто не от оценки разработки), такой некий «вертолет», как я его иногда еще называю. И я начинаю его дробить на реальность. И почти всегда всплывает одно из трёх.

  1. 1️⃣Технически это в два раза дороже, чем казалось в вашей голове и уже данным комитам CEO. И если бы мы поговорили раньше, на дискавери, нашли бы путь проще к той же цели. Но меня позвали, когда решение уже застыло. Ну и требования уже написаны и потрачено уже куча времени от момента идеи.
  2. 2️⃣ В идее зашито пять фич, а ценность несут две. Остальные три - это «ну раз делаем, давайте сразу». И вот эти три съедают половину срока. В большинстве случаев я сразу это замечаю и задаю вопросы, но если не я, то есть риск сделать то, что не несет ценность.
  3. 3️⃣Решение классное, но команда его не понимает. Не «что делать», это я объясню. А «зачем». И без «зачем» люди делают формально, без огня, и продукт получается технически правильный, но мёртвый.

Видите, в чём закономерность? Все три проблемы решаются одним. Подключать проджекта раньше. Не когда решение готово, а когда оно ещё не сформировано окончательно . Мы мысли по-разному. Вы видите ценность, рынок, пользователя. Я вижу зависимости, риски, реальную стоимость, состояние команды. Поодиночке один отвечает за дискавери, другой - за деливери. Вместе - получается синергия, которая дает результат.

И знаете, что обиднее всего? Когда сильный продакт с отличной идеей получает на выходе посредственный результат. Не потому что идея плохая. А потому что между «придумал» и «сделали» была глухая стена, и идея об неё разбилась.

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

Лучшие продукты, которые я видела, рождались не там, где продакт был гениальным. А там, где продакт и проджект думали вместе с самого начала.

А вы как работаете с проджектами? Берёте в команду с дискавери - или передаёте готовое решение «на сделать»? И где у вас чаще всего ломается путь от идеи до релиза? Автор:

Елена Кунина 😺 🐈‍⬛, у себя на канале «Проджект без штанов» пишу про РМ

Абстрактная картина: две танцующие фигуры в геометрическом стиле, красно-синие и жёлтые плоскости и тёмные линии.
Графичная абстракция с двумя танцорами и динамичными линиями.

Дискуссия

Anton
Согласен на 100% со всеми тремя пунктами. Всегда считал, что продакты чаще всего проваливаются именно потому, что они плохие проджекты. В каких-то командах это решается внедрением проджектов или delivery-менеджеров, но где-то за все отвечает сам продакт Но еще хотел отдельно пройтись по пунктам. 1. Если продакт отдает фичу в разработку, не получив оценку от разработки - это проблема. Фактически любой фреймворк приоритизации строится на оценке баланса Value и Effort. И без оценки Effort почти невозможно нормально отдавать фичу в разработку, потому что нет возможности корректно ее приоритизировать. Разве что это директива сверху, но тогда и разговор будет строиться совсем по-другому 2. Приоритизация — прямая ответственность продакта. Опять возвращаемся к пункту 1. И если продакт отдает фичи в разработку совсем без учета деливери реальности, то у меня это вызывает вопросы 3. А вот если команда не понимает "зачем мы тут все собрались", то это вообще провал. Доносить идею продукта, питчить ее, объяснять, почему это важно и какую ценность мы хотим получить - это прямая ответственность продакта. Если за него это делает проджект, то поздравляю: у вас очень сильный проджект, который фактически тащит часть продуктовой работы. Но тогда возникает вопрос, что в этот момент делает сам продакт
Кать, а ты правда agile коуч?
а как насчет того, чтобы это стало задачей проджекта - подключаться раньше? не ждать пока его позовут, а понимать что дискавери это его задача тоже?
ДЕЛАЙ КАК НИКТО
В разных компаниях по-разному настроены процессы, но хочется верить, что тезисы в посте утрированы, а не реальность:) если же реальность - звучит очень печально(( В моем опыте я всегда отвечала за реализацию, на некоторых крупных кросс-функциональных проектах на 5+ команд может быть РП для координации. Но не всегда. И в слове продакт-менеджер зашито слово «менеджер». Странно, в общем, что кто-то не умеет в это) Ещё лично я считаю, что продакт должен уметь в БА и хотя бы на джуновском уровне в СА. Этого хватит, чтобы когда на какой-нибудь встрече тебя спросят про сроки и нет никакой возможности сначала обсудить с командой, ты назвал адекватную цифру по верхней границе разумности. Ну и с опытом приходит понимание примерно что сколько может занять.
Елена Кунина. Проджект без штанов
ДЕЛАЙ КАК НИКТО
В разных компаниях по-разному настроены процессы, но хочется верить, что тезисы в посте утрированы, а не реальность:) если же реальность - звучит очень печально(( В моем опыте я всегда отвечала за реализацию, на некоторых крупных кросс-функциональных проектах…
Опыт разный и в разных компаниях, это собирательный пост)
Елена Кунина. Проджект без штанов
Кать, а ты правда agile коуч?
а как насчет того, чтобы это стало задачей проджекта - подключаться раньше? не ждать пока его позовут, а понимать что дискавери это его задача тоже?
100 процентов)))) Но только отвернешься и уже вертолет БТ принесли😅
Елена Кунина. Проджект без штанов
Anton
Согласен на 100% со всеми тремя пунктами. Всегда считал, что продакты чаще всего проваливаются именно потому, что они плохие проджекты. В каких-то командах это решается внедрением проджектов или delivery-менеджеров, но где-то за все отвечает сам продакт Но…
Спасибо, пункт 3 - последний вопрос в самое
Алексей Ф
В каком домене и каких компаниях на каждого продакта приходится по проджекту? Пока все намекает на дисфункцию орг дизайна и неэффективность процесса поставки ценности
Дима
ДЕЛАЙ КАК НИКТО
В разных компаниях по-разному настроены процессы, но хочется верить, что тезисы в посте утрированы, а не реальность:) если же реальность - звучит очень печально(( В моем опыте я всегда отвечала за реализацию, на некоторых крупных кросс-функциональных проектах…
Золотые слова в 2026-м году, когда надо быть чуть более гибким, чем когда-либо и понимать и даже закрывать как минимум несколько ролей, чтобы хороводить с контекстом в условиях сужающихся ресурсов)
Присоединиться к обсуждению →

Читайте так же