Product management: чем занимается продакт и карта трека

Продуктовый менеджер — не «главный по задачам в Jira», не «менеджер, который носит требования от бизнеса к разработке» и не «мини-CEO». Роль существует ради одного:

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

Всё остальное — интервью, метрики, RICE, роадмапы, A/B-тесты — инструменты под эту цель; если инструмент её не приближает, он превращается в ритуал. Ниже разберём проблему с первых принципов, посчитаем экономику роли явными формулами и кодом, а в конце — карта трека.

1. Проблема: почему без продакта не работает

1.1. Базовый факт индустрии

Идеи людей о том, что нужно пользователям, плохо предсказывают реальность. Это не мнение, а измеренная величина. Рон Кохави, строивший платформу экспериментов в Microsoft (а до этого в Amazon), публикует один и тот же результат больше пятнадцати лет: из идей, которые команды считали достаточно хорошими, чтобы довести до A/B-теста, примерно треть улучшает целевую метрику, треть не даёт эффекта, треть ухудшает (Kohavi, Tang, Xu, «Trustworthy Online Controlled Experiments», 2020). В зрелых, уже оптимизированных продуктах доля успешных ещё ниже.

Отсюда следует всё остальное. Если бы идеи срабатывали в 90% случаев, продакт был бы не нужен: хватило бы очереди задач и хорошего исполнения. При доле успеха около 1/3 главным активом становится скорость и дешевизна отсева неудачных идей — а это отдельная профессия.

1.2. Что бывает без этой функции: фабрика фич

Джон Катлер описал антипаттерн как «фабрику фич» — команду, которая измеряет успех количеством выпущенного, а не изменившегося («12 Signs You’re Working in a Feature Factory»). Симптомы: никто не помнит, что дала фича трёхмесячной давности; успех спринта равен «закрыли 34 story points»; решение принимается по должности просящего (HiPPO — highest paid person’s opinion); «делаем как у конкурента» без вопроса «а у него это работает?»; бэклог только растёт. Мелисса Перри называет то же состояние «ловушкой создания» — компания измеряет выход, а не результат («Escaping the Build Trap», 2018).

1.3. Экономика роли в одной формуле

Пусть за квартал есть бюджет B человеко-недель, фича стоит c недель, приносит V при успехе и 0 при провале, вероятность успеха p, цена недели работы — k. Без отсева делаем n = B/c фич с ожидаемой ценностью E = n·(p·V − c·k); при p = 1/3 это часто отрицательная величина — платим за три попытки, получаем одну. С отсевом долю бюджета α тратим на дешёвые проверки стоимостью c_e ≪ c и строим только прошедшее: стоимость ошибки падает с c до c_e. Ключевая асимметрия — c_e/c в реальности 1/20…1/100: интервью с пятью пользователями стоит два дня, фича — два месяца. Именно её продакт эксплуатирует профессионально; в разделе 6 посчитаем это строго.

2. Что такое продукт-менеджмент строго

2.1. Определение

Продуктовый менеджмент — функция принятия решений «что строить дальше» в условиях неопределённости, с ответственностью за бизнес-результат, а не за факт выпуска. Три элемента, без любого из которых роль вырождается: решения (продакт выбирает и, главное, отказывается; роль без права сказать «нет» — координатор), неопределённость (если ответ известен заранее — регуляторное требование, миграция БД — это проектная работа, см. трек Project management) и ответственность за исход (метрика, а не дата релиза).

2.2. Три линзы и четыре риска

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

Марти Каган разбивает то же самое на четыре риска, которые нужно снять до написания кода (SVPG, «The Four Big Risks»):

Два риска из четырёх — на продакте, и это ровно те два, которые дороже всего обнаружить поздно: технический всплывает на второй неделе разработки, а ценностный — через полгода после релиза, когда деньги уже потрачены.

2.3. Output vs outcome vs impact

• Output — «выпустили экран онбординга». Полностью под контролем команды.
• Outcome — «доля новичков, дошедших до первого платежа, выросла с 12% до 17%». Под частичным контролем, измеримо; это и есть предмет ответственности продакта.
• Impact — «выручка +8%, отток −2 п.п.». Под слабым контролем: влияют рынок, конкуренты, сезон.

