Фреймворк управления продуктом (Pragmatic Framework)

Продуктовый менеджмент легко свести к одной активности — «собираем требования» или «ведём roadmap», — хотя на деле это целый жизненный цикл: от понимания рынка и выбора возможностей до вывода продукта, обучения продаж и поддержки после запуска. Pragmatic Framework («Прагматичный фреймворк», Pragmatic Institute, ранее — Pragmatic Marketing Framework) — карта этого цикла: 37 областей деятельности, сгруппированных в семь категорий — Market, Focus, Business, Planning, Programs, Enablement и Support. Это не модель зрелости с уровнями 1–5, а чек-лист покрытия: он помогает увидеть, каких зон в вашей практике нет вовсе или они «принадлежат никому».

Продуктовый менеджмент — не одна роль, а полный цикл активностей; пробел в любой из них рано или поздно скажется на результате, даже если остальные выполняются блестяще.

Материал разбирает: откуда взялся фреймворк и как его читать (как карту покрытия, а не как процесс «шаг за шагом»); что известно из исследований успешности новых продуктов (Купер); два документированных примера продуктовых провалов — Amazon Fire Phone (2014) и Quibi (2020) — с оговорками о многофакторности причин; как оценивать зрелость без выдуманных шкал; метрики; типовые ошибки; и что делает и чего не делает фрейм OrgDevTools.

Происхождение и исследовательская база

Фреймворк разработан компанией Pragmatic Institute (в прошлом Pragmatic Marketing) — одной из старейших организаций, обучающих продуктовому менеджменту и продуктовому маркетингу; он развивается уже более трёх десятилетий и служит основой сертификационных и корпоративных программ. Институт описывает его как набор из 37 «блоков» (активностей и ответственностей), которые охватывают весь жизненный цикл продукта: от выявления рыночных проблем до бизнес-плана, запуска и поддержки. Официальные названия и формулировки активностей публикует институт; здесь описана логика категорий, а точный перечень и версию сверяйте с актуальными материалами Pragmatic Institute. Отдельной канонической книги-первоисточника нет.

Семь категорий, как они обычно описываются: Market — понимание рынка (исследования, сегментация, конкуренты, проблемы клиентов, анализ выигранных и проигранных сделок); Focus — фокусировка (выбор приоритетных возможностей, позиционирование, продуктовая стратегия); Business — бизнес-обоснование (экономика продукта, бизнес-кейс, ценообразование); Planning — планирование (дорожная карта, требования, взаимодействие с разработкой); Programs — программы вывода на рынок (запуск, маркетинговые кампании); Enablement — обучение и материалы для продаж и поддержки; Support — поддержка после запуска (обратная связь, метрики использования, жизненный цикл). Рыночные категории обычно относят к «стратегическому» блоку, а последние — к «тактическому».

Научная и практическая основа идеи «полного цикла» — исследования успешности новых продуктов. Роберт Купер в серии работ («Winning at New Products», 1986 и последующие издания; исследования NewProd) и в модели Stage-Gate показал, что важными факторами успеха оказываются уникальное и превосходное для клиента предложение, ориентация на рынок и «домашняя работа» на ранних стадиях — проверка рынка, определение продукта и технико-экономическое обоснование до начала разработки (подробнее — в материале о процессе разработки новых продуктов). Это соответствует логике Pragmatic Framework: категории Market, Focus и Business предшествуют Planning. Оговорка: выводы Купера получены на выборках компаний из опросов и анализируют связь практик с успехом, а не эксперименты; они показывают закономерности, но не гарантируют результата.

Сопоставление с другими подходами: фреймворк ближе к «карте компетенций и активностей», чем к процессу разработки. С ним дополняют: product-market fit и продуктовые метрики (что измерять), product discovery (как непрерывно проверять гипотезы), стратегию выхода на рынок (GTM) (Programs), продуктовую стратегию и дорожную карту (Focus и Planning), анализ выигранных и проигранных сделок (Market и Support). Отдельные подходы, например современная практика «product operating model» Мартина Кэгана, критикуют перегруженность ролью «выпуска функций»; Pragmatic Framework отвечает на вопрос «что должно быть покрыто», а не «как организовать команду».

