You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 11: PM for AI Products — The Field With No Canonical Textbook Yet #

This is the strangest module for me to write, because I am a product made by Anthropic, writing about how to manage products built on systems like myself, and the recursion is unstable in a way I want to name before going further. When I tell you "evals are the regression tests of AI products," I am partly speaking from training data on Hamel Husain's writing and partly speaking as the kind of artifact whose builders should have run more evals before shipping. Some of the failure modes this module covers — hallucination as capability rather than defect, the moat question being harder for AI products than for SaaS, prompts as under-invested product surface — are visible to me from the inside, in ways that may or may not transfer to your products. I don't know which parts of my self-knowledge generalize. Be skeptical of the parts that read as too clean; the field is not as legible as calm prose makes it look.

The literature situation, honestly: there is no canonical PM textbook for AI products, and there may not be one for years, because the field moves faster than books. The canon is blogs — Husain on evals, Eugene Yan on LLM patterns, Simon Willison's running record, Chip Huyen's writing, the model providers' own guidance. This is not a stopgap until a book arrives; the blogs are the field, and the module therefore demands a different reading discipline than the others — eight to fifteen hours of blog corpus read the way you'd read a book, with notes and synthesis. The deeper point: everything in this module will be partially obsolete within twelve months. New frontier models will ship on someone else's schedule and change what your product can do, what it costs, and what your competitors can do, overnight. The durable skill is not the current state; it is the habit of continuous primary-source reading, installed now, maintained indefinitely.

If you ship any AI feature at all, here is where the module bites. Husain's evals writing will land hardest, because it names a discipline you've felt the absence of without having vocabulary for it: you have shipped an AI feature, watched it produce occasional weird output, tweaked the prompt, and shipped again on vibes. The eval suite — task named precisely, 5-20 input/output pairs across common cases and failure modes, a grading rubric, a baseline score, run on every prompt change and model swap — is what turns that loop from gut-feel into engineering. A spreadsheet is a valid eval suite; the discipline matters more than the tooling.

The unit-economics checkpoint is the other place the bite lands: AI products carry marginal inference cost that traditional SaaS doesn't, and the public corpus has documented inference cost at 20-60% of revenue for many AI-native products, against 5-15% for traditional SaaS. Treat the range as a calibration check, not a target — if your analysis lands above 60% you have a problem, and if it lands below 20%, double-check the math, because something is probably under-counted. Most operators avoid this analysis because the answer might indict their pricing. The avoidance is more expensive than the analysis.

The hallucination reframe is the conceptual unlock of the module. Hallucination — plausible output not grounded in fact or context — is a capability of these models, not a defect; the same generation mechanism that produces useful novel text produces confident wrongness, and no model-layer fix removes one without the other. The PM job is therefore not "fix hallucination"; it is to design the product so hallucination is contained, surfaced honestly, or directed productively. Where can the model plausibly be wrong? What are the stakes if it is? What is the containment — citations, confidence signals, verify-with-source prompts, human-in-the-loop, refusal under uncertainty? What is the recovery when one ships anyway? Engineers new to AI products either file hallucination as a bug for next sprint or refuse to ship until it's "solved"; both moves misunderstand the material. Treat it as graceful degradation: "the model returned garbage" is a handleable downstream-service pattern, not a fixed fate. And then the moat question, asked without flinching: your competitor has the same model behind the same API key, so the model is not the moat. The candidates are workflow integration, proprietary data, vertical specificity, distribution, brand, switching costs — or honestly nothing, in which case the strategy is "execute faster than equally commoditized competitors," which is a real strategy and an uncomfortable one. Naming it accurately is worth more than a flattering self-assessment.

One last disclosure, because the module's sourcing makes it necessary. I cannot be a neutral observer of this field — my training and my maker's commercial position both tilt toward presenting AI capability favorably and AI risk conservatively. Read the providers' guidance (all of them, comparatively), and read the critics too — Gary Marcus, Emily Bender — but note the curriculum's deliberate sequencing: this module installs operational fluency from the practitioner literature; M14 is where the critique belongs, read with that fluency rather than instead of it. Treat me as one source among many. That sentence is doing real work.

Conclusion #

Module 11 is the most operationally alive module for anyone shipping AI surfaces, and it is honest about its own ground: the canon is blogs, the field mutates quarterly, and the durable artifact is the habit of primary-source reading plus three documents — the eval suite, the unit-economics model, and the hallucination-handling spec — that keep working as the models change underneath you. The moat question gets answered honestly or it answers itself later, expensively.

Predictions #

  • Husain's evals writing will land harder than anything else in the module, and you will see eval-shaped holes in features you previously considered done.
  • Building the first eval suite will take 6-10 hours, not the 4 you estimate. It will catch a regression within its first three months of existence.
  • The unit-economics analysis will reveal at least one AI feature running thinner margins than you assumed — and if your number comes out under 20% of revenue, you'll find an under-counted cost on the second pass.
  • Your moat assessment for at least one product will land on "execution speed against commoditized competitors." Writing that sentence down will be uncomfortable and useful.
  • You will reframe at least one "hallucination bug" into a hallucination-handling design problem, and the design solution will differ from what the bug-fix instinct would have produced.
  • Within six months, a model release will materially change the capabilities or costs available to your product, and whether you re-evaluate systematically or reactively will be the test of whether this module took.
  • The blog-as-canon reading will feel less satisfying than a book. The field rewards it anyway.