Product Discovery должно закончиться выбором эксперимента, который можно отдать агентам

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

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

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

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

Сегмент должен позволять найти участников проверки. «Весь малый бизнес» не подсказывает, кому показать прототип. «Клиенты сервисной компании с заказом в ремонте» уже задаёт способ отбора.

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

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

Первым берут важное предположение, под которым мало доказательств. Так Тереза Торрес предлагает выбирать риск в Product Talk: если клиенты всё равно предпочитают звонить менеджеру, работающий кабинет не отвечает на главный вопрос владельца.

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

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

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

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

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

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

Такой порог разрешает следующую проверку в этом примере. Он не доказывает спрос всего рынка и не даёт статистической оценки эффекта.

Паспорт передаётся вместе с проектом. Общие правила для ИИ-агентов описывают порядок работы. Паспорт описывает конкретное предположение и выбранный опыт.

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

Агент получает ограниченное поручение: собрать страницу просмотра статуса и запись событий. Мобильное приложение, оплата и весь кабинет остаются за пределами этой проверки.

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

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

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

Критерий нельзя двигать после просмотра результата. Если вместо использования страницы зачесть ответы «интересно», эксперимент уже проверяет другое предположение.

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

На нашей машине разные проверки тоже ловят разные ошибки. Три истории ниже относятся к исполнению и качеству материала. Исследования рынка они не заменяют.

На странице открытой машины агентов показаны 387 тысяч строк описаний рядом с 391 тысячей строк кода. Это опубликованный снимок, сверенный 8 октября 2026. Дата исходного подсчёта строк на странице не названа.

Числа показывают, что решения и описания живут рядом с исполнением. Объём документов не доказывает, что клиент выберет продукт или что любой эксперимент окажется удачным.

Роль инженера на той же странице названа прямо: он пишет правила и принимает работу. В машине vibecoding.ru инженер ведёт машину агентов, а не отдаёт ей последнее слово о продукте.

Клиентского кейса Product Discovery у этой машины нет. Уроки курса про правила, задачи и проверки относятся к организации работы после выбора цели.

Подробные цифры агентной разработки вынесены в соседний разбор. Коммиты и скорость правок измеряют выпуск работы. Решение о сегменте требует своих наблюдений за пользователями.

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

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

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

В этот формат передают выбранный заказчиком эксперимент. Подписка не заменяет исследование рынка и решение о продукте. Готовый прототип возвращается в вашу проверку с участниками и критерием результата.

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

1. Завершайте текущий заход Discovery выбором следующей проверки и условием решения.

2. Запишите сегмент и рискованное предположение до заказа разработки.

3. Выбирайте способ проверки по вопросу. Иногда он обходится без кода.

4. Передавайте инженеру паспорт эксперимента и отдельно принимайте реализацию и результат для бизнеса.

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