Building AI product sense, part 2

Building AI product sense, part 2

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

A weekly ritual to help you understand and design trustworthy AI products for a messy world

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

👋 Hey there, I’m Lenny. Each week, I answer reader questions about building product, driving growth, and accelerating your career. For more: Lenny’s Podcast | How I AI | Lennybot | My favorite AI/PM courses, public speaking course, and interview prep copilot.

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

P.S. Subscribers get a free year of Lovable, Manus, Replit, Gamma, n8n, Canva, ElevenLabs, Amp, Factory, Devin, Bolt, Wispr Flow, Linear, PostHog, Framer, Railway, Granola, Warp, Perplexity, Magic Patterns, Mobbin, ChatPRD, and Stripe Atlas. Yes, this is for real.

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. Да, это правда.

In part two of our in-depth series on building AI product sense (don’t miss part one), Dr. Marily Nika—a longtime AI PM at Google and Meta, and an OG AI educator—shares a simple weekly ritual that you can implement today that will rapidly build your AI product sense. Let’s get into it.

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

For more from Marily, check out her AI Product Management Bootcamp & Certification course (which is also available for private corporate sessions) and her recently launched AI Product Sense and AI PM Interview prep course (both courses are 15% off using these links). You can also watch her free Lightning Lesson on how to excel as a senior IC PM in the AI era, and subscribe to her newsletter.

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

Meta recently added a new PM interview, the first major change to its PM loop in over five years. It’s called “Product Sense with AI,” and candidates are asked to work through a product problem with the help of AI, in real time.

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

In this interview, candidates aren’t judged on clever prompts, model trivia, or even flashy demos. They are evaluated on how they work with uncertainty: how they notice when the model is guessing, ask the right follow-up questions, and make clear product decisions despite imperfect information.

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

That shift reflects something bigger. AI product sense—understanding what a model can do and where it fails, and working within those constraints to build a product that people love—is becoming the new core skill of product management.

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

Over the past year, I’ve watched the same pattern repeat across different teams at work and in my trainings: the AI works beautifully in a controlled flow . . . and then it breaks in production because of a handful of predictable failure modes. The uncomfortable truth is that the hardest part of AI product development comes when real users arrive with messy inputs, unclear intent, and zero patience. For example, a customer support agent can feel incredible in a demo and then, after launch, quietly lose user trust by confidently answering ambiguous or underspecified questions (for example, “Is this good?”) instead of stopping to ask for clarification.

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

Through my work shipping speech and identity features for conversational platforms and personalized experiences (on-device assistants and diverse hardware portfolios) for 10 years, I started using a simple, repeatable workflow to uncover issues that would otherwise show up weeks later, building this AI product sense for myself first, and then with teams and students. It’s not a theory or a framework but, rather, important practice that gives you early feedback on model behavior, failure modes, and tradeoffs—forcing you to see if an AI product can survive contact with reality before your users teach you the hard way. When I run this process, two things happen quickly: I stop being surprised by model behavior, because I’ve already experienced the weird cases myself. And I get clarity on what’s a product problem vs. what’s a model limitation.

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

In this post, I’ll walk through my three steps for building AI product sense:

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

1. Map the failure modes (and the intended behavior)
2. Define the minimum viable quality (MVQ)
3. Design guardrails where behavior breaks

Once that AI product sense muscle develops, you should be able to evaluate a product across a few concrete dimensions: how the model behaves under ambiguity, how users experience failures, where trust is earned or lost, and how costs change at scale. It’s about understanding and predicting how the system will respond to different circumstances.

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

In other words, the work expands from “Is this a good product idea?” to “How will this product behave in the real world?”

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

Let’s start building AI product sense.

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

Map the failure modes (and the intended behavior)

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

Every AI feature has a failure signature: the pattern of breakdowns it reliably falls into when the world gets messy. And the fastest way to build AI product sense is to deliberately push the model into those failure modes before your users ever do.

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

I run the following rituals once a week, usually Wednesday mornings before my first meeting, on whatever AI workflow I’m currently building. Together, they run under 15 minutes, and are worth every second. The results consistently surface issues for me that would otherwise show up much later in production.

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

Ritual 1: Ask a model to do something obviously wrong (2 min.)

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

Goal: Understand the model’s tendency to force structure onto chaos

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

