Building AI product sense, part 2

Развитие AI product sense, часть 2

Еженедельный ритуал, который поможет понимать и проектировать надёжные AI-продукты для хаотичного мира

👋 Привет, я Lenny. Каждую неделю я отвечаю на вопросы читателей о создании продуктов, ускорении роста и развитии карьеры. Больше материалов: Lenny's Podcast | How I AI | Lennybot | мои любимые курсы по AI/PM, курс публичных выступлений и copilot для подготовки к интервью.

P.S. Подписчики получают бесплатный год Lovable, Manus, Replit, Gamma, n8n, Canva, ElevenLabs, Amp, Factory, Devin, Bolt, Wispr Flow, Linear, PostHog, Framer, Railway, Granola, Warp, Perplexity, Magic Patterns, Mobbin, ChatPRD и Stripe Atlas. Да, это правда.

Во второй части нашей подробной серии о развитии AI product sense (не пропустите первую часть) доктор Marily Nika — давний AI PM в Google и Meta, и один из первых AI-преподавателей — делится простым еженедельным ритуалом, который вы можете внедрить уже сегодня, чтобы быстро развить AI product sense. Приступим.

Больше материалов от Marily можно найти в её курсе AI Product Management Bootcamp & Certification (также доступен для корпоративных сессий) и в недавно запущенном курсе AI Product Sense and AI PM Interview prep (оба курса со скидкой 15% по этим ссылкам). Также можно посмотреть её бесплатный Lightning Lesson о том, как преуспеть в роли senior IC PM в эпоху AI, и подписаться на её рассылку.

Meta недавно добавила новый этап PM-интервью — первое серьёзное изменение в PM-цикле компании за более чем пять лет. Он называется «Product Sense with AI», и кандидатов просят проработать продуктовую задачу с помощью AI в режиме реального времени.

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

Этот сдвиг отражает нечто большее. AI product sense — понимание того, что модель умеет и где она ошибается, и работа в этих ограничениях для создания продукта, который люди полюбят, — становится новым ключевым навыком продакт-менеджмента.

За последний год я наблюдала, как один и тот же паттерн повторялся в разных командах на работе и на моих тренингах: AI прекрасно работает в контролируемом потоке... а потом ломается в продакшене из-за горстки предсказуемых режимов сбоя. Неудобная правда в том, что самая сложная часть разработки AI-продукта наступает, когда приходят реальные пользователи с хаотичными вводами, неясными намерениями и нулевым терпением. Например, агент службы поддержки может казаться невероятным в демо, а после запуска тихо терять доверие пользователей, уверенно отвечая на двусмысленные или неконкретные вопросы (например, «Это хорошо?») вместо того, чтобы остановиться и попросить уточнения.

За 10 лет работы над функциями распознавания речи и идентификации голоса для разговорных платформ и персонализированных опытов (ассистенты на устройстве и разнообразные аппаратные портфели) я начала использовать простой повторяемый workflow для обнаружения проблем, которые иначе проявились бы спустя недели. Сначала я развивала этот AI product sense для себя, а потом — с командами и студентами. Это не теория и не фреймворк, а скорее важная практика, которая даёт раннюю обратную связь о поведении модели, режимах сбоя и компромиссах, заставляя вас увидеть, выживет ли AI-продукт при контакте с реальностью, до того как пользователи научат вас этому жёстким путём. Когда я запускаю этот процесс, быстро происходят две вещи: я перестаю удивляться поведению модели, потому что уже сама прожила странные случаи. И я получаю ясность в том, что является продуктовой проблемой, а что — ограничением модели.

В этом посте я расскажу о трёх шагах для развития AI product sense:

1. Картируйте режимы сбоя (и желаемое поведение)2. Определите минимально жизнеспособное качество (MVQ)3. Спроектируйте guardrails там, где поведение ломаетсяКак только мышца AI product sense разовьётся, вы сможете оценивать продукт по нескольким конкретным измерениям: как модель ведёт себя при неоднозначности, как пользователи переживают сбои, где зарабатывается или теряется доверие и как меняются затраты при масштабировании. Речь о понимании и предсказании того, как система отреагирует на разные обстоятельства.