Цель команды формулируется на уровне outcome. Роадмап из outputs («фичи A, B, C к марту») — главный признак фабрики фич; альтернатива — роадмап из проблем и результатов, подробно в статье Продуктовая стратегия и роадмап и у Мартина Фаулера в «Products Over Projects».

3. Кто есть кто: продакт, проджект, PO, аналитик

Самая частая путаница — «продакт = владелец бэклога». Разведём роли по предмету ответственности.

• Product Owner — роль внутри Scrum, определённая в Scrum Guide, а не должность и не «младший продакт». Проблема начинается, когда PO сводят к писателю тикетов: тогда решения о ценности не принимает никто (разбор Кагана).
• Продуктовое трио (продакт + дизайнер + инженер) — рабочая единица discovery по Терезе Торрес: решают втроём, иначе продакт становится узким горлышком (Product Talk). Проджект-менеджер же нужен там, где координация сама по себе дорога: много команд, подрядчики, внешние даты.

4. Как это работает: два цикла

Операционная модель современного продакта — dual-track: непрерывный discovery, идущий параллельно delivery, а не «фаза аналитики перед разработкой».

Почему не «сначала всё исследуем, потом всё построим»: пропускная способность треков разная. Discovery дешёвый — за неделю проверяется пять гипотез. Delivery дорогой — за неделю делается кусок одной фичи. Сцепив их в одну последовательность, вы заставляете дешёвый трек простаивать в ожидании дорогого, и скорость обучения падает в разы.

4.1. Двойной алмаз

Внутри discovery работает старая, но всё ещё лучшая мыслительная рамка — «двойной алмаз» Design Council (2004): дважды расходимся и дважды сходимся, причём первый алмаз — про проблему, а не про решение.

Типичная ошибка новичка — начать со второго алмаза: «давайте придумаем, как сделать уведомления умнее». Вопрос первого алмаза другой: «а точно ли проблема в уведомлениях, или люди уходят, потому что не понимают ценность на третий день?».

4.2. Жизненный цикл продуктовой идеи

Обратите внимание на два перехода, которых нет в фабрике фич: Откачена → Возможность (решение выкинули, проблему сохранили) и Сопровождение → Выведена. Продукт без явного удаления фич копит стоимость владения: каждая живая фича — это код, тесты, поддержка, место в интерфейсе и когнитивная нагрузка пользователя.

5. Приоритизация: главное ежедневное решение

Формально это рюкзак: задачи с ценностями v_i и стоимостями c_i, ёмкость команды C, надо максимизировать Σ v_i при Σ c_i ≤ C. Это 0/1 knapsack — NP-трудная задача, точное решение динамикой стоит O(n·C) по времени и памяти (Динамическое программирование). Но в продукте точное решение бессмысленно: v_i известны с погрешностью в разы. Поэтому все практические фреймворки — жадное приближение по отношению «ценность/стоимость» с разной начинкой в числителе.

Матрица «ценность/затраты» — грубый, но честный инструмент разговора со стейкхолдерами: она заставляет каждого произнести оценку ценности вслух. Строгие модели — RICE, ICE, Kano, WSJF — в статье Приоритизация. Минимальная реализация RICE:

from dataclasses import dataclass

@dataclass(frozen=True)
class Item:
    name: str
    reach: float        # сколько пользователей затронет за период (людей/квартал)
    impact: float       # 3=массивный, 2=высокий, 1=средний, 0.5=низкий, 0.25=минимальный
    confidence: float   # 1.0 = есть данные, 0.8 = есть свидетельства, 0.5 = догадка
    effort: float       # человеко-месяцы, включая дизайн, QA и аналитику

def rice(it: Item) -> float:
    """Ожидаемая польза на единицу затрат."""
    return it.reach * it.impact * it.confidence / it.effort