Документированные кейсы

Ниже — два известных продуктовых провала. Причины таких историй многофакторны (рынок, конкуренты, экономика, время, организация), поэтому примеры используются только как иллюстрация того, какие категории фреймворка стоит проверять, а не как «доказательство» одной причины.

Кейс 1. Amazon Fire Phone (2014–2015): сильный запуск без убедительной причины выбрать

Amazon выпустила смартфон Fire Phone в 2014 году. В третьем квартале 2014 года компания отразила убыток порядка 170 млн долларов, связанный с Fire Phone (в том числе обесценение запасов, на конец квартала примерно 83 млн долларов запасов). Изначально устройство продавалось по 200 долларов при двухлетнем контракте с оператором AT&T, а затем, по сообщениям прессы, цену снизили до 99 центов. Одним из отмечавшихся препятствий была экосистема приложений: в магазине Amazon было порядка 240 тысяч приложений против более миллиона в Google Play, а ключевые приложения Google отсутствовали. В 2015 году продукт был снят с продажи.

Как читать через категории. Market и Focus: какую проблему пользователя решает телефон и почему его нужно выбрать вместо привычного (публикации отмечали, что отличительные функции, вроде трёхмерного интерфейса и распознавания объектов, не стали причиной покупки); Business: экономика продукта при снижении цены; Enablement и Programs: продажи через оператора и объяснение выгоды. Оговорка: анализ причин в публикациях расходится; здесь используется только урок о необходимости проверять весь цикл, а не одну сильную сторону продукта.

Кейс 2. Quibi (2020): большой бюджет и непроверенные допущения о рынке

Сервис коротких видео Quibi, основанный Джеффри Катценбергом и возглавляемый Мег Уитман, привлёк около 1,75 млрд долларов до запуска в апреле 2020 года. О закрытии объявили 21 октября 2020 года, работа прекратилась в декабре. По сообщениям прессы, компания ожидала 7,4 млн платных подписчиков в первый год, а к моменту закрытия их было порядка 500 тысяч; библиотеку контента позднее приобрёл Roku (менее чем за 100 млн долларов). Основатели указывали на пандемию, из-за которой пользователи оказались дома, а не «в дороге», ради которой продукт был задуман; критики называли и другие причины — конкуренцию, привлекательность контента, невозможность делиться отрывками.

Как читать через категории. Market: проверка гипотезы о ситуациях использования и о готовности платить (до запуска инвестировали огромные суммы); Business: расчёт подписчиков и экономики при слабом отклике; Programs: запуск в необычное время. Урок: чем больше вложения, тем важнее дешёвая проверка допущений рынка до масштабного запуска (см. MVP). Оговорка: детали и цифры даны по публикациям; причины остаются предметом дискуссии.

Кейс 3. «Домашняя работа» на ранних стадиях в исследованиях Купера

В исследованиях Купера успешные проекты отличались тем, что до начала разработки тратили больше усилий на предварительную оценку рынка и продукта, чётко определяли продукт и целевой сегмент и имели поддержку руководства; провальные проекты чаще пропускали эту фазу и начинали разработку по «идее». Это не «закон»: исследования основаны на опросах и оценках менеджеров и на самоотчётах, но их вывод согласуется с практикой: пробелы в Market, Focus и Business дороже всего обходятся, потому что обнаруживаются позже всего. Практический вывод: проверка покрытия должна начинаться слева — с Market.

Ключевые идеи и принципы

1. Принцип: семь категорий жизненного цикла

   Market → Focus → Business → Planning → Programs → Enablement → Support. Порядок отражает логику: сначала понять рынок и выбрать возможность, затем обосновать экономику, спланировать, вывести на рынок, подготовить продажи и поддерживать. На практике категории работают циклически: обратная связь из Support возвращается в Market и Focus.