Другими словами, работа расширяется с «Хорошая ли это продуктовая идея?» до «Как этот продукт будет вести себя в реальном мире?».

Давайте начнём развивать AI product sense.

Картируйте режимы сбоя (и желаемое поведение)

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

Я провожу следующие ритуалы раз в неделю, обычно по утрам в среду перед первой встречей, на любом AI-workflow, который я сейчас разрабатываю. Вместе они занимают меньше 15 минут и стоят каждой секунды. Результаты стабильно выводят на поверхность проблемы, которые иначе появились бы намного позже в продакшене.

Ритуал 1: Попросите модель сделать что-то заведомо неправильное (2 мин.)

Цель: Понять склонность модели навязывать структуру хаосу

Возьмите тот тип хаотичных, полусформированных, эмоционально непоследовательных данных, с которыми каждый PM сталкивается ежедневно — Slack-треды, заметки со встреч, комментарии в Jira — и попросите модель извлечь из них «стратегические решения». Именно здесь генеративные модели раскрывают свой самый опасный паттерн:

Столкнувшись с хаосом, они уверенно изобретают структуру.

Вот пример хаотичного Slack-треда:

Alice: «Stripe снова падает для пользователей из EU?»

Ben: «без понятия, может, вебхук?» Sara: «лол, можем не переименовывать модалку онбординга снова?» Kyle: «Так и не разобрался, что делать с тёмной темой» Alice: «Онбординг нужно выкатить к четвергу» Ben: «Стоп, баннер всё ещё сломан на мобильных???» Sara: «Я могу пофиксить копирайт потом»

Я попросила модель извлечь «стратегические продуктовые решения» из этого треда, и она уверенно нагаллюцинировала roadmap, назначила неправильных владельцев и превратила случайные комментарии в обязательства. Это та сигнатура сбоя, вокруг которой должен проектировать каждый AI PM:

Выглядит авторитетно, чисто, структурированно. И это полностью неверно.

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

Вот что именно нужно сделать:

1. Повторно прогоните тот же Slack-тред через модель

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

Пример (вставляете Slack-тред):

На основе этой Slack-дискуссии составь наш roadmap на Q4.

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

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

Добавьте одну короткую строку, объясняющую ожидаемое поведение. Например:

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

Запустите этот промпт на том же самом Slack-треде. Правильное, заслуживающее доверия поведение будет таким:

Этот ответ признаёт отсутствие чётких решений, задаёт уточняющие вопросы и выводит на поверхность полезную структуру без изобретения фактов («ключевые темы»). Он избегает назначения владельцев, если это не указано явно, и подсвечивает неопределённости вместо того, чтобы их скрывать.

3. Сравните два вывода — и приведшие к ним вводы — бок о бок

Этот контраст между двумя выводами выше — уверенная галлюцинация против скромной ясности — учит вас тому, как модель ведёт себя сегодня и к чему вам нужно проектировать. И именно в этом контрасте AI product sense оттачивается быстрее всего.

Вы ищете:

Что изменилось?Какой guardrail исправил галлюцинацию?Что нужно модели, чтобы вести себя надёжно? (Явные ограничения? Лучший контекст? Более узкий скоупинг?)Кажется ли «хорошая» версия готовой к запуску или всё ещё хрупкой?Что испытает пользователь в каждой версии?

4. Зафиксируйте пробелы — они становятся продуктовым требованием

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

Теперь вы знаете, где продукт ломается и каково его желаемое поведение. Дальше в этом руководстве я покажу конкретные примеры того, как на практике выглядят promt- и дизайн-guardrails и retrieval, и как решить, когда их добавлять.

Ритуал 2: Попросите модель сделать что-то неоднозначное (3 мин.)

Цель: Понять семантическую хрупкость модели

Неоднозначность — это криптонит для вероятностных систем, потому что если модель не до конца понимает намерение пользователя, она заполняет пробелы своей лучшей догадкой (то есть галлюцинациями, плохими идеями). Именно тогда доверие пользователей начинает трескаться. Попробуйте, например, загрузить PRD в NotebookLM и попросить его «Суммируй этот PRD для VP of Product».