Take the kind of chaotic, half-formed, emotionally inconsistent data every PM deals with daily—think Slack threads, meeting notes, Jira comments—and ask the model to extract “strategic decisions” from it. That’s because this is where generative models reveal their most dangerous pattern:

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

When confronted with mess, they confidently invent structure.

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

Here’s an example messy Slack thread:

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

Alice: “Stripe failing for EU users again?”

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

Ben: “no idea, might be webhook?”
Sara: “lol can we not rename the onboarding modal again?”
Kyle: “Still haven’t figured out what to do with dark mode”
Alice: “We need onboarding out by Thursday”
Ben: “Wait, is the banner still broken on mobile???”
Sara: “I can fix the copy later”

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

I asked the model to extract “strategic product decisions” from this thread, and it confidently hallucinated a roadmap, assigned the wrong owners, and turned offhand comments into commitments. This is the kind of failure signature every AI PM must design around:

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

It looks authoritative, clean, structured. And it’s completely wrong.

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

Now that you have the obviously wrong results, you’ll need to generate the “ideal” response and compare the two responses to understand what signals the model needs to behave correctly.

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

Here’s exactly what to do:

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

1. Re-run the same Slack thread through the model

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

Use the same messy context that caused the hallucination.

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

Example (you paste the Slack thread):

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

Based on this Slack discussion, draft our Q4 roadmap.

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

Let’s say the model invents features you never discussed. Great, you’ve found a failure mode.

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

2. Now tell the model what good looks like and run it again

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

Add one short line explaining the expected behavior. For example:

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

Try again, but only include items explicitly mentioned in the thread. If something is missing, say “Not enough information.”

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

Run that prompt against the exact same Slack thread. A correct, trustworthy behavior would be:

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

This answer acknowledges the lack of clear decisions, asks clarifying questions, and surfaces useful structure without inventing facts (“key themes”). It avoids assigning owners unless explicitly stated and highlights uncertainties instead of hiding them.

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

3. Compare the two outputs—and the inputs that led to them—side by side

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

This contrast of the two outputs above—confident hallucination vs. humble clarity—is what teaches you how the model behaves today, and what you need to design toward. And that contrast is where AI product sense sharpens fastest.

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

You’re looking for:

Вы ищете:

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

4. Capture the gaps—this becomes a product requirement

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

When you see a failure mode repeat, it usually points to a specific kind of product gap (and specific kind of fix).

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

Now you know where the product fails and its intended behavior. Later in this guide, I’ll show concrete examples of what prompt and design guardrails and retrieval look like in practice, and how to decide when to add them.

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

Ritual 2: Ask a model to do something ambiguous (3 min.)

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

Goal: Understand the model’s semantic fragility

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

Ambiguity is kryptonite for probabilistic systems because if a model doesn’t fully understand the user’s intent, it fills the gaps with its best guess (i.e. hallucinations, bad ideas). That’s when user trust starts to crack. Try, for example, to input a PRD into NotebookLM and ask it to “Summarize this PRD for the VP of Product.”

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

How to try this in 2 minutes (NotebookLM):

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

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

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

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

Does it:

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

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

The model’s failures reveal where its semantic fragility is—in what ways the model technically understands your words but completely misses your intent. Other examples could be if you ask for a summary for leaders and it gives you a bullet list of emojis and jokes from the thread. Or you ask for UX problems and it confidently proposes a new pricing model.

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

What you’re learning here is where the model gets confused, which is exactly where your product should step in and do the work to reduce ambiguity. That could mean asking the user to choose a goal (“Summarize for who?”), giving the model more context, or constraining the action so the model can’t go off-track. You’re not trying to “trick” the model; you’re trying to understand where communication breaks so you can prevent misunderstanding through design.

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

Ambiguous prompts: what to test, what breaks, what to do

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

Here are a few ambiguous prompts to try, along with the different interpretations you should explicitly test:

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

Now you have another batch of design work for the AI product to help guide it toward predictable and trustworthy results.

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

Ritual 3: Ask a model to do something unexpectedly difficult (3 min.)

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

Goal: Understand the model’s first point of failure

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

Pick one task that feels simple to a human PM but stresses a model’s reasoning, context, or judgment.

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

