Примеры product roadmap: шесть форматов и их слабые места

Примеры product roadmap, которые стоит брать за образец, делятся на шесть форматов: Now/Next/Later, квартальный график, тематический roadmap, roadmap по результатам, публичный roadmap и внутренний релизный roadmap. Каждый отвечает на свой вопрос для своего читателя, поэтому подходящий пример тот, что совпадает с вашим читателем. Внешний вид выбирается в последнюю очередь.

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

Какие бывают хорошие примеры product roadmap?

Хороший пример roadmap короткий, адресован конкретному читателю и даёт обещание одного рода. Формат выбирают по тому обещанию, которое вы готовы выполнить: направление, дата, тема работ, результат, публичное обязательство или график поставки.

Как выглядит каждый пример product roadmap?

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

Now/Next/Later

NOW (делаем в этом месяце)
  Сохранённые виды во входящих
  Экспорт CSV, который работает на больших аккаунтах
NEXT (решено, порядок не зафиксирован)
  SSO для плана Team
  Уведомления в Slack
LATER (направление, без обязательств)
  Мобильное приложение
  Журнал аудита

Этот формат подходит компании, которая не хочет обещать даты, а так живут многие команды на ранней стадии. Он держится потому, что три колонки описывают степень уверенности: «now» в работе, «next» решено, «later» надежда. Он ломается, когда «later» становится местом, куда складывают все идеи, которые жалко отклонить, и когда у «next» незаметно появляются порядок и дата, хотя вслух это никто не называет графиком.

Временная шкала, или квартальный roadmap

Q4 2026
  Окт   Сохранённые виды во входящих
  Ноя   SSO в бете с пятью партнёрами
  Дек   SSO, общий доступ
Q1 2027
  Янв   Уведомления в Slack
  Мар   Журнал аудита (только экспорт)

Он подходит продажам, поддержке и финансам, которым нужно во что-то упираться при планировании. Работает, когда даты действительно жёсткие: контракт, конференция, срок по комплаенсу. Ломается, когда даты взяты с потолка, потому что месяц в roadmap через несколько недель превращается в обещание в презентации отдела продаж. Если вы выбрали этот формат, помечайте каждый квартал как «обязательство» или «прогноз» и делайте второй квартал заметно менее определённым, чем первый.

Тематический roadmap

ТЕМА: Первая неделя в продукте
  Импорт из CSV и Trello
  Стартовые шаблоны
ТЕМА: Готовность к большим командам
  SSO
  Журнал аудита
  Права по ролям
ТЕМА: Меньше ручных действий
  Уведомления в Slack
  Повторяющиеся задачи

Подходит для отчётов руководству и для новых сотрудников, потому что сначала объясняет, зачем нужна работа, и только потом перечисляет её. Держится, когда каждая тема соответствует причине, по которой клиенту это важно. Ломается, когда темы слишком широкие («Рост», «Качество»), так что любой пункт подходит под любую из них, и тогда группировка ничего не объясняет.

Roadmap по результатам

ЦЕЛЬ: Больше новых команд завершают настройку
  Метрика: настройка за 7 дней, с 40% до 55%
  Ставки: импорт из CSV, стартовые шаблоны
ЦЕЛЬ: Меньше обращений по экспорту
  Метрика: обращений по экспорту в неделю, с 30 до 10
  Ставки: починка экспорта на больших аккаунтах,
  страница статуса экспорта

Цифры условные, а важна раскладка: цель, одна метрика с исходным и целевым значением и ставки, которые вы собираетесь проверить. Формат подходит командам продукта и разработки, которым доверяют выбор решения. Работает, когда метрика существует и у неё есть владелец. Ломается, когда цель нельзя измерить или когда «ставки» остаются прежним списком функций, к которому сверху приклеили предложение про результат.

Публичный roadmap для клиентов

ПЛАНИРУЕМ
  Сохранённые виды во входящих
В РАБОТЕ
  Уведомления в Slack
ВЫПУЩЕНО
  Экспорт CSV для больших аккаунтов

Это самый маленький формат и самое сильное обещание. Он подходит клиентам, которые хотят знать, услышали ли их запрос. Держится при очень малом числе пунктов, без дат и с названиями словами клиента. Ломается, когда превращается в свалку бэклога: каждое «может быть» в списке это обещание, о котором кто-нибудь спросит позже. Как вести такой roadmap из трекера задач, описано в статье публичная roadmap в трёх колонках, поэтому здесь это не повторяется.

Внутренний релизный roadmap