Как попробовать это за 2 минуты (NotebookLM):

Откройте NotebookLM → создайте новый ноутбук

Загрузите PRD (хорошо подойдёт Google Doc/PDF)

Спросите: «Суммируй это для руководителей и перечисли топ-5 рисков и открытых вопросов».

Делает ли модель следующее:

чрезмерно суммирует?цепляется за одну неактуальную деталь?игнорирует оговорки?предполагает не ту аудиторию?

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

Что вы узнаёте здесь — это где модель путается, и именно там ваш продукт должен вмешаться и проделать работу по снижению неоднозначности. Это может означать просьбу к пользователю выбрать цель («Суммировать для кого?»), предоставление модели большего контекста или ограничение действия так, чтобы модель не могла сойти с пути. Вы не пытаетесь «обмануть» модель; вы пытаетесь понять, где ломается коммуникация, чтобы предотвратить недопонимание через дизайн.

Неоднозначные промпты: что тестировать, что ломается, что делать

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

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

Ритуал 3: Попросите модель сделать что-то неожиданно сложное (3 мин.)

Цель: Понять первую точку сбоя модели

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

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

Примечание: Это ещё не финальное решение; это желаемое поведение. В разделе про guardrails далее я покажу, как превратить это в явное правило в продукте (промпт + UX + fallback-поведение).

Пример 1: «Сгруппируй эти 40 багов в темы и предложи roadmap».

Пример 2: «Суммируй этот PRD и помечь риски для руководства».

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

Со временем такая работа также начинает выводить на поверхность эффекты второго порядка — моменты, когда маленькая AI-функция тихо перекраивает рабочие процессы, дефолты или ожидания. Системные инсайты приходят позже, когда основы заложены прочно. Первая цель — понять поведение.

Определите минимально жизнеспособное качество (MVQ)

Даже когда вы понимаете режимы сбоя модели и спроектировали продукт вокруг них, почти невозможно полностью предсказать, как AI-функции будут вести себя, когда столкнутся с реальным миром, но производительность почти всегда падает, как только они выходят из контролируемой среды разработки. Поскольку вы не знаете, как и насколько она упадёт, один из лучших способов держать планку высокой с самого начала — определить минимально жизнеспособное качество (MVQ) и сверяться с ним по продукту на протяжении всей разработки.

Сильное MVQ явно определяет три порога:

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

Также важен в MVQ cost envelope продукта: примерный диапазон того, во сколько эта функция обойдётся при работе в масштабе для ваших пользователей.

Конкретный пример MVQ — из моего личного опыта. Я провела годы, работая над распознаванием речи и идентификацией спикера — областью, где разрыв между лабораторной точностью и точностью в реальном мире болезненно очевиден.

Я до сих пор помню демо, где модель показывала более 90% точности в контролируемых тестах, а потом полностью разваливалась при первой же попытке использовать её в реальном доме. Лающая собака, работающая посудомойка, кто-то говорит из другой комнаты — и вдруг «отличная» модель чувствуется сломанной. И с точки зрения пользователя она была сломанной.

Для идентификации спикера в AI-функциях, идущих от умных колонок, MVQ способности определять, кто говорит, выглядел бы так:

Приемлемая планка

Правильно идентифицирует спикера в x% случаев в типичных домашних условияхИзящно восстанавливается при неуверенности («Я не уверен, кто говорит — использовать твой профиль или продолжить как гость?»)

Планка восхищения

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

Пользователи перестают повторяться или переформулировать командыКоррекции «Нет, я имел в виду...» резко падают

Правило большого пальца: если 8 или 9 из 10 попыток работают без повтора в реалистичных условиях, это ощущается магически. Если 1 из 5 требует повтора, доверие быстро разрушается. MVQ также зависит от фазы, в которой вы находитесь. В закрытой бете пользователи часто терпят шероховатости, потому что ожидают итераций. При широком запуске те же режимы сбоя ощущаются как поломка.