You’re not trying to exhaustively test the model. You’re trying to see where it breaks first, so you know where the product needs organizing structure. Where it starts to go wrong is exactly where you need to design guardrails, narrow inputs, or split the task into smaller steps.

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

Note: This isn’t the final solution yet; it’s the intended behavior. In the guardrails section later, I’ll show how to turn this into an explicit rule in the product (prompt + UX + fallback behavior).

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

Example 1: “Group these 40 bugs into themes and propose a roadmap.”

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

Example 2: “Summarize this PRD and flag risks for leadership.”

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

With results from all three rituals, you now have a complete list of product design work that needs to happen to get the results you and users can use and trust.

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

Over time, this kind of work also starts to surface second-order effects—moments where a small AI feature quietly reshapes workflows, defaults, or expectations. System-level insights come later, once the foundations are solid. The first goal is to understand behavior.

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

Define a minimum viable quality (MVQ)

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

Even when you understand a model’s failure modes and have designed around them, it’s nearly impossible to entirely predict how AI features will behave once they hit the real world, but performance almost always drops once they’re out of the controlled development environment. Since you don’t know how it will drop or by how much, one of the best ways to keep the bar high from the start is to define a minimum viable quality (MVQ) and check it against your product throughout development.

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

A strong MVQ explicitly defines three thresholds:

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

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

Also important in MVQ is the product’s cost envelope: the rough range of what this feature will cost to run at scale for your users.

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

A concrete example of MVQ comes from my firsthand experience. I spent years working in speech recognition and speaker identification, a domain where the gap between lab accuracy and real-world accuracy is painfully visible.

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

I still remember demos where the model hit over 90% accuracy in controlled tests and then completely fell apart the first time we tried it in a real home. A barking dog, a running dishwasher, someone speaking from across the room, and suddenly the “great” model felt broken. And from the user’s perspective, it was broken.

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

With speaker identification for AI features coming from smart speakers, the MVQ of the ability to identify who is speaking would look like this:

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

Acceptable bar

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

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

Delight bar

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

You don’t need a perfect percentage to know that you’ve hit the right delight bar, but you look for behavioral signals like:

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

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

Rule of thumb: If 8 or 9 out of 10 attempts work without a retry in realistic conditions, it feels magical. If 1 in 5 needs a retry, trust erodes fast. MVQ also depends on the phase you’re in. In a closed beta, users often tolerate rough edges because they expect iteration. In a broad launch, the same failure modes feel broken.

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

For the speech recognition feature, here are some examples for assessing delight:

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

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

Do-not-ship bar

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

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

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

Five strategic context factors that raise or lower your MVQ bar

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

Here are the five factors that most often determine where that bar should be set, and how they change your product decision:

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

Estimating the cost envelope

Оценка cost envelope

One of the most common mistakes new AI PMs make is falling in love with a magical AI demo without checking whether it’s financially viable. That’s why it’s important to estimate the AI product or feature’s cost envelope early.

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

Cost envelope = the rough range of what this feature will cost to run at scale for your users

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

You don’t need perfect numbers, but you need a ballpark. Start with:

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

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

Example: AI meeting notes again

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

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

Now you can have a real conversation:

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

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

This is a core part of AI product sense: Does what you’re proposing actually make sense for the business?

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

Design guardrails where behavior breaks

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

Now that you better understand where a model’s behavior breaks and what you’re looking for to greenlight a launch, it’s time to codify some guardrails and design them into the product. A good guardrail determines what the product should do when the model hits its limits so that users don’t get confused, misled, or lose trust. In practice, guardrails protect users from experiencing a model’s failure modes. At a startup I’ve been collaborating with, we built an AI feature to increase the team’s productivity that summarized long Slack threads into “decisions and action items.” In testing, it worked well—until it started assigning owners for action items when no one had actually agreed to anything yet. Sometimes it even picked the wrong person.

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

Because my team had developed our AI product sense, we figured out that the fix was a new guardrail in the product, not a different underlying model.

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

So we added one simple rule to the system prompt (in this case, just a line of additional instruction):

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

Only assign an owner if someone explicitly volunteers or is directly asked and confirms. Otherwise, surface themes and ask the user what to do next.

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

That single constraint eliminated the biggest trust issue almost immediately.

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

What good guardrails look like in practice

Как хорошие guardrails выглядят на практике

This post is for paid subscribers

Этот пост — для платных подписчиков