AI Product Discovery

Большинство продуктовых идей умирает не потому, что их плохо реализовали, а потому, что они с самого начала были фантазией, не привязанной к рынку. В этом гайде я показываю, как превратить Product Discovery из творческого хаоса в вычислительную систему: от сигналов рынка до проверяемых гипотез и Lean Canvas — с ИИ-агентами на каждом этапе. Материал собран из моих побед в бизнес-акселераторах и опыта работы CTO в международной венчурной студии. Поехали!

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

Почему Discovery не масштабируется

В большинстве компаний Discovery — это не система, а набор плохо связанных активностей. Выглядит это всегда одинаково:

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

Роль ИИ в этой системе принципиальна: ИИ — не генератор идей. Он играет четыре роли, и ни одна из них не отменяет человека:

А решения принимает человек. Дальше — почему это так важно.

Главный риск рождается до разработки

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

Распространённая ловушка — надежда, что прототип и MVP всё покажут. Не покажут. Слабую гипотезу они не исправляют, а делают дороже: прототип выглядит убедительно, MVP обрастает кодом, людьми и обязательствами, затраты становятся невозвратными. И только на MVP выясняется, что онбординг не проходят, пользователи не возвращаются и никто не платит. Задача Discovery — дать слабым направлениям умереть быстро и дёшево, до разработки.

То же относится и к Lean Canvas: это результат исследования, а не его старт.

Пайплайн: как генерация идей становится системой

Полная логика системы — это конвейер, где выход одного этапа строго является входом следующего. Именно эта связь превращает разовые генерации в воспроизводимый процесс.

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

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

Архитектурно зрелая система складывается из семи слоёв:

Старт: не идея, а сигнал рынка

Система стартует не с вопроса «какой продукт мы хотим сделать?», а с вопроса «какой сигнал мы наблюдаем?». Сигналы сходятся в карту реальности — продукты, участники, деньги и проблемы конкретного рынка. И только из этой карты рождается идея.

Откуда берутся сигналы? Из двух контуров. Внешний говорит о рынке:

Внутренний контур говорит о наших пользователях:

Критично важное различие: яркость сигнала — не то же самое, что его надёжность. Одна жалоба может быть случайностью, один громкий запуск — маркетингом, одна инвестиция — ошибкой фонда. Сильный сигнал — это проблема, которая повторяется в независимых источниках: сайты, отзывы, интервью, CRM и поведение указывают в одну сторону. Мы оцениваем повторяемость, независимость и свежесть. Одиночный инсайт — кандидат. Паттерн — основание. Product Hunt и данные фондов при этом — полезные радары, но не источники истины: голоса — не выручка, запуск — не PMF, инвестиция — ещё не устойчивый спрос.

Рамка исследования и поиск продуктов

Прежде чем искать, фиксируем рамку — исследовательский контракт. Определяем: B2B или B2C, географию, размер компаний, тип продукта, стадию рынка, бизнес-модели. Исключаем: консалтинг, каталоги, исследовательские проекты, неактивные стартапы, продукты без оффера. Фиксируем: количество результатов, глубину анализа, формат данных, список источников. Чем точнее определён вход, тем меньше мусора уходит дальше — а главное, контракт позволяет повторить исследование по тем же правилам.

Дальше — поиск. Ловушка в том, что одна категория скрывается за десятками названий: AI Sales Assistant, Revenue Intelligence, AI SDR, Sales Automation, Lead Gen Agent — всё это может быть одним рынком. Один запрос пропустит половину рынка, поэтому система ищет по множеству формулировок и собирает карту решений: название, сайт, источник, дата. Цель — полнота и разнообразие, а не максимум ссылок и не «победители».

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

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

И про инженерную реальность: блокировки ботов, JavaScript-контент, региональные ограничения, редиректы. Нужны повторы, браузерный режим, резервные страницы; причины ошибок фиксируются, а не замалчиваются. Железное правило: нет данных — значит нет данных. Иначе модель с удовольствием опишет продукт, которого не существует.

Продуктовый паспорт и дисциплина знаний

Собранные данные превращаются в продуктовый паспорт — стандартизированный артефакт, который позволяет сравнивать решения, а не рекламные формулировки. В нём два блока: суть — что за продукт, какую работу выполняет, кто пользуется, кто покупает, «вход → операции → выход», обещанная ценность; и атрибуты — категория, модель монетизации, цены, интеграции, сценарии, ограничения, требования к внедрению. Например: «ИИ-ассистент продаж: CRM и почта → ресёрч и квалификация → готовый контакт».

В B2B паспорт обязан отражать всю цепочку ролей — усреднённый «клиент» даёт усреднённое и слабое ценностное предложение:

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

Конкуренты: структура пространства решений

Конкурентный анализ — это не таблица функций, а структура пространства решений. Он отвечает на четыре вопроса:

Правильный вопрос: «как решается работа клиента сегодня?» — вместо «что нам добавить в продукт?».

Конкуренты бывают трёх типов:

Новый продукт конкурирует с привычками, рисками и доверием, а не только с функциями. И самый сильный конкурент чаще всего — именно заменитель: знакомый, предсказуемый, доверенный.

По каждому конкуренту смотрим две стороны — что продукт делает (функции, сценарии, интеграции, внедрение) и как он продаётся (позиционирование, цены, сегменты, каналы, отзывы). Отдельное золото — сопоставление обещаний с реальным опытом:

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

Сегментация: для кого именно

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

Алгоритм сегментации простой, но порядок шагов принципиален — название появляется в конце, а не в начале:

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

ICP: мост между рынком и клиентом