def plan(items: list[Item], capacity: float) -> list[Item]:
    """Жадный отбор по убыванию RICE в рамках ёмкости квартала.
    Время: O(n log n) на сортировку, память: O(n).
    Это приближение knapsack: на однородно мелких задачах почти оптимально,
    на одной огромной задаче может ошибаться на величину её стоимости."""
    chosen, left = [], capacity
    for it in sorted(items, key=rice, reverse=True):
        if it.effort <= left:
            chosen.append(it)
            left -= it.effort
    return chosen

backlog = [
    Item("Ускорить онбординг",  reach=12000, impact=2,    confidence=0.8, effort=1.0),  # 19200
    Item("Импорт от конкурента", reach=3000, impact=3,    confidence=0.5, effort=3.0),  #  1500
    Item("Тёмная тема",         reach=20000, impact=0.25, confidence=1.0, effort=1.5),  #  3333
    Item("Письмо о корзине",     reach=8000, impact=1,    confidence=0.8, effort=0.5),  # 12800
]
# plan(backlog, capacity=4.0) → онбординг, письмо, тёмная тема

«Импорт от конкурента» не влез в остаток 1.0 — классический промах жадного алгоритма: крупная ставка всегда проигрывает мелким, если смотреть только на отношение. Поэтому квартальную ёмкость заранее делят на корзины «мелкие улучшения» и «ставки». И вообще: RICE не даёт «правильный ответ», он делает оценки явными и обсуждаемыми. Спор «тёмная тема важнее импорта или нет» бесконечен; спор «impact = 0.25 или 3» конечен и часто заканчивается словами «а давай проверим». Главная ошибка — ставить confidence = 1 всюду и превращать модель в наукообразную ширму для уже принятого решения.

6. Главный навык: ценность информации

Вот та часть работы, которую можно записать математически и которая объясняет, зачем вообще нужны интервью и эксперименты. Фича стоит C, приносит V при успехе и 0 при провале, априорная вероятность успеха p. Есть дешёвая проверка стоимостью c_e, дающая зашумлённый сигнал: sens = P(сигнал положительный | фича хорошая), spec = P(сигнал отрицательный | фича плохая). Ожидаемая ценность информации (EVSI) — насколько вырастет ожидаемая прибыль, если сперва проверить.

def ev_without_test(p: float, V: float, C: float) -> float:
    """Строим, только если ожидаемая прибыль положительна; иначе не делаем ничего."""
    return max(0.0, p * V - C)

def ev_with_test(p, V, C, cost_test, sens, spec):
    """Байесовское обновление: тест меняет p, решение принимаем после сигнала.
    Сложность O(1) на идею, O(n) на бэклог из n идей."""
    p_pos = p * sens + (1 - p) * (1 - spec)           # P(сигнал положительный)
    p_neg = 1 - p_pos
    post_pos = p * sens / p_pos if p_pos else 0.0     # P(хорошая | положительный)
    post_neg = p * (1 - sens) / p_neg if p_neg else 0.0
    return (-cost_test
            + p_pos * max(0.0, post_pos * V - C)
            + p_neg * max(0.0, post_neg * V - C))

def evsi(p, V, C, cost_test, sens, spec) -> float:
    return ev_with_test(p, V, C, cost_test, sens, spec) - ev_without_test(p, V, C)

# Фича на 2 месяца команды (C = 2 млн), выгода при успехе 6 млн, шанс успеха 1/3.
# Проверка: 5 интервью плюс фейк-дор, стоит 60 тыс., отсеивает плохие идеи в 75% случаев.
args = dict(p=1/3, V=6_000_000, C=2_000_000, cost_test=60_000, sens=0.85, spec=0.75)
print(ev_without_test(1/3, 6e6, 2e6))   # 0.0
print(round(ev_with_test(**args)))      # 740000
print(round(evsi(**args)))              # 740000

Разбор результата — он контринтуитивен, и в этом вся суть:

