AI for Product Builders

The first decision is not which model — it is whether the problem needs a model at all. Most teams reach for AI when they should reach for a SQL query, a checklist, or a one-line rule. Sharpen that judgment before you commit a quarter.

1. 1When AI Is the Right Answer (and When It Isn't)manual13 min readChapter 1 of the AI Manual. The opinionated screen — use AI for unstructured problems, code for structured ones — and the cost of getting that call wrong. Read this before anyone in the room types "AI" into the roadmap.
2. 2Notion AI — Adding Intelligence Without Breaking Trustcase7 min readHow Notion introduced AI writing assistance into a product where people store their most important thinking. Opt-in design, onboarding, recovery from bad outputs — the canonical "we earned the right to add AI here" case.
3. 3Klarna — When AI Customer Support Was Half-Rightcase17 min readPending authoring — Klarna's customer-service AI deflection. A case where AI was the right answer in narrow scope and an over-claim at company-wide scale. Watch how the framing shifted under scrutiny.optional

The model-selection ladder is not "biggest wins" — it is "smallest model that clears the bar." The cost gap between rungs is 10× to 100×, and a default-to-frontier habit will quietly kill your unit economics.

1. 1The Model-Selection Laddermanual12 min readChapter 2. Start at the bottom of the ladder, climb only on evidence, and treat every climb as a budget decision the CFO will eventually audit. The single most under-priced PM skill in 2026.
2. 2The 2026 Model Landscapemanual13 min readChapter 12. The opinionated atlas of where the frontier sits today — what each lab is good at, where the open-source line is, and what is likely to be commodity in 18 months. Pair it with Chapter 2 when you size a build.
3. 3Cursor — The AI Code Editor That Competed with GitHubcase6 min readCursor's bet — wrap a frontier model in a defensible coding UX rather than train one. A live worked example of the model-selection ladder in product form.

A prompt is a spec, not a wish. And no AI feature ships without a golden set — if you cannot measure whether it is right, you can only hope. These two chapters are the engineering discipline most PMs abdicate, and most teams pay for in production.

1. 1Prompt Design as Product Designmanual12 min readChapter 3. Review a teammate's prompt the way you review their copy — line by line, asking what each sentence is buying you. The PRD discipline applied to the layer that actually drives output.
2. 2Eval Before Launchmanual15 min readChapter 4. The small, sharp eval set you build before any AI feature touches a real user — and run as a regression suite on every prompt and index change after. Shipping without evals is the AI-era equivalent of shipping without tests.
3. 3Harvey — Vertical AI for a High-Stakes Professioncase8 min readVertical AI in a high-accountability domain. The product decisions underneath buyer trust — eval design, auditability, and how a narrow fine-tuned model became the moat over a general API.

Hallucination is a permanent property of how language models work, not a bug the next release fixes. Your job is to design around it — with grounding, citations, abstention, confidence cues, and UX patterns that turn a probabilistic system into something users trust.

1. 1Hallucination as a Product Problemmanual15 min readChapter 5. Turn hallucination from an engineering surprise into a product constraint you spec for. The lab will not save you; the UI will.
2. 2AI UX Patterns That Workmanual13 min readChapter 8. The pattern library with opinions — streaming, citations panels, confidence pills, regenerate, undo. What to copy, what to skip, and what to invent only when the problem is genuinely new.
3. 3Air Canada — The Chatbot That Made a Promise the Airline Had to Keepcase15 min readPending authoring — the canonical "the chatbot promised something the company didn't" case. Hallucination as legal liability, not just a UX glitch. Use it to ground every conversation about confidence UI and topic guards.optional

The big architecture forks — single-prompt vs. tool use vs. multi-step agent, and context window vs. RAG vs. fine-tune. The wrong choice here costs months, not days. Walk the ladder; do not skip rungs.

1. 1Tool Use, Function Calling, Agents — The Maturity Laddermanual12 min readChapter 6. The maturity ladder from single prompt to function calling to multi-step agents. Each rung adds value and adds blast radius — and most teams skip rungs and pay for it in production.
2. 2RAG, Fine-Tune, or Context Window?manual16 min readChapter 7. The decision tree for giving a model your data — start with context window if it fits, move to RAG when it doesn't, fine-tune only when prompts and retrieval are both exhausted.
3. 3Anthropic — Research Lab to Product Companycase7 min readBuilding the consumer product around a foundation model your own team also trains. Tool use, fallback, and trust instrumented at the agent layer — the PM decisions when model and product live under one roof.

Inference is not free, three-second responses churn users, and the regulator will eventually call. Cost-per-user-per-month, p95 latency, and the safety controls are dashboard numbers, not afterthoughts.

1. 1Cost & Latency as First-Class Product Constraintsmanual13 min readChapter 9. Treat cost-per-inference and p95 latency the way the SaaS manual treats CAC and conversion rate — as numbers you put on the dashboard and answer for in every review. If you cannot recite them, you have a science fair project, not a product.
2. 2Safety, Privacy, Compliance for Shipping Teamsmanual15 min readChapter 10. The shortest practical path through GDPR, DPDP, HIPAA-adjacent risk, content filters, PII scrubbing, audit logs, and human approval gates. The controls that keep a shipping team out of the news.
3. 3GitHub Copilot — The First Real AI Product, and What Five Years Taught Uscase14 min readPending authoring — Copilot's slow climb from "neat demo" to "default toolchain." The cost, latency, and trust decisions that made adoption durable rather than a churn spike.optional

Building with AI and building an AI product are different bets with different cost structures, hiring plans, and moats. The strategy decision sits above every other choice in this path — and most teams get it backwards.

1. 1Building With AI vs. Building AI Productsmanual12 min readChapter 11. Separate the productivity choice from the business choice. Stop accidentally hiring an ML team to do work an API would have done — and stop wrapping an API when the moat demands you go deeper.
2. 2The 2026 Model Landscapemanual13 min readChapter 12, revisited as a strategy lens. The shorter half-life chapter, used here to read the board before committing to a build.
3. 3Perplexity — Search Rewritten as Conversationcase6 min readReplacing a link-list with a generated answer. Trust, citation, hallucination handling, and the monetisation problem — the product strategy underneath the demo most people only see the front of.
4. 4Linear — AI as a Quiet Utility, Not a Chat Assistantcase14 min readPending authoring — Linear's measured, late, opinionated AI rollout into a power-user workflow tool. A counter-example to "ship AI everywhere now" — the strategy of choosing where AI does not belong.optional

The path completes when you have made the build/buy call, picked the model, written the prompt, built the eval set, sketched the UX for uncertainty, and put a cost-per-user number on the page. The two courses below are the structured drill version of that capstone; until they ship, walk it through the Manual chapters.

1. 1Course 1: Model Selection and EvalscourseComing soon — the structured drill for Stages 2 and 3. In the interim, work through AI Manual chapters 2, 4, and 12 with a real feature spec in front of you.optional
2. 2Course 2: Prompt as SpeccourseComing soon — the structured drill for Stage 3. In the interim, treat AI Manual chapter 3 as the course and review three of your own prompts against it line by line.optional