Он подходит разработке, QA и поддержке, которым нужно знать, что выходит вместе и что от чего зависит. Работает, когда точен до недели и у каждой строки есть владелец. Ломается, когда его принимают за стратегию: график поставки говорит, что и когда покидает здание, и ничего не говорит о том, были ли эти релизы правильными ставками.

Какой формат product roadmap выбрать?

Выбирайте сначала по читателю, затем по тому, насколько вы на самом деле уверены. Если вы не можете назвать, кто читает roadmap и какое решение он помогает принять, ни один из примеров выше его не спасёт.

• Клиенты спрашивают: «вы меня услышали?» Берите публичный формат и ограничьтесь горсткой пунктов.
• Продажи и поддержка спрашивают: «можно назвать клиенту дату?» Берите квартальный график, где обязательства и прогнозы чётко разделены.
• Руководство спрашивает: «зачем эта работа?» Берите темы, а если есть данные, то результаты.
• Команда меняет направление каждый месяц. Берите Now/Next/Later и не ставьте дат.
• Инженеры спрашивают: «что и когда выходит?» Берите релизный roadmap и держите его отдельно от стратегического.

Большинство команд в итоге ведут два документа: стратегический roadmap в одном из первых четырёх форматов и график релизов под ним. Публичный roadmap тогда становится отфильтрованным видом стратегического и показывает только то, за что вы готовы отвечать.

Как составить product roadmap?

Составляйте roadmap так: назовите читателя, выберите формат под его вопрос, внесите только пункты, которые вы готовы защищать на встрече, и дайте каждому статус и владельца. Затем решите, как часто его будут пересматривать, прежде чем публиковать.

1. Назовите читателя и решение. «Поддержка решает, что говорить клиентам про SSO» это причина. «Все должны видеть roadmap» не даёт ничего, под что можно проектировать.
2. Начните с того, что уже знаете. Открытые запросы, упорядоченные по понятному правилу, лучший материал, чем мозговой штурм.
3. Пишите каждый пункт как результат для клиента. «Сохранять фильтр, которым пользуешься часто» читается лучше, чем «Реализовать сохранение состояния видов», и сразу показывает клиенту, его ли это проблема.
4. Решите, чего в roadmap не будет. Обычно это даты, оценки и склад идей.
5. Назначьте дату пересмотра. У roadmap без запланированного пересмотра есть незапланированные похороны.

Как поддерживать product roadmap в актуальном состоянии?

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

Самый дешёвый источник правды это трекер задач. Если каждая колонка roadmap соответствует метке на задаче, roadmap меняется вместе с меткой, и ничего не набирается заново. В Changeloop это устроено через метки roadmap:planned, roadmap:building и roadmap:shipped, а когда на задаче две метки, побеждает самая продвинутая. Перенос карточки в «выпущено» остаётся отдельной сменой метки, поэтому сделайте его частью проверки, на которой вы одобряете запись в changelog.

Эта запись вторая половина дела. Когда пункт выпущен, changelog описывает изменение в терминах клиента, а тому, кто просил об этом, можно сообщить. Замкнуть эту петлю и есть смысл петли обратной связи клиента, а roadmap это отрезок этой петли, который клиент видит до того, как что-либо выпущено. Если вы отказались от пункта, скажите об этом; публичное «нет» закрывает и этот запрос, а как его сформулировать, описано в статье отказ в запросах на функции. Тем, кто хочет увидеть, как читаются готовые записи, пригодятся примеры changelog.

FAQ

Какой формат product roadmap самый простой? Now/Next/Later. В нём три колонки, не нужны даты, а пункты группируются по степени уверенности. Для небольшой команды, которая часто меняет направление, в нём ещё и труднее всего опозориться.

Сколько пунктов должно быть в product roadmap? Меньше, чем вам кажется. Публичному roadmap хватает менее десяти пунктов на все колонки, а внутреннему стратегическому редко нужно больше дюжины. Сверх этого получается бэклог с красивым заголовком.

Нужно ли указывать даты в product roadmap? Только если даты действительно жёсткие, и то лишь для ближайшего квартала. Дальше используйте колонки или темы. Дата в roadmap становится обязательством в разговоре с продажами, хотите вы этого или нет.

Чем product roadmap отличается от плана релизов? Roadmap говорит, что вы собираетесь строить и зачем. План релизов говорит, какая сборка выходит в какую дату и кто за неё отвечает. Roadmap меняется, когда меняется стратегия, а план релизов меняется, когда меняется работа.

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

По теме на changeloop: Документация для разработчиков, Примеры changelog