Демо AI-помощника для службы поддержки выигрывает любое совещание. Модель за секунды читает тикет, находит похожие случаи и пишет черновик ответа, который оператору остается только отправить.
Через три месяца после запуска тот же помощник может оказаться в минусе. Самые активные клиенты присылают длинные переписки, контекст раздувается, каждый ответ стоит в несколько раз дороже, чем на демо, а качество проседает именно на редких запросах, где ошибка обходится дороже всего. Ни одна из этих проблем не видна в прототипе, и все они относятся к бизнес-модели, а не к модели машинного обучения. Пример иллюстративный, но мы будем к нему возвращаться.
Привычный каркас цифрового продукта (рынок, аудитории, ценностное предложение, каналы роста, удержание, юнит-экономика, цена) для AI-продукта по-прежнему нужен, но картину он не замыкает. ИИ приносит переменные, которых в классическом SaaS почти не было: стоимость обслуживания растет вместе с интенсивностью использования, качество результата вероятностное, модель деградирует со временем, а преимущество перед конкурентами все чаще складывается из данных, системы оценки, оркестрации и скорости, с которой команда учится. Отсюда вопрос, на который отвечает эта статья: как продакт-менеджеру заранее понять, превратится ли эффектный прототип в продукт, который окупается под реальной нагрузкой.
Вопросов, из которых складывается ответ, пять, и каждый неудобен:
- Хватит ли данных, чтобы система работала стабильно за пределами отобранных примеров?
- Как часто будет проседать качество и что это сделает с доверием пользователя?
- Удержится ли стоимость обслуживания, когда использование вырастет?
- Какие части решения строить как переиспользуемые способности, а какие оставить локальными продуктовыми механиками?
- Где лежит настоящая ценность: в сокращении труда, в точности, в снижении рисков или в новом пользовательском опыте?
Пока на них нет ответа, говорить о бизнес-модели рано, сколько бы восторга ни вызывал прототип.
Из-за этого меняется и сама роль. PM по-прежнему продумывает путь пользователя и экономику роста. Но теперь он отвечает и за поведение системы. Как спрос превращается в нагрузку на серверы? Как качество модели влияет на то, останутся ли клиенты и будут ли платить? Почему от данных зависит, смогут ли конкуренты вас скопировать? И как скорость экспериментов решает, долго ли продержится преимущество? PM уже не просто ведет дорожную карту. Он отвечает за жизнеспособность AI-продукта целиком.
Поэтому начинать приходится с проблемы, которую стоит усиливать ИИ, а выбор модели, интерфейс и модный use case подождут. Все остальное (карта возможностей, метрики, эксперименты, цена, ROI и организационная зрелость) вырастает из этого основания.
Три признака проблемы, которую стоит отдавать ИИ
Частая ошибка в AI-продуктах: думать, что стратегия начинается с выбора модели. Команда спорит, взять открытую модель или платный API, подключать ли поиск по базе знаний, дообучать ли модель, добавить ли помощника или агента. И только потом ищет реальную задачу. Для продуктового менеджера это почти всегда опасный путь. Обратный порядок обходится дешевле: сначала найти экономически важную проблему, а уже потом решать, какой стек ее потянет.
Проблема, которую действительно стоит решать с помощью ИИ, проходит три проверки. Прежде всего она повторяется достаточно часто, чтобы автоматизация или интеллектуальная помощь окупались. Она заметно влияет на бизнес: на выручку, затраты, скорость операций, качество решений, риски или пользовательский опыт. Наконец, по ней существует или может быть собран разумный объем данных, чтобы модель работала воспроизводимо на всем потоке, а не на трех эффектных примерах.
Частота, влияние и доступность данных вместе образуют первый фильтр для PM в AI-среде. Идея, которая не проходит хотя бы по одному из трех признаков, так и остается красивой и экономически слабой.
Большая часть верных стратегических решений принимается именно здесь. Разбор писем и документов, персонализация, умный поиск, краткие выжимки, автоматизация процессов, где каждый случай немного другой, классификация, прогнозы, помощь в решениях: все это кажется естественной территорией ИИ. Но перечислить мало.
PM нужно понять, где ИИ добавляет существенное преимущество относительно более простых инструментов. Если задачу можно надежно решить правилами, SQL-запросом, ручной операцией или классической аналитикой, AI-слой может оказаться дорогим и неоправданным. Если же скачок в качестве невозможен без того, что умеет только ИИ (писать текст, искать по смыслу, подстраиваться под пользователя), тогда ИИ перестает быть украшением и сам начинает приносить ценность.
В этот момент продакт-менеджер формулирует первый уровень AI-бизнес-модели: почему именно эта проблема должна стать точкой приложения интеллектуальной способности продукта. И это гораздо важнее, чем вопрос, какой именно стек будет использоваться дальше.
Ценность ИИ нужно определять через экономический механизм
Когда проблема выбрана, команды часто описывают пользу ИИ словами, которые ни к чему не обязывают: "улучшает UX", "делает продукт умнее", "повышает производительность". Для бизнес-модели этого мало. Нужен механизм: что именно меняется в экономике клиента или компании, когда система работает как задумано.
Механизмов немного, и они плохо уживаются в одной метрике успеха. ИИ может сокращать ручной труд, и тогда считать придется время и стоимость единицы операционной работы. Может ускорять процесс, сокращая путь до результата. Может повышать точность классификации, поиска, прогноза или маршрутизации, и здесь главным становится цена ошибки. Может раньше замечать риски, что особенно ценят в fraud, compliance, поддержке, операциях и финансовых продуктах. А может создавать новый формат взаимодействия (copilot, генерацию, интеллектуальные подсказки, полуавтономные сценарии), и тогда судьбу продукта решают принятие, удержание, готовность платить и глубина использования новой способности.
Вернемся к помощнику для поддержки. Если его ценность в экономии труда, успех измеряется минутами оператора на тикет и долей черновиков, отправленных без правок. Если в точности, важно другое: сколько обращений ушло не в ту очередь и во что обошлась каждая такая ошибка. Это два разных продукта с разными экспериментами, разными тарифами и разными аргументами для покупателя, хотя на демо они выглядят одинаково. Пока команда не выбрала основной механизм, все согласны, что ИИ "полезен", но никто не может сказать, какой эффект он обязан стабильно производить, чтобы продукт окупался.
От выбора механизма зависит и будущее ценообразование. То, за что клиент платит в AI-продукте, редко совпадает с тем, что дороже всего обходится в инфраструктуре: высокая ценность иногда достигается дешевым запросом, а самая дорогая функция порой почти ничего не дает пользователю. Поэтому отправной точкой для PM остается механизм ценности. Техническая эффектность функции здесь мало что решает.
Защитимость ИИ строит система вокруг модели
Следующая ловушка: переоценить саму модель. Когда AI-рынок только появился, легко было поверить, что преимущество дает выбор лучшей базовой модели. Сегодня это все менее верно. Модели становятся товаром, их легко заменить одну на другую, открытые модели быстро догоняют закрытые. А пользователь редко отличит "чуть лучшую" модель от "достаточно хорошей", если сам продукт слабый. Вывод для продуктового менеджера простой: защиту AI-продукту создает система вокруг модели. В реальной ML-системе код модели занимает малую часть, основную массу составляют данные, конфигурация, мониторинг и обвязка.
Такая система складывается из шести слоев.
В основе лежат свои данные, которые трудно скопировать. Над ними работают процессы, которые собирают, чистят и упорядочивают знания из вашей области и подают их модели. Поиск нужных документов перед ответом модели (так называемый RAG) нередко важнее, чем выбор самой модели.
Свой вклад дают дообучение модели, тонкие настройки и правила, по которым запросы распределяются между разными моделями. Глубокое встраивание в рабочие процессы и удобный интерфейс превращают продукт из "обертки" вокруг модели в привычный рабочий инструмент. И замыкает список инфраструктура быстрых экспериментов вместе с организационным циклом обучения, благодаря которым команда реагирует быстрее конкурентов.
Отсюда другой взгляд PM на roadmap. Он должен понимать, что некоторые вложения почти не видны пользователю, но делают продукт в разы устойчивее и ценнее. Хорошая проверка качества модели, запасной вариант на случай сбоя, продуманная связка шагов, умная работа с памятью, точный поиск: все это может дать больше долгого преимущества, чем еще одна "заметная" AI-фича. Поэтому в бизнес-модели ИИ считают прежде всего способности, которые компания строит как многоразовые активы. Список выпущенных функций говорит о защищенности гораздо меньше.
Карта возможностей показывает, где продукт сломается
Как только проблема и источник ценности определены, PM необходимо перевести стратегию в архитектуру возможностей. Для этого служит capability mapping. Красивая схема системы тут вторична, задача в том, чтобы понять: какие именно уровни возможностей нужны, как они связаны между собой, сколько стоят, какие риски создают и где находятся реальные точки масштабируемости.
Такую карту удобно строить по слоям. Слой данных: сбор и подготовка данных, поисковые базы, разметка и контроль качества. Слой моделей: базовые и дообученные модели, поиск по документам и проверка качества. Слой управления: шаблоны запросов, правила выбора модели, цепочки шагов агента, память и запасные варианты на случай сбоя. Слой пользователя: помощники, автоматические сценарии, рекомендации, дашборды и чат.
Эта многослойность важна потому, что AI-продукт почти никогда не проваливается на "идее" и очень часто проваливается на одном из скрытых слоев реализации.
Главная польза capability mapping для продуктового менеджера в том, что каждую способность можно связать с тремя вещами одновременно: пользовательской ценностью, техническими ограничениями и операционной стоимостью. Способность, которую нельзя объяснить как элемент бизнес-модели, так и остается просто "крутой".
Здесь и становятся видны компромиссы. Где лучше искать по документам, а где дообучать модель? Когда маленькая модель с умным распределением запросов лучше большой? Когда сохраненный готовый ответ полезнее дорогой генерации каждый раз заново? Инструменты сценарного моделирования полезны как способ проговорить эти компромиссы. Готовых ответов они не дают.
Приоритизация смещается от функций к AI-возможностям
В традиционном продакт-менеджменте приоритизация почти всегда начинается с уровня функций: что даст больший эффект, что быстрее доставить, что сильнее влияет на рост. В AI эта логика становится слишком поверхностной, потому что важнейшие решения касаются не только того, что видит пользователь, но и того, что система вообще способна выдерживать под нагрузкой.
Зрелые команды расставляют приоритеты для AI-возможностей наравне с функциями. Кроме важности для пользователя, PM смотрит на многое другое. Подходит ли модель к задаче? Хватает ли данных и хороши ли они? Насколько быстро и точно нужно отвечать? От скольких других частей зависит решение, какие в нем риски и окупится ли оно? Из этого следует, что иногда разумнее сначала строить capability, которая еще не выглядит "рыночной фичей", но открывает возможность для нескольких сильных сценариев в будущем. И наоборот, иногда яркая идея должна быть отложена, потому что базовая способность еще слишком слаба, дорога или ненадежна.
Такой подход требует от PM большей технической и финансовой зрелости. Зато он защищает от сценария, в котором внешне сильная функция стоит на слабой способности и обрушивает всю ценность при первом же росте нагрузки, а именно это и мешает AI-продукту масштабироваться.
Аналитика в AI должна связывать поведение пользователя и модели
Расставлять приоритеты по способностям имеет смысл, только если видно, что каждая из них делает с продуктом. Это уже вопрос к аналитике. Обычные продуктовые метрики остаются: активация, глубина использования, завершенные задачи, удержание, время до первой пользы. В AI к ним добавляются сэкономленное время и то, как каждая функция влияет на результат со временем. Но главное отличие в другом: наблюдать приходится одновременно за пользователем и за моделью, причем как за частями одной системы.
У модели свои важные показатели: как часто она права, сколько нужного находит, как часто выдумывает, как быстро отвечает, сколько стоит каждый ответ и не портится ли качество со временем. PM уже не может считать это делом одних дата-сайентистов: каждый показатель рано или поздно бьет по продуктовой воронке. В помощнике для поддержки цепочка выглядит так: выросла доля галлюцинаций в черновиках, операторы начали переписывать ответы с нуля, время на тикет вернулось к уровню до запуска, и через квартал клиент спрашивает, за что он платит. Рост задержки ответа бьет по использованию: оператор, который ждет черновик дольше, чем писал бы ответ сам, перестает нажимать кнопку. Рост стоимости одного ответа модели способен сделать растущий сегмент нерентабельным. А дрейф качества ухудшает опыт тихо, задолго до того, как это заметно в выручке.
Для помощника поддержки главная метрика очевидна: доля черновиков, отправленных без правок или с мелкой правкой. Порог успеха команда задает заранее, например 60% через восемь недель после запуска (порог стоит откалибровать на пилоте). Рядом обязательно стоит сторожевая метрика: доля повторных обращений клиента по тому же вопросу в течение семи дней. Если черновики отправляют чаще, а повторных обращений стало больше, операторы просто перестали проверять ответы, и выигрыш в минутах оплачивается недовольством клиентов.
К тому же ИИ редко влияет на одну точку воронки. Он может сократить onboarding, ускорить момент ценности, удержать пользователя персонализацией, подсказать upsell или предсказать churn. Поэтому AI-аналитике не место в отдельном "техническом дашборде": модельные метрики должны стоять рядом с бизнесовыми, иначе PM не увидит, как поведение модели превращается в деньги или в их потерю.
Эксперимент проверяет и спрос, и жизнеспособность
В AI-продуктах эксперимент выбирает не только удачный UX-вариант: через него проверяют, жизнеспособна ли сама модель бизнеса. ИИ приходится валидировать одновременно по нескольким осям: полезность для пользователя, качество модели, безопасность, системная нагрузка и экономическая устойчивость.
Offline-эксперименты нужны, чтобы быстро отсечь слабые варианты, сравнить модели и оценить базовую пригодность на исторических данных. Но они почти никогда не отражают реальное поведение системы под живой нагрузкой. Online-эксперименты, наоборот, показывают, как модель ведет себя в реальном продукте, как меняется поведение пользователя, возникают ли неожиданные ошибки, накапливается ли drift, растет ли стоимость использования. Поэтому AI-эксперимент отвечает сразу на два вопроса: что нравится пользователю и что действительно можно вывести в устойчивую эксплуатацию.
Отдельно важны защитные ограничения, специфичные для ИИ. Для поддержки это не абстракция: ответ бота клиент воспринимает как обещание компании, и неверно названная скидка или срок возврата превращается в претензию, которую придется удовлетворять за счет компании. PM должен понимать, какой уровень галлюцинаций допустим, какие типы контента запрещены, какие виды сбоев критичны, в какие моменты нужен fallback. Compliance и репутация здесь только часть ответа, на кону жизнеспособность продукта. Продукт, который красиво работает в среднем, но неуправляем в крайних сценариях, не становится масштабируемым бизнесом. Инструменты анализа экспериментов ценны тем, что помогают структурировать эту двойную проверку, где оценивают и эффект, и устойчивость, а умение "считать статистику" тут лишь входной билет.
Место за 30 долларов приносит минус 15: маржу съедает самый активный клиент
Заметнее всего AI-продукт отличается от классического SaaS структурой затрат. В традиционном ПО PM мог позволить себе смотреть на экономику на более высоком уровне: CAC, LTV, gross margin, retention. В AI этого уже недостаточно. Стоимость инференса становится одной из важнейших продуктовых переменных, а значит, финансовая модель должна начинаться с нее.
Стоимость обслуживания зависит от размера модели, объема текста на входе и выходе, частоты запросов, пиков трафика, того, как часто удается отдать сохраненный ответ, и того, как запросы распределяются между моделями. Даже небольшое изменение в продукте может сильно сдвинуть экономику. Например, больший контекст или режим "подумать подольше" делают ответы на вид лучше, но резко ухудшают юнит-экономику. Для AI-продуктов это повседневность. Поэтому PM обязан понимать хотя бы базовую экономику инференса: инженерной деталью она быть перестала.
Базовую экономику инференса удобно держать в голове как одну связку и следить, какой множитель растет быстрее спроса:
Стоимость запроса ≈ (токены_ввода + токены_вывода) × цена_за_токен
Эффективная стоимость ≈ Стоимость запроса × (1 - доля_ответов_из_кэша)
Маржа с запроса = цена_для_клиента - Эффективная стоимость
- токены_ввода растут вместе с длиной контекста и системного промпта: удлинение контекста бьет по себестоимости сильнее, чем кажется на демо.
- токены_вывода отражают генерацию; более "умный" reasoning-режим почти всегда означает и больше выходных токенов.
- цена_за_токен зависит от выбора модели и роутинга: часть запросов можно уводить на модель поменьше без потери качества.
- доля_ответов_из_кэша остается единственным членом, который снижает счет: чем больше повторяемых запросов закрывается кэшем, тем ниже эффективная стоимость.
Маржа уходит в минус, когда интенсивность использования обгоняет цену тарифа, и качество при этом может оставаться отличным. Поэтому смотреть нужно на стоимость запроса в самом активном сегменте: средняя по всем пользователям эту проблему прячет.
Посчитаем помощника для поддержки из начала статьи. Возьмем цены 3 доллара за миллион входных токенов и 15 за миллион выходных. Короткий тикет с демо занимает около 2000 токенов контекста и 300 токенов ответа: 2000 × 0,000003 + 300 × 0,000015 ≈ 0,0105 доллара, примерно цент. Длинная переписка активного клиента тянет 12 000 токенов контекста и 500 ответа: 12 000 × 0,000003 + 500 × 0,000015 ≈ 0,0435 доллара. Запрос подорожал вчетверо, хотя модель, промпт и интерфейс те же.
Теперь тариф. Допустим, место оператора продается за 30 долларов в месяц, оператор закрывает 40 тикетов в день, 840 за месяц, и на каждый тикет уходит в среднем два запроса к модели. У клиента с короткими тикетами себестоимость 840 × 2 × 0,0105 ≈ 17,6 доллара, маржа около 40%. У клиента, где половина тикетов длинные, она уже 420 × 2 × 0,0105 + 420 × 2 × 0,0435 ≈ 45,4 доллара. Каждое место приносит минус 15 долларов, и чем активнее клиент пользуется продуктом, тем глубже минус.
Выходов три, и у каждого своя цена. Можно обрезать историю переписки до последних сообщений плюс краткой выжимки: контекст падает в разы, но модель иногда теряет важную деталь из начала. Можно ввести лимит запросов в тарифе с доплатой сверх него: экономика выравнивается, но самые вовлеченные операторы начинают экономить на функции, которая им нравится. Можно направлять длинные, но типовые тикеты на модель поменьше: это дешевле, но требует набора тестов, который докажет, что маленькая модель справляется. Правило решения простое: если самый активный дециль клиентов обходится дороже, чем платит, один из этих рычагов включают до того, как тратить деньги на привлечение.
Кроме того, значительна стоимость жизненного цикла модели. Подготовка данных, разметка, fine-tuning, оценка, регрессионные тесты, масштабирование инфраструктуры, мониторинг и смягчение drift: все это формирует постоянный расход, которого в классическом SaaS либо нет, либо он гораздо слабее выражен. Инструменты экономического моделирования нужны PM, чтобы за подсчетом серверов увидеть долгосрочную экономику способности.
Шесть листов, по которым финмодель читает финансовый директор
Все цифры выше стоит собрать в одну таблицу, и порядок листов в ней важнее формул. Шесть листов позволяют проследить любую цифру маржи до допущения, из которого она выросла:
- Драйверы. Все, что приходится угадывать: число мест, тикетов на оператора, запросов на тикет, долю длинных переписок, цену места, лимит и доплату сверх него. На остальных листах руками ничего не вводится.
- Стоимость запроса. Токены ввода и вывода по цене выбранной модели, доля ответов из кэша, доля запросов, уходящих на большую модель или к человеку. В примере это 0,0105 доллара за короткий тикет и 0,0435 за длинный.
- Жизненный цикл. Ежемесячные расходы, не зависящие от отдельного запроса: разметка, прогоны оценки, дообучение, мониторинг, дежурный инженер. В пересчете на место они решают, может ли маленький клиент вообще быть прибыльным.
- Выручка. Сколько платит каждый сегмент при выбранной механике: фиксированное место, лимит с доплатой или тариф за объем. Сравнивать механики между собой этот лист не должен, он отражает уже выбранную.
- Сценарии. Три столбца: доля длинных тикетов как на пилоте, вдвое больше и та же доля с обрезанной историей переписки.
- Чувствительность. Для каждого драйвера изменение маржи от одного правдоподобного сдвига.
Читать модель стоит с шестого листа. В примере себестоимость места равна 17,6 + 55,4 × (доля длинных тикетов) доллара, поэтому каждые 10 пунктов доли длинных переписок добавляют около 5,5 доллара затрат и отнимают примерно 18 пунктов маржи. Место за 30 долларов уходит в ноль, когда длинных тикетов чуть больше пятой части. Если обрезать контекст длинного тикета с 12 000 до 6 000 токенов, запрос подешевеет с 0,0435 до 0,0255 доллара, и клиент с половиной длинных тикетов выйдет примерно в ноль. Такая таблица сразу показывает, куда идет следующий спринт: в длину контекста и долю длинных тикетов, задолго до спора о цене на сайте.
То же касается ROI: он может строиться на автоматизации, снижении ручного труда, росте точности решений, снижении рисков, росте производительности или новых доходных потоках. Но каждый из этих источников нужно прогнать через несколько сценариев, одного оптимистичного business case недостаточно. Сценарная модель показывает разброс альтернатив, и "правильного ответа" от нее ждать не стоит.
Когда можно запускать без финмодели?
Многие команды считают все это преждевременным. До запуска команда не знает ни реальной длины тикетов, ни того, как часто операторы будут нажимать кнопку, ни сколько токенов съест промпт после десятка доработок. Любая финмодель на этом этапе строится на догадках. К тому же цены на инференс за единицу качества у провайдеров год от года заметно снижаются. Проблема маржи, посчитанная сегодня, через полгода может исчезнуть сама. Значит, разумнее запустить продукт на небольшой группе, собрать реальные данные и только потом считать.
В одном случае они правы. Продукт еще ищет product-market fit, клиентов несколько десятков на пилотных условиях, а худшая себестоимость на клиента ничтожна рядом с суммой контракта. Неделя на финмодель здесь означает неделю, не потраченную на проверку того, нужен ли продукт вообще.
Аргумент перестает работать в момент, когда публичная цена появляется на сайте для самообслуживания. Цену поменять труднее, чем архитектуру: место за 30 долларов без лимитов сложно забрать обратно, а громче всех возмущаются как раз самые активные пользователи. Компромисс выглядит так. Запускайте пилот без публичного тарифа, с первого дня пишите в лог токены и запросы по каждому клиенту и заранее задайте порог пересмотра, например месячную себестоимость клиента выше половины его платежа. Финмодель строится, когда сработает порог или когда продукт идет в общий доступ, смотря что наступит раньше.
Три фильтра, которые дешевле всего отсеивают слабые идеи
Все перечисленное легко разложить по отдельным документам: карта capability в одном месте, финмодель в другом, отчет об эксперименте в третьем, и ни один не ссылается на соседа.
Управляемой AI-бизнес-модель становится тогда, когда эти артефакты выстроены в порядке, где каждый следующий опирается на предыдущий. Сначала проблема и механизм ценности. Затем данные: достаточно ли их, насколько они качественны, где пробелы. Потом capability mapping, критерии оценки модели и циклы экспериментов. Финансовая модель осмысленна только поверх этого, сценарное планирование еще позже, а в самом конце встает вопрос организационной зрелости: есть ли у команды и компании нужные роли, процессы, скорость обучения и governance-практики.
Абсолютной уверенности такой порядок не дает. Он делает другое: превращает хаотичный набор гипотез в повторяемый цикл обучения и заменяет ощущение "мы делаем что-то инновационное" пониманием того, как способности продукта становятся устойчивой экономикой.
Тот же порядок работает и как фильтр для решения об инвестициях. Если команда не может назвать проблему, которая повторяется часто, заметно влияет на бизнес и обеспечена данными, разговор о модели преждевременен.
Если проблема есть, но неясен экономический механизм (снижение затрат, точность, риски или новый опыт), неясно и то, что мерить в эксперименте. Если механизм ясен, следующим стоп-фактором становится маржа с запроса по самому активному сегменту: пока она не посчитана, pricing остается догадкой. В примере с помощником для поддержки решающим оказался как раз третий фильтр: демо считали на коротких тикетах, а платить пришлось за длинные.
Только пройдя эти три проверки, имеет смысл вкладываться в capability, которых пользователь не видит: систему оценки модели, fallback, retrieval, маршрутизацию между моделями. Через год именно они отличают продукт, который держится под нагрузкой и плохо копируется, от дорогой обертки вокруг чужого API. И именно за них PM приходится бороться в roadmap, когда рядом стоит очередная заметная AI-фича с красивым демо.