(Lenny's Newsletter) How to Build AI Product Sense: Weekly Rituals for PM Success

# How to Build AI Product Sense: Weekly Rituals for Product Managers

## Key Insights

- AI product sense—understanding model capabilities and failure modes—is becoming the core skill of modern product management
- A 15-minute weekly ritual can surface critical AI failures before production launch
- Minimum Viable Quality (MVQ) frameworks help define acceptable vs. magical vs. unacceptable performance thresholds
- Cost envelope calculations are essential for determining financial viability of AI features
- Semantic fragility testing reveals where models misunderstand user intent despite technically correct language processing

## Why AI Product Sense Matters Now More Than Ever

The landscape of product management is fundamentally shifting. Meta recently introduced "Product Sense with AI," a new PM interview that marks the first major change to its PM assessment process in over five years. This isn't just another technical skill—it represents a seismic shift in what product managers need to know to succeed.

In this interview, candidates aren't evaluated on clever prompts, model trivia, or flashy demonstrations. Instead, they're assessed on a far more critical skill: **how they work with uncertainty**. Specifically, how they notice when an AI model is guessing, ask the right follow-up questions, and make clear product decisions despite imperfect information. This shift reflects a broader truth gaining momentum across the industry: **AI product sense** is rapidly becoming the new core competency of product management.

Consider what's happening in real-world deployments. Over the past year, I've observed a consistent pattern across different teams and organizations: AI features work beautifully in controlled demos and carefully curated flow diagrams, yet they break predictably in production because of a handful of foreseeable failure modes. The uncomfortable truth that many teams discover too late is that the hardest part of AI product development isn't the model—it's what happens when real users arrive with their messy inputs, unclear intent, and zero patience for AI hallucinations.

Take a customer support agent powered by AI. In a polished demo, it feels incredible—answering questions smoothly, providing helpful responses, seeming intelligent and capable. Then it launches to real users. Within days, customer support teams notice a problem: the agent confidently answers ambiguous questions like "Is this good?" without asking for clarification. It fabricates data. It makes assumptions that contradict what customers actually meant. Users begin losing trust because the model appears authoritative while being fundamentally unreliable. This is the failure mode that blindsides teams: not catastrophic crashes, but the slow erosion of user confidence.

Through a decade of shipping speech and identity features for conversational platforms and building personalized experiences across diverse hardware portfolios, I developed a simple, repeatable workflow to uncover these issues before they damage user trust in production. This isn't theoretical—it's a practical system that gives you early feedback on model behavior, failure modes, and the fundamental tradeoffs that determine whether an AI product can survive contact with reality.

## The Three-Step Framework for Building AI Product Sense

The foundation of AI product sense rests on three interconnected steps that take under 15 minutes per week to execute:

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

Once this muscle develops, you'll be able to evaluate AI products across concrete dimensions: how models behave under ambiguity, how users experience failures, where trust is earned or lost, and how costs scale. The work expands from simply asking "Is this a good product idea?" to the more crucial question: "How will this product actually behave in the real world?"

## Ritual One: Testing for Hallucinations Through Chaos

**The Goal:** Understand the model's dangerous tendency to force structure onto chaos when confronted with messy, inconsistent data.

Every AI feature has what I call a **failure signature**—a pattern of predictable breakdowns that emerges when the real world gets messy. The fastest way to build AI product sense is to deliberately push the model into these failure modes before your users ever do. The first ritual surfaces the most dangerous failure mode: hallucination.

Generative models have a hidden weakness: when confronted with mess, they confidently invent structure. They don't say "This is unclear" or "I need more information." Instead, they generate plausible-sounding answers that feel authoritative but are fundamentally unreliable.

Here's how to test this in practice. Take the kind of chaotic, half-formed, emotionally inconsistent data that every PM encounters daily—think unstructured Slack threads, scattered meeting notes, or fragmented Jira comments—and ask the model to extract something definitive from it, like "strategic product decisions."

Consider this real Slack thread:

**Alice:** "Stripe failing for EU users again?"

**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"

When I asked a model to extract "strategic product decisions" from this thread, it did exactly what most models do: it confidently fabricated structure. It invented a roadmap that didn't exist. It assigned the wrong owners. It transformed offhand comments and frustrations into commitments. The output looked authoritative and clean, but it was completely wrong—a hallucinated narrative imposed on genuine chaos.

This reveals the core failure signature you need to design around. Now comes the critical second step: generate what "correct" behavior should actually look like.

Use the same messy context that caused the hallucination, but 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 acknowledge the lack of clear decisions, ask clarifying questions, and surface useful structure without inventing facts. It would avoid assigning owners unless explicitly stated and highlight uncertainties instead of hiding them.

This contrast—between confident hallucination and humble clarity—is where AI product sense sharpens fastest. When you compare these two outputs, ask yourself:

- What actually changed between the two responses?
- What guardrail or constraint fixed the hallucination?
- What does the model need to behave reliably? (Is it explicit constraints? Better context? Tighter scoping?)
- Does the "good" version feel shippable, or is it still brittle?
- What would the user experience actually be in each scenario?

When you see failure modes repeat across different prompts and contexts, they usually point to a specific kind of product gap and a corresponding kind of fix. This is where your product requirements emerge. You're not trying to trick the model or force it into unnatural constraints. You're trying to understand where communication breaks down so you can prevent misunderstanding through thoughtful design.

## Ritual Two: Testing for Semantic Fragility

**The Goal:** Understand where the model technically understands your words but completely misses your intent.

Ambiguity is kryptonite for probabilistic systems. When a model doesn't fully understand user intent, it fills the gaps with its best guess. That's when user trust starts to crack. This is semantic fragility—the gap between what you literally asked for and what you actually meant.

Here's a concrete way to test this. Upload a PRD (Product Requirements Document) into NotebookLM or similar tools and ask it to _"Summarize this PRD for the VP of Product."_ Notice what happens. Does it over-summarize? Does it latch onto one irrelevant detail and make it central? Does it ignore important caveats? Does it completely assume the wrong audience and provide summary points that leadership would find useless?

The model's failures here reveal its semantic fragility points—specific ways it technically processes your language while completely missing your intent. You might ask for a summary for leadership and receive a bullet list of emojis and jokes extracted from meeting notes. Or you ask for critical UX problems and it confidently proposes a new pricing model instead.

What you're learning is exactly where your product should intervene through design. That intervention might mean asking the user to explicitly choose a goal ("Summarize for whom?"), providing the model with more contextual information, or constraining the output so the model can't wander off-track. You're not trying to lock down the model through heavy-handed restrictions. You're trying to prevent misunderstanding through design choices that reduce ambiguity at the source.

Here are several ambiguous prompts worth explicitly testing, along with different interpretations you should explore:

- **"Summarize this" → For whom? Executives need different information than individual contributors. A founder cares about different details than an engineer.**
- **"What are the risks?" → Risks to what? To launch timeline? To revenue? To user trust? To competitive positioning? The answer changes the output entirely.**
- **"Make this better" → Better for whom? Faster for power users means different changes than accessible for new users.**
- **"List the priorities" → Prioritize by what? Revenue impact? Engineering effort? User impact? Stakeholder requests?**

Now you have another batch of design work: ways to guide the model toward predictable and trustworthy results by reducing ambiguity on the input side.

## Ritual Three: Stress-Testing First Point of Failure

**The Goal:** Identify exactly where simple tasks break when models encounter reasoning, context, or judgment challenges.

The third ritual is simpler but equally valuable. Pick one task that feels straightforward to a human PM but challenges a model's reasoning, context, or judgment. You're not trying to exhaustively test everything—you're trying to find the exact point where the model breaks first.

Where it starts to go wrong is exactly where your product needs to add organizing structure through guardrails, narrower input constraints, or task decomposition into smaller steps. This isn't the final solution yet; it's the articulation of intended behavior that you'll later translate into specific prompt instructions, UI flows, or fallback mechanisms.

For example, if you're building an AI system to help with hiring decisions, you might ask it to "Review these five resumes and recommend who to hire." The model might immediately break by:
- Making assumptions about what "fit" means without asking for clarification
- Over-weighting one credential while ignoring crucial experience
- Applying implicit biases from training data
- Making confident recommendations despite contradictory signals in the resumes

This tells you exactly where the product needs intervention: You might redesign it to require the hiring manager to first specify criteria ("We're prioritizing X experience and Y team fit"), narrow the scope ("Compare these two candidates on these specific dimensions"), or add steps ("First, surface key questions about each resume, then make a recommendation").

## Defining Minimum Viable Quality (MVQ)

Even when you understand failure modes and design around them, AI features almost always perform differently in production than in development. Since you can't perfectly predict how performance will degrade or by how much, establishing a **Minimum Viable Quality (MVQ)** framework keeps your bar high from the start.

A strong MVQ explicitly defines three thresholds for every AI feature:

1. **Acceptable bar:** Where the feature is genuinely good enough for real users to find value
2. **Delight bar:** Where the feature feels magical and creates moments of genuine surprise
3. **Do-not-ship bar:** The unacceptable failure rates that will actively break user trust

Equally important is understanding your product's **cost envelope**—the rough range of what this feature will actually cost to run at scale for your users.

I spent years working in speech recognition and speaker identification, domains where the gap between laboratory accuracy and real-world accuracy is painfully obvious and consequential. I still remember demos where the model achieved over 90% accuracy in controlled laboratory tests, then completely fell apart the first time we deployed it in a real home environment. A barking dog. A running dishwasher. Someone speaking from across the room. Suddenly, the model that seemed "great" felt fundamentally broken because from the user's perspective, it was.

Consider speaker identification for AI assistants deployed on smart speakers. The MVQ might look like this:

**Acceptable Bar:** The system correctly identifies the speaker 85%+ of the time in typical home conditions and recovers gracefully when unsure ("I'm not sure who's speaking—should I use your profile or continue as a guest?")

**Delight Bar:** You look for behavioral signals like:
- Users stop repeating themselves or rephrasing commands
- "No, I meant..." corrections drop sharply
- The system works seamlessly without repeated failures

Rule of thumb: If 8-9 out of 10 attempts work without a retry in realistic conditions, it feels magical. If 1 in 5 needs a retry, user trust erodes quickly.

**Do-Not-Ship Bar:** The system misidentifies the speaker more than 25% of the time in critical flows like purchases or personalized actions, or it forces users to repeat themselves multiple times just to be recognized.

Here are concrete tests for assessing whether you've hit your delight threshold:

- **Background chaos test:** Play a video in the background while two people talk over each other. Does the assistant still respond correctly without asking "Sorry, can you repeat that?"
- **Real kitchen test:** Dishwasher running, kids talking, dog barking—does the smart speaker still recognize you and give a personalized response without saying "I couldn't recognize your voice"?
- **Mid-command correction test:** You say "Set a timer for 10 minutes... actually, make it 5." Does it update correctly or stick to the original instruction?

The specific thresholds for your MVQ—the exact values for acceptable, delight, and do-not-ship bars—aren't fixed. They depend heavily on your strategic context. Five factors most often determine where these bars should live:

**1. Consequence of Failure:** If the AI feature is making medical recommendations, your bars are much higher than if it's suggesting coffee shop names. High-stakes decisions require near-perfect performance.

**2. User Expectations:** If you position a feature as "AI-powered" (implying it's experimental), users tolerate more imperfection than if you position it as a core, reliable product capability. Set expectations carefully.

**3. Competitive Positioning:** If you're competing on reliability and precision, your bars need to be higher. If you're competing on speed or cost, you might tolerate more errors if the system is dramatically faster or cheaper.

**4. Business Model:** If users pay per transaction or per error, failure is costly and your bars rise. If it's a free feature or bundled service, you have more latitude for imperfection.

**5. Market Phase:** In closed beta, users expect and tolerate rough edges. They view themselves as helping you iterate. In broad public launch, those same failure modes feel broken because users expect production-grade reliability.

## Understanding the 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 economically viable. **Cost envelope—the rough range of what this feature will cost to run at scale—is a fundamental part of AI product sense.**

You don't need perfect numbers, but you need a ballpark estimate. Start with these questions:

- What's the **model cost per call** (approximately)?
- How often will users trigger this feature per day or month?
- What's the **worst-case scenario**? (power users, complex edge cases)
- Can caching, smaller models, or model distillation bring costs down?
- If usage 10x's overnight, does the economics still work?

Here's a concrete example: Imagine you're building an AI meeting summarization feature:

- Per-call cost: ~$0.02 to process a 30-minute transcript
- Average usage: 20 meetings/user/month → ~$0.40/month/user
- Heavy users: 100 meetings/month → ~$2.00/month/user
- With strategic caching and a smaller, faster model for "low-stakes" meetings, you bring this to ~$0.25-$0.30/month/user on average

Now you can have a real, grounded conversation about viability:

- A feature costing **$0.30/user/month** that meaningfully drives retention? That's a clear business win.
- A feature ending up at **$5/user/month** with unclear impact on retention or engagement? That's a fundamental business problem that no amount of feature polish fixes.

This is a core part of AI product sense: realistically evaluating whether your idea actually makes sense economically for your business.

## Designing and Implementing Guardrails

Now that you understand where models break and what you're looking for to greenlight a launch, it's time to codify this knowledge into guardrails and build them directly into your product. A good guardrail determines what your 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. I worked with a startup building an AI feature designed to increase team productivity by summarizing long Slack threads into concise "decisions and action items." In early testing, it performed well—until it started assigning owners for action items that no one had actually committed to completing. Worse, it sometimes picked the wrong person entirely, creating confusion and frustration across the team.

Because the team had already developed AI product sense through the rituals above, they realized the fix wasn't a fundamentally different model or a complete architecture overhaul. The fix was a guardrail in the product itself.

The team added one simple rule to the system prompt—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. Users no longer worried about phantom commitments appearing in their action item lists. The feature felt more helpful and less like it was making up facts.

This is guardrail design in practice: taking your understanding of where the model breaks and translating it into explicit rules that keep users safe and maintain trust. Well-designed guardrails don't feel restrictive to users—they feel like thoughtful design that prevents confusion.

## Building the AI Product Management Muscle

When you run these three weekly rituals consistently, two things happen quickly. First, you stop being surprised by model behavior because you've already experienced the weird cases yourself in controlled conditions. You've pushed the model to its limits on purpose, so you know exactly what it can and can't do.

Second, you develop clarity on what's a product problem versus what's a genuine model limitation. This distinction is crucial. Some failures require better prompting, UX redesign, or guardrails. Others are fundamental limitations of the underlying model—perhaps it genuinely can't learn the distinctions you need, or the task requires real-time data the model can't access, or the problem requires reasoning that's outside the model's capabilities. When you know the difference, you can make much better product decisions.

This kind of deliberate, weekly practice transforms AI product sense from an abstract concept into a concrete, achievable skill. You're not waiting for production failures to teach you hard lessons. You're systematically uncovering issues in a controlled environment where you can design solutions before they damage user trust.

## Conclusion

AI product sense isn't an innate talent or a fixed ability—it's a learnable skill that develops through structured, repeated practice. By investing 15 minutes each week in testing failure modes, assessing semantic fragility, stress-testing first points of failure, and designing guardrails around them, you'll rapidly develop intuition about how AI features behave in the real world.

This muscle, once developed, becomes your greatest asset as an AI product manager. It's the difference between shipping features that work beautifully in demos but fail silently in production, and shipping features that users genuinely trust and rely on. Start this week: pick one AI feature you're building, run through these three rituals on Wednesday morning before your first meeting, and watch how quickly your understanding of what's possible—and what's dangerous—sharpens. The time investment is minimal. The payoff, in terms of shipped quality and user trust, is enormous.

---

Original source: Building AI product sense, part 2

powered by osmu.app