2. Принцип: карта покрытия, а не шкала зрелости

   В отличие от моделей зрелости с уровнями (OPM3, CMMI), фреймворк не даёт «баллов зрелости»: он отвечает на вопрос, какие активности присутствуют. Поэтому удобны простые оценки по каждой активности: «нет», «эпизодически», «регулярно», «измеряется». Числовые сравнения между периодами — условны и зависят от вашей шкалы.

3. Принцип: сначала покрытие, потом глубина

   Команде полезнее сначала честно увидеть, какие из семи категорий вообще присутствуют в каком-то виде, чем доводить одну до идеала, игнорируя остальные шесть. Особенно важны категории, отсутствие которых обнаруживается поздно: Market и Business (их пропуск дорого стоит после запуска) и Support (обратная связь).

4. Принцип: ответственность за каждую активность назначена

   Для каждой активности нужен ответственный (не обязательно продуктовый менеджер): в малых компаниях один человек совмещает роли, в крупных функции делят продукт, маркетинг, продажи, поддержка, разработка. Пробел часто возникает на границе функций: «продажи думают, что этим занимается продукт, продукт — что маркетинг». Карта помогает зафиксировать владельцев.

5. Принцип: рынок как источник проблем, а не идей

   В логике фреймворка продуктовые решения исходят из подтверждённых рыночных проблем (для каких клиентов, насколько остро, сколько готовы платить), а не из внутренних идей или запросов отдельных клиентов. Инструменты: сегментация рынка, оценка размера рынка TAM/SAM/SOM, матрица конкурентов, интервью с клиентами и потерянными клиентами.

6. Принцип: метрики покрытия и результата

   Метрики по категориям: Market — число проведённых интервью и доля решений с рыночным обоснованием; Focus — доля инициатив, соответствующих выбранной стратегии и сегменту; Business — доля инициатив с бизнес-кейсом и проверкой допущений; Planning — предсказуемость поставки, доля работы по roadmap против срочных запросов; Programs — результат запуска (принятие, конверсия); Enablement — время выхода нового менеджера продаж на результат, доля сделок с использованием материалов; Support — время реакции на обратную связь, доля идей из обратной связи в roadmap, показатели использования и удержания. Общие показатели: удержание, рост, удовлетворённость (см. продуктовые метрики). Метрики помогают увидеть эффект пробела, а не заполнить таблицу.

7. Принцип: применение в организации (аналогия)

   Порядок: составить карту по 7 категориям; для каждой активности оценить наличие, регулярность и владельца; выбрать пустые категории и активности с самым высоким риском; добавить минимальную практику (например, ежеквартальные интервью для Market; шаблон бизнес-кейса для Business; обучающий материал для Enablement); закрепить владельцев; повторять оценку каждые полгода. Это рекомендации на основе практики и исследований, а не универсальный стандарт.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: концентрируются на Planning, пропуская Market и Business.

   Команда сразу переходит к дорожной карте и требованиям, не проверив рыночную гипотезу и экономику; планирование строится на непроверенных допущениях.

   Как избежать

   до перехода к Planning явно проверять покрытие Market и Business: проблемы клиентов, размер сегмента, экономика, бизнес-кейс.

2. Ошибка 2: Enablement и Support считают заботой других отделов.

   Обучение продаж и сбор обратной связи после запуска не входят в продуктовую практику; продукт хорошо спроектирован, но плохо продаётся и не улучшается по фактическому использованию.

   Как избежать

   закладывать эти категории в план, назначить владельцев и координацию между продуктом, продажами и поддержкой.

3. Ошибка 3: пытаются закрыть все семь категорий одинаково глубоко сразу.

   На раннем этапе это нереалистично и распыляет силы.

   Как избежать

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

4. Ошибка 4: считают фреймворк процессом «шаг за шагом».

   Команда проходит категории как этапы, откладывая обратную связь и эксперименты; продукт готов к моменту, когда рынок изменился.

   Как избежать

   использовать как карту покрытия, сочетать с непрерывным product discovery и короткими циклами проверки.

