Дорожная карта нового продукта связывает функции с проверками, а агенты исполняют ближайший шаг

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

Роман Пихлер в GO Product Roadmap связывает функции с целью и метриками её достижения. Подробные поручения разработке он оставляет в отдельном списке задач.

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

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

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

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

Для первой проверки хватит фрагмента, где пользователь принимает решение. Торрес предлагает проверять предположения до сборки полного решения.

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

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

Зелёные тесты подтверждают исправность выбранного сценария. Проверку пользы основатель проводит с будущим пользователем.

Правила работы агента фиксируют до запуска. Само поручение «проверить спрос» не даёт агенту права публиковать обещания или писать клиентам от имени компании.

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

На vibecoding.ru инженер ведёт машину агентов. Её поломки научили нас проверять весь выбранный путь, а не наличие нового экрана.

Открытая страница машины на 8 октября показывает 387 тысяч строк спеков и 391 тысячу строк кода. Объём описания объясняет контекст агента, но не измеряет пользу продукта.

У каждого такого описания нужен выход в проверку. Документ с верным правилом не защитит функцию, если исполнение с ним никто не сверяет.

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

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

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

У подрядчика покупают работу над ближайшей согласованной функцией и способ её принять. Бюджет месяца сам по себе не подтверждает весь будущий объём.

Подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. В потоке одна задача в работе, следующая ждёт в очереди.

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

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

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

В учебном сервисе стартом станет путь согласования заявки. Отчёты и интеграции получат место в карте после проверки, которая объяснит, зачем они нужны.

1. Свяжите каждую функцию с изменением для пользователя и проверкой этого изменения.

2. Первой проверьте причину, из-за которой продукт могут не использовать.

3. Поручите агенту ближайший проверяемый шаг; техническую приёмку проводит инженер.

4. После показа запишите наблюдение, решение и новую очередь. Не заменяйте результат статусом «сделано».

5. Разделяйте согласованный выпуск и исследуемые функции. Следующее обещание опирается на проверку предыдущего шага.