Roadmap-форматы: Now/Next/Later, GIST, outcome-based

Продуктовая дорожная карта — один из самых обсуждаемых и противоречивых артефактов в современном продуктовом управлении. С одной стороны, без roadmap команда не имеет общего видения и сложно объяснить стейкхолдерам, куда идёт продукт. С другой — классические roadmaps в формате Gantt-диаграмм с конкретными датами превращаются в источник конфликтов и постоянных оправданий за невыполнение сроков.

За последние десять лет в продуктовом сообществе появились новые форматы roadmap, лучше отражающие реалии современной разработки: неопределённость, итеративность, важность результатов над фичами. Now/Next/Later от ProdPad, GIST от Itamar Gilad, outcome-based roadmaps от Marty Cagan, theme-based подходы — каждый из них предлагает альтернативу классическим срокам и фичам. Понимание этих форматов и условий их применимости помогает строить дорожную карту, которая работает, а не порождает разочарования.

Зачем нужны roadmaps

Дорожная карта решает несколько разных задач, иногда конфликтующих между собой.

• Коммуникация видения: рассказать команде и стейкхолдерам, куда идёт продукт
• Координация работы: согласовать действия разных команд, зависящих друг от друга
• Управление ожиданиями: дать стейкхолдерам понимание сроков и приоритетов
• Принятие решений: фрейм для приоритизации между конкурирующими инициативами
• Продажа продукта: показ потенциальным клиентам, что планируется и зачем
• Привлечение инвестиций: основа для рассказа инвесторам о развитии

Разные задачи требуют разных форматов. Внутренняя roadmap для команды может содержать гипотезы, неопределённости, спорные инициативы. Внешняя для клиентов должна быть проще, без чувствительной информации. Roadmap для инвесторов фокусируется на ключевых milestones и бизнес-результатах. Попытка сделать один универсальный документ для всех аудиторий обычно проваливается.

Классические Gantt-формы и их проблемы

Долго стандартом в индустрии была дорожная карта в форме Gantt-диаграммы: список конкретных фич с привязкой к датам или кварталам выпуска. Эта форма пришла из проектного менеджмента и хорошо работает там, где задачи известны, оценки точны, контекст стабилен.

Почему Gantt-roadmap не работает в продукте

1. Оценка сложности задач неточна: реальная сложность становится известна по ходу работы
2. Приоритеты меняются: внешние факторы, новые данные, поведение рынка
3. Discovery меняет понимание: исследования пользователей могут перевернуть представление о решении
4. Зависимости между задачами: блокировки на смежных командах сдвигают сроки
5. Психологический эффект: команда воспринимает roadmap как обязательство, а не план

В результате Gantt-roadmap становится фиктивным документом: либо команда выполняет обязательства за счёт качества и горения людей, либо постоянно пересматривает сроки и теряет доверие. Третий вариант — формальное «выполнение» с превращением discovery в delivery без реальной валидации.

Now / Next / Later

Один из самых популярных современных форматов, разработанный ProdPad. Roadmap делится на три горизонта без точных дат.

Преимущества формата

• Не привязывает к датам, которые невозможно точно предсказать
• Чётко показывает приоритеты команды
• Простой для понимания внешними аудиториями
• Легко обновляется по мере прогресса
• Не создаёт ложных обязательств по срокам

Когда подходит

Формат хорошо работает для большинства продуктовых команд, особенно на ранних стадиях продукта. Он гибкий, понятный, не создаёт лишнего стресса. Менее подходит для жёстко регулируемых индустрий и B2B-продаж, где клиентам нужны конкретные сроки для планирования внедрений.

GIST — Goals, Ideas, Steps, Tasks

Методология Итамара Гилада, бывшего product lead в Google. GIST разделяет планирование на четыре уровня с разными частотами обновления.

Goals

Цели команды на длинном горизонте — обычно квартал или год. Формулируются в терминах outcomes, а не фич: «увеличить retention 7-day до 40%», «достичь $5M ARR», «снизить churn на 30%».

Ideas

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

Steps

Шаги реализации выбранных идей. Каждая идея разбивается на серию экспериментов или MVP-итераций, проверяющих её ценность. Не разрабатывается полная фича сразу — сначала проверяется гипотеза.

Tasks

Конкретные задачи в backlog, реализующие текущие steps. Это уровень спринтов и операционного планирования.

Принципы GIST

1. Цели стабильны, идеи меняются часто
2. Идеи без подтверждения не превращаются в полные фичи
3. Steps итеративны и могут привести к отказу от идеи на полпути
4. Связь между уровнями явная и пересматривается регулярно

GIST требует зрелой продуктовой культуры с акцентом на experiments и outcomes. В компаниях, привыкших к feature-driven подходу, внедрение GIST занимает 1–2 года.