• Без проверки E = 1/3·6 − 2 = 0: ставка ровно нулевая, компания «в среднем» не зарабатывает ничего и просто жжёт два месяца команды за лотерейный билет.
• Положительный сигнал приходит с вероятностью 0.45 и поднимает апостериорную вероятность успеха с 0.33 до 0.63 — ставка становится прибыльной на ≈ 1.78 млн. Отрицательный сигнал (вероятность 0.55) роняет её до 0.09, и мы не строим: теряем 60 тысяч вместо двух миллионов. Проверка ценой в 3% от стоимости фичи превращает нулевую ставку в ставку на 740 тыс.
• Ценность информации максимальна там, где решение на грани. При p = 0.95 проверка почти бесполезна (всё равно построите), при p = 0.02 — тоже. Отсюда правило: не тратьте discovery на очевидное, тратьте на спорное.

Это же объясняет, почему пяти интервью часто «достаточно»: цель не оценить p точно, а перевалить решение через порог p·V > C — точность нужна ровно такая, чтобы поменять решение. Техника интервью — в Discovery, статистика экспериментов — в MVP и A/B.

7. Данные: минимум, который продакт считает сам

Продакт не обязан быть аналитиком, но обязан доставать базовые числа без очереди в дата-команду. Минимум — воронка активации по когортам.

-- Отвечает на вопрос: «мы правда улучшили онбординг или это сезонность?»
WITH cohorts AS (
    SELECT user_id, DATE_TRUNC('week', created_at) AS cohort_week
    FROM users
    WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
),
steps AS (
    SELECT
        c.cohort_week,
        c.user_id,
        MAX(CASE WHEN e.name = 'profile_completed' THEN 1 ELSE 0 END) AS s1,
        MAX(CASE WHEN e.name = 'project_created'   THEN 1 ELSE 0 END) AS s2,
        MAX(CASE WHEN e.name = 'teammate_invited'  THEN 1 ELSE 0 END) AS s3
    FROM cohorts c
    LEFT JOIN events e
           ON e.user_id = c.user_id
          -- окно активации 7 дней: иначе старые когорты несравнимы с новыми
          AND e.occurred_at < c.cohort_week + INTERVAL '7 days'
    GROUP BY c.cohort_week, c.user_id
)
SELECT
    cohort_week,
    COUNT(*)                                        AS registered,
    ROUND(100.0 * SUM(s1) / COUNT(*), 1)            AS pct_profile,
    ROUND(100.0 * SUM(s2) / NULLIF(SUM(s1), 0), 1)  AS pct_project_of_profile,
    ROUND(100.0 * SUM(s3) / NULLIF(SUM(s2), 0), 1)  AS pct_invite_of_project
FROM steps
GROUP BY cohort_week
ORDER BY cohort_week;

Три решения приняты здесь намеренно и чаще всего делаются неправильно: когорты вместо «всего за период» (общая конверсия смешивает старых и новых и меняется от одного притока трафика); фиксированное окно в 7 дней (иначе у старых когорт больше времени на конверсию и график «улучшается» по чистой механике); пошаговая конверсия вместо сквозной (сквозные проценты прячут, на каком шаге течёт). Как устроить событийную модель — в треке Data engineering; что именно мерить — в Продуктовых метриках; как не обмануться результатом — в Аналитике.

8. Как это выглядит в проде

• Amazon: working backwards. До начала разработки команда пишет пресс-релиз будущего продукта и FAQ от лица клиента, без слова про технологии; скучный пресс-релиз — продукт не начинают («Working Backwards», Bryar & Carr, 2021).
• Платформа экспериментов как инфраструктура (Microsoft, Booking, Airbnb): решение «раскатывать или нет» принимает стат-критерий, а не совещание (exp-platform.com). Продакт отвечает за правильность метрики, а не за положительность результата. Условие такой работы — feature flags как норма: релиз и запуск разделены, дешёвый откат делает эксперименты возможными.
• Метрики активации не копируются. Публичные примеры вроде «7 друзей за 10 дней» у Facebook или «2000 сообщений» у Slack — не магические числа, а результат локального анализа: искали действие, сильнее всего коррелирующее с удержанием своей аудитории. Копировать стоит метод.
• B2B и платформенные команды. Пользователь — другая команда или интегратор, метрика — время до первой успешной интеграции, доля успешных вызовов API, поток обращений в поддержку. Интервью проще (клиенты доступны), количественных данных меньше: на 40 клиентах A/B статистически невозможен, решают качественные методы.