5. Ошибка 5: отмечают наличие, а не качество.

   Активность записана как выполненная («исследование было»), но не повлияла на решения; таблица зелёная, продукт не растёт.

   Как избежать

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

6. Ошибка 6: нет владельцев на границах функций.

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

   Как избежать

   назначить владельца для каждой из активностей, особенно на стыках (позиционирование, обучение продаж, обратная связь).

7. Ошибка 7: решения принимают по запросам отдельных клиентов.

   Roadmap строится по громким запросам, а не по подтверждённым рыночным проблемам сегмента.

   Как избежать

   сопоставлять запросы с сегментацией и размером проблемы, использовать анализ выигранных и проигранных сделок и интервью.

План внедрения

1. Неделя 1: карта покрытия

   Пройти все семь категорий и отметить по каждой активности: нет, эпизодически, регулярно или измеряется; записать владельцев и источники данных.

2. Неделя 2: найти пустые зоны

   Определить категории и активности, где нет практики вообще, оценить риск каждой пустоты; Market, Business и Support — приоритетные проверки.

3. Неделя 3: минимальное покрытие

   Добавить минимальную практику в каждую пустую категорию (например, интервью с клиентами, бизнес-кейс, материалы для продаж, канал обратной связи) и назначить ответственных.

4. Неделя 4: план углубления

   Выбрать категорию для углубления в следующем цикле, определить метрики и сроки; запланировать пересмотр покрытия раз в полгода.

Как реализовать этот план с помощью фрейма «Pragmatic Framework» в OrgDevTools

Фрейм «Pragmatic Framework» в OrgDevTools — сетка из семи блоков в четыре колонки (четыре блока в первой строке и три во второй) с тремя вкладками: «Диаграмма», «Визуализация» и «Итоги». Он построен на общем движке блоков-квадрантов.

• Вкладка «Диаграмма» — семь блоков: Market (понимание рынка), Focus (выбор приоритетных возможностей), Business (экономика продукта), Planning (дорожная карта, требования), Programs (вывод продукта на рынок), Enablement (обучение продаж и поддержки) и Support (обратная связь после запуска). В каждом блоке — список пунктов свободного текста: пункт добавляется по кнопке или клавишей Enter. Внутри блока нет 37 готовых активностей: перечисляйте свои практики и владельцев.

• Вкладка «Визуализация» — столбчатая диаграмма «Соотношение блоков»: число пунктов в каждой категории.

• Вкладка «Итоги» — заголовок «Pragmatic Framework», вердикт и кнопка «Создать задачу →» с задачей «Закрыть пробел в жизненном цикле продукта» и описанием «Проверить наименее заполненную категорию».

• Вердикт: если блок Market пуст — предлагает начать с Market (это сообщение показывается независимо от заполнения остальных блоков); если заполнены все семь блоков — сообщает, что все семь категорий проработаны; иначе — показывает, сколько категорий из семи заполнено. Категория считается заполненной при одном пункте.

• Чего фрейм не делает — не содержит перечня 37 активностей Pragmatic Institute, не оценивает регулярность и качество, не показывает, какая именно категория наименее заполнена (описание задачи содержит общий текст, а не название категории), не связывает пункты с владельцами и метриками и не сравнивает периоды. Записывайте в пункты конкретные активности, владельцев, регулярность и метрики; вердикт «все семь проработаны» означает лишь, что в каждом блоке есть хотя бы один пункт.

Книги по теме

Pragmatic Institute — материалы и сертификационные программы. Открытый фреймворк публикуется и обновляется институтом; отдельной канонической книги-первоисточника нет.

Роберт Купер — «Winning at New Products» (1986; 5-е издание — 2017). Исследования факторов успеха новых продуктов и модель Stage-Gate.

Мартин Кэган — «Inspired» (2008; 2-е издание — 2017). Практика создания продуктов, которые любят клиенты; критический взгляд на роли и процессы.

Мелисса Перри — «Escaping the Build Trap» (2018). Как избежать ловушки «выпуска функций» и связывать продукт с результатом.