Outcome-based roadmap

Подход, продвигаемый Marty Cagan и Teresa Torres. Вместо списка фич roadmap содержит бизнес-результаты, которые команда обязуется достичь. Конкретные решения остаются на усмотрение команды и могут меняться по ходу.

Пример outcome-based roadmap

Q1 2026: Снизить churn первого месяца с 25% до 15%
  Возможные направления:
  - Улучшение onboarding
  - Активация ключевых функций в первую неделю
  - Перепроектирование payment recovery

Q2 2026: Увеличить выручку с существующих клиентов на 30%
  Возможные направления:
  - Запуск premium-тарифа
  - Upsell-механика в продукте
  - Дополнительные платные интеграции

Q3 2026: Достичь NPS 50+ в основной аудитории
  Возможные направления:
  - Сокращение времени ответа поддержки
  - Перепроектирование самых жалобных сценариев
  - Программа лояльности для активных пользователей

Преимущества

Outcome-based подход даёт команде свободу искать лучшие решения и не приклеивает её к конкретным фичам, которые могут оказаться не оптимальными. Стейкхолдеры видят понятные бизнес-результаты, к которым стремится продуктовая команда.

Сложности

Многие стейкхолдеры (особенно sales, marketing, customer success) хотят видеть конкретные фичи для своей коммуникации с клиентами. Чисто outcome-based roadmap может быть слишком абстрактной для этих аудиторий. Гибридный подход — outcome-based как основа, с примерами возможных фич — обычно работает лучше.

Theme-based roadmap

Промежуточный формат между outcome-based и feature-based. Работа группируется в темы, отражающие крупные направления развития продукта.

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

Roadmap по OKR

Многие компании, использующие OKR (Objectives and Key Results), строят roadmap вокруг этой структуры. Каждый квартал команда формулирует objectives и key results, под них группируются инициативы.

Сильные стороны

• Прямая связь между стратегией компании и продуктовой работой
• Чёткие критерии успеха в виде key results
• Регулярный пересмотр и фокусировка
• Хорошо интегрируется с другими процессами компании

Сложности

OKR-roadmap требует зрелой OKR-культуры по всей компании. Без неё она превращается в формальность — заполнение шаблонов раз в квартал без реального влияния на работу. Также OKR плохо работают для долгосрочных инициатив, занимающих несколько кварталов.

Story-map roadmap

Метод Джеффа Паттона на основе user story mapping. Roadmap визуализируется как карта пользовательского опыта: горизонтальная ось — основные шаги пользователя, вертикальная — глубина проработки.

Самый верхний уровень — minimum viable journey, обеспечивающий базовый сценарий. Следующие уровни — расширения, улучшения, дополнительные сценарии. Это даёт стейкхолдерам понятную картину того, что входит в каждый релиз и как продукт развивается через серию релизов.

Story-map хорошо подходит для новых продуктов и больших фичей. Менее подходит для зрелых продуктов, где работа распределена между независимыми инициативами.

Internal vs External roadmap

Внутренняя и внешняя дорожные карты решают разные задачи и требуют разных форматов.

Internal roadmap

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

External roadmap

• Упрощённая, без чувствительной информации
• Без конкретных сроков (или с очень широкими)
• Фокус на ценности для клиентов, а не технических деталях
• Обновляется реже, при значимых изменениях
• Используется для коммуникации с клиентами и партнёрами

Что нельзя в external roadmap

• Конкретные обязательства по датам (создают юридические риски)
• Информация о конкурентных стратегиях
• Технические детали реализации
• Внутренние спорные инициативы
• Метрики и аналитика бизнеса

Инструменты для управления roadmap

Выбор инструмента менее важен, чем выбранная методология. Любой инструмент можно настроить под любой формат roadmap. Часто команды переходят с одного инструмента на другой не из-за функциональности, а из-за стоимости или интеграций с остальным стеком.

Антипаттерны

Feature factory roadmap

Roadmap — это список фич, привязанных к датам, без связи с бизнес-результатами или пользовательскими проблемами. Команда выполняет план, не задумываясь, имеет ли он смысл. Узнать про эту проблему легко: спросите команду, какие из последних 10 выпущенных фич реально повлияли на метрики — обычно не вспомнят.

Свалка пожеланий стейкхолдеров

Roadmap состоит из всего, что попросили sales, marketing, customer success, CEO. Без приоритизации, без фокуса, с тысячью задач. Команда не успевает довести ничего до конца, бизнес-результат отсутствует. Признак — длина roadmap превышает реальную мощность команды в 3–5 раз.

Скрытая roadmap

Roadmap существует только в голове продакт-менеджера или в private-доках. Команда узнаёт о приоритетах постфактум, не имеет возможности заранее предложить альтернативы, влиять на выбор. Эффективность падает, мотивация снижается.