9. Типичные ошибки

1. Спрашивать «нужна ли вам такая фича». Люди отвечают вежливо и плохо предсказывают своё поведение. Спрашивать надо о прошлом: «расскажите, как вы делали это в последний раз» — основа JTBD (Christensen, HBR 2016).
2. Метрика без контрметрики. «Растим конверсию в подписку» → добавили тёмный паттерн → выросли и конверсия, и возвраты с жалобами. Целевая метрика всегда идёт с guardrail-метрикой.
3. Роадмап как обещание дат для фич, чья ценность не доказана: команда обязана выполнить обещание даже после того, как узнала, что делать этого не надо.
4. Discovery как разовая фаза. «Мы провели исследование в январе» — к маю оно устарело; discovery непрерывен и не единоличен: если с пользователями говорил только продакт, команда спорит с его пересказом — инженер и дизайнер должны быть на интервью лично.
5. Средние по всей базе. Средний чек и средняя сессия обычно не существуют: распределения тяжёлохвостые. Смотрите перцентили и сегменты.
6. Отсутствие явного «нет». Бэклог из 400 задач — не план, а способ публично ни от чего не отказываться. Здоровый бэклог — то, что команда реально сделает за 1–2 квартала.
7. Оптимизация локального максимума. Бесконечные A/B кнопок дают +0.3% и не спасают продукт со сломанной базовой ценностью; крупные ставки требуют другой техники — см. Стратегию и роадмап.

10. Откуда роль взялась

Линия важна не сама по себе: каждая волна добавляла инструмент под конкретную боль. Brand men — против размытой ответственности, Agile — против длинных спецификаций, Lean Startup — против дорогих провалов, continuous discovery — против устаревающих исследований. Когда инструмент применяют, не понимая исходной боли, получается карго-культ.

11. Карта трека

Трек устроен по стадиям цикла из раздела 4: сначала понять проблему (01, 06), затем измерить (02, 08), затем выбрать (03, 04) и наконец проверить и вырасти (05, 07). Читать можно подряд или точечно — каждая статья самодостаточна.

Смежные треки: Project management — сроки, риски, координация; DDD — единый язык бизнеса и кода, снижающий потери при передаче требований; Data engineering — откуда берутся данные.

12. Мини-итог

• Продакт существует, потому что большинство идей не работает, и дешёвый отсев ценнее быстрого производства. Предмет ответственности — outcome, а не output и не дата релиза.
• Из четырёх рисков продакт лично закрывает два самых дорогих: ценностный и бизнес-риск.
• Рабочая модель — два параллельных трека: непрерывный discovery и delivery за фича-флагами.
• Приоритизация — жадное приближение к NP-трудной задаче; смысл фреймворков не в точности, а в том, что они делают предположения явными. Ценность discovery максимальна там, где решение на грани: измеряйте ровно столько, сколько нужно, чтобы поменять решение.
• Хороший продакт узнаётся не по числу выпущенных фич, а по числу вовремя отменённых.

Источники

• Marty Cagan. Inspired (2nd ed.), Empowered — svpg.com
• Teresa Torres. Continuous Discovery Habits, 2021 — producttalk.org
• Melissa Perri. Escaping the Build Trap, O’Reilly, 2018; Eric Ries. The Lean Startup, 2011
• Kohavi, Tang, Xu. Trustworthy Online Controlled Experiments, CUP 2020 — experimentguide.com
• Christensen. Competing Against Luck, 2016; HBR про JTBD
• Bryar, Carr. Working Backwards, 2021 — workingbackwards.com
• John Cutler. 12 Signs You’re Working in a Feature Factory
• Martin Fowler. Products Over Projects
• Design Council. Framework for Innovation / Double Diamond
• Intercom. RICE · Scrum Guide · NN/g. Journey Mapping 101

Что дальше

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

Читайте: Discovery: интервью, JTBD, проверка проблемы