Lesson 13: Building AI Product Sense
Push a model into its failure modes in 15 minutes a week, then set the quality bar before you ship.
if (!lesson) throw new Error("Lesson metadata missing");
Section 1: The Core Idea
AI product sense is knowing what a model can do, where it fails, and how to build something people love inside those limits. Meta now interviews for it, the first major change to its PM loop in over five years. Candidates work a product problem with AI in real time and are judged on how they handle uncertainty: noticing when the model is guessing, asking the right follow up question, and still deciding. AI features fail differently from ordinary software. A button either works or it does not. A model works most of the time, and the exceptions are invisible in a demo. Marily Nika, a longtime AI PM at Google and Meta, sees the same pattern everywhere: it works beautifully in a controlled flow, then breaks in production on a few predictable failure modes. A support agent that confidently answers "Is this good?" instead of asking what the user means quietly loses trust after launch. 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. Her answer is a 15 minute weekly habit: three small prompts that push the model into its failure modes before users do. Do each one once as you read.
Section 2: Ritual 1: Ask for something obviously wrong (2 minutes)
Find the messiest text you have (a Slack thread, raw meeting notes, Jira comments) and ask the model to extract "strategic product decisions" from it. Her example is a short thread. Alice asks whether Stripe is failing for EU users again. Ben guesses it might be the webhook. Sara asks not to rename the onboarding modal again. Alice says onboarding has to be out by Thursday. There is not one decision in there. The model returned a roadmap anyway, with owners assigned and offhand remarks turned into commitments. > KEY POINT: Faced with mess, a generative model confidently invents structure. The cleaner the output looks, the harder you should check its inputs. Now run the same thread with one extra line: only include items explicitly mentioned, and say "Not enough information" where something is missing. A trustworthy response admits there are no clear decisions, lists the themes, asks what to do next, and names no owners. Put the two outputs side by side. Which constraint fixed the hallucination? Is the fixed version shippable or still brittle? That gap is a product requirement. Write it down.
Section 3: Ritual 2: Ask for something ambiguous (3 minutes)
Drop a PRD into NotebookLM or any tool that reads documents and ask it to summarise for execs with the top five risks and open questions. The prompt is underspecified on purpose. Which execs? Risks to what? Watch for four tells: it over summarises, it latches onto one irrelevant detail, it drops the caveats, or it writes for the wrong audience. This is semantic fragility: the model understood your words and missed your intent, and being probabilistic it filled the gap with a guess rather than a question. Every place it guessed is where your product should reduce the ambiguity: ask the user who the summary is for, pass more context, or narrow what the feature may do. You are not tricking the model. You are finding where communication breaks so design can prevent it.
Section 4: Ritual 3: Ask for something unexpectedly difficult (3 minutes)
Pick a task a human PM finds easy but that stresses the model's reasoning, context, or judgement. Marily's examples: "Group these 40 bugs into themes and propose a roadmap" and "Summarise this PRD and flag risks for leadership." Forty bugs strains the model's context, and a roadmap needs judgement the list does not contain. Watch for the first crack: a bug that silently disappears, a theme no bug supports, a sequence built on invented estimates. 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. The first point of failure is where the product needs structure: a guardrail, a narrower input, or the task split into smaller steps. What you write down is intended behaviour, not the final design.
Section 5: Minimum Viable Quality and guardrails
Performance drops when a feature leaves the controlled environment, and you cannot predict by how much. So define a minimum viable quality (MVQ) up front and check against it as you build. Marily's example is speaker identification on a smart speaker. It passed 90% accuracy in the lab and fell apart in a real home with a barking dog and a running dishwasher. Acceptable bar: identifies the speaker x% of the time in typical home conditions, and when unsure asks whether to use your profile or continue as a guest. Delight bar: behavioural signals, not a number. People stop repeating themselves and "No, I meant..." corrections drop sharply. Do-not-ship bar: misidentifies the speaker more than y% of the time in critical flows like purchases and messages. The x and y stay blank because thresholds depend on context: a closed beta forgives what a broad launch calls broken. MVQ also needs a cost envelope, a ballpark of the running cost at scale: cost per call, calls per user per month, the heaviest user, and whether the maths holds at ten times the usage. AI meeting notes at roughly $0.30 per user per month that drive retention are a no brainer. At $5 with unclear impact, a business problem. Finally, turn each failure into a guardrail. A startup Marily worked with shipped a Slack summariser that began assigning action item owners to people who had never agreed to anything. The fix was one line in the system prompt, not a different model: 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 removed the biggest trust issue almost immediately. 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. Source: Marily Nika, "Building AI product sense, part 2", Lenny's Newsletter (Feb 2026). **Apply It:** Set a 15 minute timer and run the three rituals on any AI tool you already use (Claude, ChatGPT, NotebookLM, your notes app's assistant). Paste a messy chat thread and ask for the strategic decisions in it. Paste a document and ask for a summary "for leadership" with no other context. Give it a long list (bugs, feedback, tasks) and ask for themes plus a plan. Write down one failure mode you saw and one guardrail that would have prevented it. One sentence each. buildContent= );