Roadmap без обновлений

Документ нарисован один раз, размещён где-то на портале и больше не обновляется. Через несколько кварталов он не имеет никакого отношения к реальности, но формально существует. Зрелая roadmap пересматривается минимум раз в квартал, лучше — раз в месяц по верхнему уровню.

Roadmap как обязательство

Sales продаёт фичи из roadmap клиентам как обещания. Marketing анонсирует даты выпуска. Customer success обещает решения проблем к конкретному сроку. Это превращает roadmap из планирующего документа в юридическое обязательство и убивает её адаптивность. Внешняя коммуникация требует особой осторожности.

Roadmap — это набор приоритетов команды на разных горизонтах, а не план реализации с точными сроками. Превращение roadmap в обязательство по датам — это путь к потере доверия и качества продукта.

Эволюция формата с ростом компании

Формат roadmap обычно меняется по мере роста и зрелости команды.

Стартап на seed-стадии

Roadmap — это лист идей в порядке приоритета. Никаких сложных форматов не нужно. Цикл планирования — недели. Главное — общее понимание, что делать следующим.

Pre-PMF стартап

Now/Next/Later — оптимальный формат. Без жёстких сроков, с фокусом на discovery. Регулярные пересмотры по мере получения данных от пользователей.

Растущий стартап

Появляются темы, цели, координация между несколькими командами. Outcome-based подход с темами начинает работать. Появляются разделения internal/external roadmap.

Зрелая компания

Полный портфельный подход. Quarterly OKRs на уровне компании каскадируются в продуктовые цели. GIST или похожие методологии. Несколько внутренних roadmap для разных продуктов с координацией на верхнем уровне.

Часто задаваемые вопросы

Можно ли работать без roadmap вообще

В малых командах из 2–5 человек на ранней стадии — да, разговор и приоритизация в чате работают. С ростом команды и продукта без формального roadmap начинаются конфликты приоритетов, потеря фокуса, проблемы с координацией. На команду из 10+ человек roadmap уже необходим.

Как реагировать на запросы с конкретными датами от sales

Объяснить, что конкретные даты — это обязательство, которое продуктовая команда не может давать в условиях неопределённости. Предложить альтернативу: широкие диапазоны («во второй половине года»), привязка к достижениям metric’ов, общее понимание приоритета. Если конкретный клиент готов платить за commitment по дате, это уже отдельная коммерческая дискуссия, не часть стандартной roadmap.

Как часто обновлять roadmap

Верхний уровень (темы, outcomes) — раз в квартал. Уровень инициатив — раз в месяц. Уровень текущей работы — еженедельно. Полное переписывание roadmap происходит редко — обычно эволюция, не революция.

Кто должен видеть internal roadmap

Минимум — вся продуктовая команда, инженеры, дизайнеры. Желательно — все смежные функции (sales, marketing, customer success, support) для координации. Прозрачность внутри компании обычно полезнее закрытости, потому что снижает информационную асимметрию и улучшает понимание решений.

Что делать с долгосрочными инициативами на 6–12 месяцев

Разделить на этапы: что можно проверить и выпустить за 4–8 недель, что зависит от результатов первого этапа, что точно нужно сделать дальше. Параллельно держать в later как направление, но без конкретики реализации. Большие монолитные инициативы обычно проваливаются — лучше декомпозировать на серию меньших проверяемых итераций.

Стоит ли публиковать внешнюю roadmap

Зависит от типа продукта и компании. Open source-проекты, developer tools, продукты с активным сообществом обычно публикуют. Корпоративный B2B-SaaS — реже, или только для существующих клиентов под NDA. Consumer-продукты обычно не публикуют. Главный риск публичной roadmap — обещания становятся обязательствами с репутационными последствиями.

Заключение

Современные дорожные карты — это набор форматов и методологий, отражающих неопределённость и итеративность продуктовой разработки. Now/Next/Later, GIST, outcome-based, theme-based, story-map — каждый формат имеет свою область применимости. Выбор зависит от размера команды, зрелости продукта, культуры компании, требований стейкхолдеров.

Общий принцип современных roadmaps — приоритизация приоритетов и направлений над конкретными сроками и фичами. Это снимает с команды нереалистичные обязательства по предсказанию будущего и оставляет место для discovery и адаптации. Главные практические следствия — переход от Gantt-диаграмм к более гибким форматам, разделение internal и external roadmap, регулярное обновление документа по мере получения новых данных. Roadmap, не обновляющаяся годами, теряет смысл; roadmap, обновляющаяся еженедельно с заменой всего содержимого, тоже бесполезна — нужен баланс между стабильностью и адаптивностью.