Продуктовый roadmap и OKR

Что такое продуктовый roadmap и чем он не является

Roadmap — стратегический инструмент коммуникации: он объясняет команде, руководству и смежникам, куда движется продукт и почему именно туда. Это не план-график и не бэклог с дедлайнами.

Главная ошибка — превратить roadmap в гантт из фич с точными датами. Такой документ обещает то, что на ранних стадиях невозможно знать, и наказывает команду за обучение: как только реальность расходится с планом, roadmap выглядит «проваленным», хотя команда просто узнала новое. Roadmap должен переживать смену деталей, оставаясь верным направлению.

Outcome против output

Это ключевое различие в продуктовом планировании:

• Output — то, что команда построила: фичи, экраны, релизы. Их легко посчитать, но сами по себе они не создают ценности.
• Outcome — изменение в поведении пользователя или в бизнес-метрике, ради которого фича делалась.

Roadmap, построенный вокруг outcomes («снизить отток на онбординге», «ускорить время до первой ценности»), устойчивее фичевого: он не привязывает команду к конкретному решению и оставляет свободу найти лучший способ добиться результата. Фичи становятся гипотезами о том, как достичь outcome, а не самоцелью.

Форматы: now / next / later против timeline

Timeline-roadmap раскладывает инициативы по календарю (Q1, Q2…). Он создаёт ложную точность: даты выглядят как обязательства, хотя уверенность в дальних кварталах низкая.

Now / Next / Later заменяет даты горизонтами уверенности: Now — то, над чем работаем и в чём уверены; Next — следующее по приоритету, проработанное грубее; Later — направления и идеи без деталей. Формат честно отражает, что чем дальше горизонт, тем выше неопределённость, и снимает давление ложных дедлайнов.

Timeline уместен там, где есть реальные внешние обязательства и зависимости (релиз к мероприятию, требования регулятора, контрактные сроки). Для остального now/next/later обычно честнее, особенно на ранних стадиях.

OKR и связь roadmap с целями

OKR связывают roadmap со стратегией. Objective — качественная, вдохновляющая цель («сделать онбординг местом, откуда не уходят»). Key Results — измеримые признаки её достижения («доля дошедших до aha-момента выросла с 40% до 60%»).

Правильная связка: инициативы в roadmap существуют, чтобы двигать конкретные Key Results, а KR опираются на продуктовые метрики. Частая ошибка — записывать в Key Results задачи («выпустить фичу X»): KR должен описывать результат, а не работу. Если инициатива из roadmap не двигает ни один KR, это повод спросить, зачем она в плане.

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

Рабочая последовательность идёт сверху вниз: цели (OKR) → проблемы и возможности, которые двигают эти цели → инициативы, решающие проблемы. Дальше инициативы приоритизируют (RICE/ICE), а выбранные разворачивают в постановку задачи и PRD с метриками успеха.

Roadmap — живой документ: его пересматривают по мере обучения, а не фиксируют раз в год. Главный антипаттерн — «фичеконвейер», где roadmap живёт отдельно от целей и просто перечисляет, что команда успеет построить. Лекарство — на каждом пересмотре спрашивать про каждую инициативу: какой outcome она двигает и как мы поймём, что добились результата.

Частые вопросы

Чем roadmap отличается от бэклога?

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

Нужны ли даты в продуктовом roadmap?

Точные даты оправданы только там, где есть реальные внешние обязательства и зависимости. В остальных случаях формат now/next/later честнее: он отражает, что уверенность падает с дальностью горизонта, и не превращает оценки в обещания, которые потом выглядят как провал.

Как связать roadmap с OKR?

Каждая инициатива в roadmap должна двигать конкретный Key Result, а KR — опираться на измеримые продуктовые метрики. Если инициатива не влияет ни на один KR, стоит пересмотреть её место в плане. При этом важно не записывать в Key Results сами задачи: KR описывает результат, а не выполненную работу.