Квартальное ревью. Вы две недели готовили новый Roadmap. За это время конкурент запустил агентный сценарий, три функции запланированные на следующий квартал уже стали бессмысленными. RICE не врал, он считал правильно, но считал по фактам, которых больше нет.
RICE, OKR, дорожная карта работают. Они просто работают на предположении, что исходные предпосылки, используемые в планировании, стабильны хотя бы на горизонте квартала.
AI сделал это предположение ложным.
То что недавно являлось базовым набором продуктовой стратегии, сегодня полностью перестраивается. И разрабатывать свой Roadmap, не учитывая данные факторы, стало просто опасно для бизнеса.
Можно выделить 3 ключевых элемента, которые AI уже сломал. И которые сильно влияют на подход к проектированию.
1. Пользователь = человек в UI
Notion сменил позиционирование с “all-in-one workspace” на “AI team workspace”, переключив ключевое действие с функций продукта на агентные сценарии. Miro создал слой “Intelligent Canvas”. Оба пересмотрели ключевую предпосылку: пользователь продукта теперь и человек, и AI-агент, работающий от его имени.
Если в Roadmap все функции спроектированы для человека за экраном, через 6 месяцев половину действий сможет выполнять уже агент.
2. Разработка = узкое место
Бизнес-кейсами по ускорению и “удешевлению” разработки сейчас забиты все ленты в социальных сетях и статьи в любом медиа-сервисе. Надо это принять как свершившийся факт.
Когда цикл разработки сжимается, узкое место смещается. Для большинства компаний оно уже в выходе на рынок: запуск, дистрибуция, обратная связь, итерация на основе данных.
Быстро и дешево разрабатывать (и копировать!) продукты теперь умеет большинство и это всегда надо учитывать в своей стратегии. Но вот продавать и продвигать продукт, а также удерживать пользователей, именно эти умения становятся главным конкурентным полем битвы в ближайший год.
3. Дорожная карта = план поставок
Проектировать развитие функциональности даже на квартал вперед, сегодня является не позволительной роскошью.
-
IT-гиганты ускорили развитие своих экосистем и в любой день, с утра, вы можете узнать, что полный аналог вашего продукта теперь есть в пакете подписки крупной компании.
-
Разработчики AI моделей переключились с бизнес-модели развития LLM на создание собственных автоматизированных рабочих мест для массовых профессий. Полностью ломая устоявшийся рынок (привет всем разработчикам сервисов для копирайтеров, дизайнеров, и еще десятка других). И это только начало.
Дорожная карта должна превращаться не в поток релизов и обновлений, а в систему сценарного планирования, позволяющую перестроить свой план в любой момент.
Для этого каждый CPO должен перейти от дорожной карты в формате разработки конкретных функций к формату приоритетов и сценариев.
С этим есть свои проблемы, так как стейкхолдеры перестанут видеть привычный “функция X в Q2” и получат “ставка на исход Y при уровне уверенности 60%”.
Об этом дальше в статье.
Фреймворк: сценарный Roadmap
Сценарный Roadmap строится на трех основных элементах: список сценариев —> набор приоритетов разработки —> план действий.
Действие первое. Сформируйте список сценариев.
Перед формированием сроков и расчетов загрузки команд необходимо сформировать конкретный список сценариев, которые по мнению команды могут реализоваться в ближайший квартал.
Применяйте здесь классический брейншторминг либо любой формат коллективного творчества.
Главный ожидаемый результат — набор карточек описанных сценариев.
Шаблон карточки сценария:
Сценарий: [название]1. Проблема рынка (текущая): {{ }}2. Потребность пользователя (текущая): {{ }}3. Триггер перехода (пользователя): {{ }}4. Суть сценария: {{ }}5. Наблюдаемые сигналы: {{ }}6. Уровень уверенности в реализации сценария: {{low / medium / high}}7. Что мониторим: {{ }}
Как читается данная карточка:
Проблема рынка — структурное ограничение, вокруг которого вынуждены крутиться все игроки вашей категории. Это не фича и не «хотелка», а условие, которое рынок не может обойти: регуляторика, юнит-экономика, технологический потолок, стоимость привлечения. Ваша задача сформулировать гипотезу: какую именно структурную задачу решают конкуренты, даже если сами её так не называют.
Потребность пользователя — что именно пользователь ожидает от продукта вашего типа и что (ключевое) он не может получить прямо сегодня.
Тут внимание! Проблема рынка и Потребность пользователя в большинстве случаев не совпадают. Простой пример. Пользователь хочет провести платёж за онлайн-сервис в один клик и это его потребность. А проблема рынка в том, что любой платёжный продукт обязан удерживать фрод и соответствовать регуляторике при минимальных потерях конверсии. Потребность и проблема рынка смотрят в разные стороны, и сценарий рождается на их стыке.
Триггер перехода — конкретное условие, при котором воспринимаемая выгода альтернативы перевешивает стоимость переключения, и пользователь уходит. Важно: речь не о выборе между прямыми конкурентами, а о переходе на альтернативу или иной способ закрыть потребность, которую предлагает рынок. Формулируйте триггер как порог: что должно появиться или измениться, чтобы переключение стало рациональным.
Суть сценария — короткий абзац (максимум 3 предложения): кто и как может развернуть этот сценарий на рынке. Это сборка трёх полей выше в одну причинно-следственную цепочку: появляется игрок (новый вход или смежная платформа), который закрывает потребность пользователя в обход проблемы рынка, — и это снимает порог из триггера, запуская переток пользователей. Суть отвечает не “при каком условии”, а “как именно это произойдёт и чьими руками”.
Наблюдаемые сигналы — конкретные ранние признаки того, что сценарий начинает реализовываться. Это не сам факт перехода пользователей (его вы увидите слишком поздно), а опережающие индикаторы: запуск или раунд у стартапа, изменение в регуляторике, появление новой технологии в открытом доступе, рост запросов пользователей в нужную сторону, движение цены/юнит-экономики у альтернатив. Правило простое: если сценарий нельзя привязать хотя бы к одному наблюдаемому сигналу это не сценарий, а догадка, и в роадмап он не попадает. Формулируйте сигнал так, чтобы по нему можно было однозначно сказать “сработал / не сработал”.
Что мониторим — где смотрим, как часто и при каком значении считаем сигнал сработавшим. Для каждого сигнала фиксируйте источник (конкретный отчёт, метрика продукта, рыночный трекер, новостной триггер), частоту проверки (раз в спринт, раз в месяц) и порог срабатывания — то значение, после которого вы пересматриваете уровень уверенности сценария и его приоритет. Именно этот пункт превращает сценарный Roadmap из презентации в инструмент. Уверенность не остаётся “medium” навсегда, а двигается по мере того, как сигналы подтверждаются или гаснут.
Пример заполненной карточки сценария:
Сценарий: Нативный AI-ассистент становится причиной выбора базы знаний1. Проблема рынка (текущая): Все вендоры вики баз с AI функционалом конкурируют на базовой функциональности. И решают вопрос интеграции с GigaChat/YandexGPT в 152-ФЗ и защищённый контур.2. Потребность пользователя (текущая): Нужен готовый ответ из документов на русском, а не список страниц. Сегодня поиск по ключевым словам не возвращает документ или точную цитату.3. Триггер перехода (пользователя): AI-ассистент, отвечающий по содержимому базы в защищённом контуре. Выгода (ответ за секунды) перевешивает стоимость миграции и переобучения.4. Суть сценария: Вендор с ресурсами на интеграцию GigaChat/YandexGPT первым выпускает RAG-ассистента поверх базы знаний и закрывает потребность в обход проблемы рынка. Первыми мигрируют IT и финтех, за ними остальной рынок.5. Наблюдаемые сигналы: 1) Анонсы on-prem развёртываний; 2) Рост запросов «база знаний с ии» в Wordstat; 3) Обращения клиентов в поддержку/демо: "есть ли AI-поиск по внутренней базе документов";6. Уровень уверенности в реализации сценария: medium7. Что мониторим: 1) Changelog конкурентов раз в спринт; анонсы в новостях раз в месяц. Порог: запуск у конкурента → сценарий в топ роадмапа; Рост доли AI-запросов >10% → уверенность на high.
Действие второе. Раскладываем сценарии по матрице вероятности.
Когда карточки собраны, их нужно сравнить между собой и не по ощущению “важно / не важно”, а по двум осям:
-
Вероятность реализации берётся напрямую из поля 6 карточки (low /medium / high);
-
Тяжесть последствий. То есть насколько сильно сценарий ударит по продукту, если реализуется без вашей реакции: потеря доли, отток ключевого сегмента, обесценивание текущей дорожной карты.
Разместите каждую карточку в одном из четырёх квадрантов:
Тяжесть последствий низкая высокая ┌───────────────┬───────────────┐ высокая │ Фон │ Приоритет │ Вероятность │ (учитываем) │ (действуем) │ ├───────────────┼───────────────┤ низкая │ Шум │ Радар │ │ (игнор) │ (мониторим) │ └───────────────┴───────────────┘
Как читается матрица:
-
Приоритет (высокая × высокая) — сценарии, под которые планируется разработка в первую очередь. Ядро роадмапа.
-
Радар (низкая × высокая) — пока маловероятны, но при реализации опасны. Сюда уходят сигналы и мониторинг из поля 7: не разрабатываем, но держим под наблюдением и готовим план ответа.
-
Фон (высокая × низкая) — случатся почти наверняка, но без серьёзных последствий. Учитываем в текущей работе, отдельных ставок не делаем.
-
Шум (низкая × низкая) -отбрасываем, чтобы не распылять команду.
Главный результат этого шага даже не сама матрица, а отсечение. Из всех сценариев в разработку идут только квадрант «Приоритет», под наблюдение — «Радар». Остальное снято с повестки осознанно, а не забыто.
Действие третье. Формируем план действий.
Матрица дала приоритеты, теперь раскладываем их в привычную форму. Каждый сценарий из квадранта “Приоритет” превращается в инициативу роадмапа, а горизонт берётся из матрицы:
-
Приоритет → горизонты Now / Next (разрабатываем).
-
Радар → горизонт Later / Watch (не разрабатываем, держим под сигналом).
-
Фон → растворяется в текущей работе, в роадмап отдельной строкой не выносится.
Сам роадмап это таблица в горизонтах Now / Next / Later.
NOW (текущий квартал) ┌─────────────────┬──────────────┬─────────┬────────┬───────────────┐ │ Инициатива │ Сценарий │ Команда │ Метрика│ Сигнал отмены │ ├─────────────────┼──────────────┼─────────┼────────┼───────────────┤ │ RAG-ассистент │ AI-поиск по │ Core + │ % AI- │ нет беты у │ │ поверх базы. │ базе знаний │ ML │ ответов│ конкурентов │ │ │ │ │ к месяцу│ 2 квартала │ └─────────────────┴──────────────┴─────────┴────────┴───────────────┘NEXT (следующий квартал) ┌─────────────────┬──────────────┬─────────┬────────┬───────────────┐ │ ... │ ... │ ... │ ... │ ... │ └─────────────────┴──────────────┴─────────┴────────┴───────────────┘LATER / WATCH (на радаре) ┌─────────────────┬──────────────────────────────────────────────────┐ │ Сценарий │ Триггер активации (из поля 7 карточки) │ ├─────────────────┼──────────────────────────────────────────────────┤ │ [сценарий] │ сработал сигнал → переносим в Now │ └─────────────────┴──────────────────────────────────────────────────┘
Что отличает этот роадмап от обычного списка фич:
-
Колонка “Сценарий” где каждая инициатива привязана к рыночному сценарию, а не к чьему-то пожеланию. Всегда видно, зачем строка в плане.
-
Сигнал отмены — здесь живёт мониторинг из поля 7. Если сценарий не подтверждается то инициатива снимается, ресурс уходит дальше. Роадмап перестаёт быть обязательством любой ценой.
-
Зона Later / Watch не свалка «когда-нибудь», а сценарии с заготовленным триггером: маловероятны сейчас, но при первом сигнале мгновенно поднимаются в Now.
Три ошибки, которые “не прощает” сценарный Roadmap:
Ошибка 1. Схлопывать проблему рынка и потребность пользователя.
Самая частая и самая дорогая. Команда пишет в обоих полях одно и то же “пользователю нужен AI”, “рынок идёт к AI”. В этот момент исчезает весь двигатель фреймворка: сценарии рождаются именно на расхождении этих полей. Если они совпали значит вы не нашли сценарий, вы просто описали очевидную фичу.
Проверка: поля 1 и 2 должны смотреть в разные стороны. Пользователь хочет ответ за секунду; рынок решает проблемы регуляторику или удешевления доступа к LLM. Совпали — переписывайте.
Ошибка 2. Сценарий без наблюдаемого сигнала.
Сценарий, который нельзя привязать к конкретному внешнему признаку. Это не сценарий, а догадка, выдающая себя за стратегию. Такие пункты невозможно ни подтвердить, ни опровергнуть, поэтому они вечно висят в бэклоге и тихо съедают внимание команды.
Проверка: к каждой карточке составьте минимум один сигнал из поля 5, по которому однозначно видно “сработал / не сработал”. Нет сигнала — сценарий не попадает в матрицу.
Ошибка 3. Роадмап без сигнала отмены.
Команда проходит все три шага, рисует красивую матрицу и фиксирует план на квартал как обязательство. Уверенность остаётся “medium” навсегда, мониторинг не ведётся, сигналы не пересматриваются. Сценарный Roadmap превращается в обычный список фич с лишними этапами на входе.
Проверка: у каждой инициативы есть сигнал отмены и условие подъёма с “Радара”. Если ни одна строка роадмапа не может быть снята по сигналу значит вы построили статичный план, а не сценарный.
Заключение
Сценарный Roadmap не отменяет привычный план. Он меняет то, на чём план держится. Обычный роадмап отвечает на вопрос “что мы хотим сделать”. Сценарный “что должно произойти на рынке, чтобы это имело смысл”.
Весь фреймворк сводится к трём шагам:
-
Сценарии — расхождение проблемы рынка и потребности пользователя, привязанное к наблюдаемым сигналам.
-
Матрица то есть отсев по вероятности и тяжести последствий. В работу идёт только то, что важно и вероятно.
-
Роадмап со своими этапами Now / Next / Later, где каждая строка привязана к сценарию и к сигналу, по которому её можно отменить или поднять.
Главное, что вы получаете на выходе это не документ, а способность реагировать раньше рынка. Пока конкуренты обнаруживают изменение по факту оттока, вы видите его по сигналу и успеваете среагировать. Это и есть новая роль CPO: не защищать зафиксированный план, а управлять набором сценариев, которые рынок сам подтверждает или отменяет.
ссылка на оригинал статьи https://habr.com/ru/articles/1044182/