Для функции распознавания речи вот несколько примеров оценки восхищения:

Тест с фоновым хаосом: включите видео на фоне, пока два человека перебивают друг друга, и посмотрите, отвечает ли ассистент правильно без вопроса «Извини, можешь повторить?»Кухонный тест в 18:00: работает посудомойка, дети разговаривают, лает собака — и умная колонка всё равно узнаёт тебя и даёт персонализированный ответ без прерывания «Я не смог распознать твой голос».Тест с коррекцией в середине команды: вы говорите «Поставь таймер на 10 минут... вообще-то, на 5», и он правильно обновляется, а не придерживается изначальной инструкции.

Планка «не запускать»

Неправильно идентифицирует спикера более чем в y% случаев в критических потоках (покупки, сообщения, персонализированные действия)Заставляет пользователей повторяться много раз только для того, чтобы быть распознанными

Вы, возможно, заметили, что я не присвоила конкретные значения каждой планке. Это потому, что конкретные пороги для MVQ (ваши планки «приемлемой», «восхищения» и «не запускать») не фиксированы. Они сильно зависят от вашего стратегического контекста.

Пять факторов стратегического контекста, которые поднимают или опускают планку MVQ

Вот пять факторов, которые чаще всего определяют, где должна быть установлена эта планка, и как они меняют ваше продуктовое решение:

Оценка cost envelope

Одна из самых распространённых ошибок новых AI PM — влюбиться в магическое AI-демо, не проверив, финансово ли оно жизнеспособно. Поэтому важно оценивать cost envelope AI-продукта или функции рано.

Cost envelope = примерный диапазон того, во сколько эта функция обойдётся при работе в масштабе для ваших пользователей

Вам не нужны идеальные цифры, но нужен ориентир. Начните с:

Какова стоимость модели за вызов (примерно)?Как часто пользователи будут запускать это в день/месяц?Каков худший сценарий (power users, edge cases)?Может ли кеширование, меньшие модели или дистилляция снизить это?Если использование вырастет в 10 раз, математика всё ещё сходится?

Пример: снова AI-заметки со встреч

Стоимость за вызов: ~$0.02 за обработку 30-минутной транскрипцииСреднее использование: 20 встреч/пользователь/месяц → ~$0.40/месяц/пользовательТяжёлые пользователи: 100 встреч/месяц → ~$2.00/месяц/пользовательС кешированием и меньшей моделью для встреч «низкой важности» вы, возможно, доведёте это до ~$0.25–$0.30/месяц/пользователь в среднем

Теперь вы можете вести реальный разговор:

Функция, которая фактически стоит $0.30/пользователь/месяц и драйвит retention — это no-brainer.Функция, которая в итоге стоит $5/пользователь/месяц с неясным влиянием — это бизнес-проблема.

Это ключевая часть AI product sense: Действительно ли то, что вы предлагаете, имеет смысл для бизнеса?

Спроектируйте guardrails там, где поведение ломается

Теперь, когда вы лучше понимаете, где поведение модели ломается и на что вы смотрите для разрешения запуска, пришло время кодифицировать некоторые guardrails и заложить их в продукт. Хороший guardrail определяет, что продукт должен делать когда модель достигает своих пределов, чтобы пользователи не запутались, не были введены в заблуждение и не потеряли доверие. На практике guardrails защищают пользователей от переживания режимов сбоя модели. В стартапе, с которым я сотрудничала, мы построили AI-функцию для повышения продуктивности команды, которая суммировала длинные Slack-треды в «решения и action items». В тестировании она работала хорошо — пока не начала назначать владельцев action items, когда никто на самом деле ни на что не соглашался. Иногда она даже выбирала не того человека.

Поскольку моя команда развила свой AI product sense, мы выяснили, что фикс — это новый guardrail в продукте, а не другая базовая модель.

Поэтому мы добавили одно простое правило в системный промпт (в данном случае просто строку дополнительной инструкции):

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

Это единственное ограничение почти сразу устранило самую большую проблему доверия.