Ideal Customer Profile — мост между сегментом и конкретным клиентом, у которого боль сильна, а способность купить высока. В ICP входят тип и отрасль, фирмографика, география, поведение, цели, триггеры покупки, процесс решения, бюджет, каналы и возражения. Формат работает и для B2B, и для B2C: в B2B это отрасль, размер компании, роли и процесс принятия решения, в B2C — пол, возраст, доход, география, привычки и контекст использования. Чем больше измерений — тем точнее профиль и тем дешевле обходится поиск своего клиента. Каждый элемент работает на практику: триггеры показывают момент возникновения спроса, процесс решения задаёт структуру продаж, каналы — способ привлечения, возражения превращаются в требования к продукту и онбордингу.

Про триггеры стоит сказать отдельно: проблема живёт годами — спрос появляется после события. Вот типичные моменты, когда компания начинает искать решение:

ICP отражает всю систему принятия решения — инициатора, пользователя, ИТ, держателя бюджета и потенциального блокера, — а не только конечного пользователя. И в нём действует та же дисциплина честности: факты отдельно («размер компаний ← позиционирование конкурентов», «цены ← открытые тарифы»), допущения отдельно («бюджет ≈ выводится из тарифов»). Пустое поле — скрытый пробел. Помеченное допущение — проверяемая гипотеза. ICP — набор проверяемых предположений, а не художественный портрет.

Интервью: симуляция, вопросы и язык клиента

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

В реальных интервью работает одно правило: исследуем факты прошлого, а не отношение к нашей идее.

Всего 8–10 вопросов: контекст · боли · решения · критерии · страхи · ожидания. Отдельная ценность — язык клиента. Корпоративное «у меня недостаточная эффективность процесса» ничего не даёт. Живое «я трачу на это два часа — и потом всё равно всё перепроверяю» — готовый материал для формулировок болей, сообщений и следующих вопросов. Но даже реальная яркая цитата — ещё не основание продукта: повторение внутри симуляции не равно повторению на рынке.

Pain Map: от стенограммы к структуре

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

По каждой значимой боли копаем глубже: причина → обход → результат. Боль «устаревшие данные в CRM» может иметь разные первопричины — неудобный интерфейс, отсутствие стандарта, отсутствие мотивации — и разные первопричины требуют разных решений. Обходные пути (таблицы, аутсорс, свой скрипт) показывают реального конкурента и готовность тратить ресурсы. А желаемый результат — изменение состояния, а не функция: «ресёрч клиента за одну минуту вместо десяти — с уверенностью в данных».

JTBD: клиент нанимает прогресс

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

Формулировка — без функций, технологий и интерфейсов. И обратите внимание на struggle: это не «нет автоматизации», а «собираю вручную и всё равно боюсь ошибиться». У каждой работы три уровня:

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

Смену решения описывают четыре силы прогресса — и продукт должен не только создавать ценность, но и снижать стоимость смены поведения:

Завершают JTBD-этап критерии успеха и момент прогресса. Критерии: результат за час, не меньше 80% корректно, автоматическая передача дальше, проверяемость. Момент прогресса — первое событие, когда клиент получил то, что раньше стоило часов. Регистрация — не ценность. Ценность — первый значимый результат.

Ценностное предложение и цепочка ценности

Value Proposition Canvas в этой системе не заполняется заново — он собирается из результатов этапов: Jobs приходят из JTBD, Pains — из Pain Map, Gains — из желаемых результатов; каждый Pain Reliever связан с конкретной болью, каждый Gain Creator — с конкретным результатом. Случайных функций на стороне продукта не бывает — у каждой есть причина. Проверка ценности — цепочка «проблема → механизм → результат»:

Граф знаний и сильные гипотезы

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

Гипотеза рождается из причинной цепи: боль → выгода → JTBD → механизм → ожидаемое изменение поведения.

У каждой гипотезы — обоснование, связанная боль, JTBD, метрика проверки, ожидаемый результат и эксперимент. Хорошая гипотеза связывает метрики трёх уровней:

Способ проверки подбирается по цене: прототип, Fake Door, Wizard of Oz, консьерж, рекламный тест, интервью, пилот, A/B-тест. Чем меньше мы знаем — тем дешевле должен быть первый эксперимент.

Приоритизация и сборка артефактов

Когда гипотез становится много, нужна общая система координат — RICE:

Но у RICE есть пределы: Reach, Impact, Confidence и Effort — оценки, а не факты; синтетическое интервью не может давать ту же уверенность, что реальные данные; а меньший балл может выигрывать стратегически — уникальные данные, платформенный потенциал, новый рынок. Поэтому рядом с RICE всегда стоит Strategic Fit: компетенции, доступ к клиентам, капитал, миссия, архитектура бизнеса. Балл помогает структурировать решение — но не превращает его в истину.

Только теперь собирается Lean Canvas — из графа, а не из воображения. Вот классический шаблон:

Каждый блок наследует происхождение:

А из одного графа знаний дальше собирается весь комплект артефактов — и главная боль звучит одинаково в продукте, на лендинге, в метриках и в демо:

Масштабирование, стоимость и человек

У автоматизации есть обратная сторона — комбинаторный взрыв: 10 продуктов × 5 сегментов × 4 JTBD × 5 гипотез = 1000 направлений. Поэтому система должна не только расширять пространство, но и сжимать его:

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

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

Идея ничего не стоит. Стоит только её исполнение. Конкурентное преимущество сегодня — это скорость превращения предположений в надёжное знание. Именно её и даёт AI Product Discovery: не машину для генерации красивых документов, а производственную систему, в которой каждая идея имеет происхождение, каждое утверждение — источник и уровень уверенности, а каждая гипотеза — путь к дешёвой проверке.