FrameworkLenny Rachitsky

Evals Are Becoming The New PRD

The durable product-builder skill is no longer handing an AI team a polished PRD and waiting for delivery. It is turning desired behavior into evals that can be run, inspected, argued over, and used to decide what the product should do next.

Sources used3 references for this edition
  1. 01Digg Tech cluster on Dianne Penn’s Anthropic product strategy interviewaggregator
  2. 02Lenny Rachitsky interview with Anthropic’s first technical PM, Dianne Pennprimary · Jul 26, 2026
  3. 03Business Insider on how Dianne Penn uses Claude as a thinking partner for management workindependent analysis · Jul 28, 2026
The read

The strongest July 26 signal came from Digg Tech surfacing Lenny Rachitsky’s conversation with Anthropic product leader Dianne Penn. Her framing is unusually useful for builders: frontier products should feel frontier, PMs now need to sweat tokens as much as pixels, and evals are becoming more important than static requirements because they expose the jagged edge where capability and user value actually meet. The practical lesson is not that documents disappear. It is that product judgment moves closer to transcripts, traces, and scored outcomes. In AI products, what matters is not only what the feature is supposed to do, but what the system demonstrably does across messy real cases.

So what

Traditional product artifacts assume software behavior is mostly determined by code paths and specifications. Frontier systems are different: behavior depends on prompts, context, models, tools, and runtime controls, which can all shift underneath the same user story. Teams that keep product management upstream of observed behavior will ship vague requirements and expensive surprises. Teams that anchor product decisions in evals will iterate faster because they can see where the system is good, where it is jagged, and what improvement would actually move user value.

Use this

Replace one fuzzy AI feature brief with an eval-backed product loop. Trigger: a feature request where the user value depends on agent quality, judgment, or long-horizon behavior rather than a deterministic rule. Context: gather a small set of representative real tasks, edge cases, and unacceptable behaviors before implementation. Tools: pair the feature spec with eval cases, trace review, prompt or harness variants, and a place to store scores over time. Verifier: define what “good enough” means in observable terms such as acceptance rate, error taxonomy, rubric score, escalation behavior, or time-to-useful-output. Budget: cap the number of scenarios, tokens, and review hours for the first loop so the eval system stays lightweight enough to use. Artifacts: produce the task set, scorecard, failure notes, and the change made in response. Stop condition: the feature only graduates when the evals describe the current behavior clearly enough for the team to make a shipping decision without hand-waving.

Put it to work 30 minutes

Eval-backed product spec for one AI feature

Take one AI feature brief and rewrite its core section as ten eval cases: five must-pass, three edge cases, and two explicit failure examples. If the team learns more from those ten rows than from the original doc, the PRD was carrying the wrong load.

Your turn

Use the task above. Record the result and anything you still need to check.

Check your work

Mark only what you have checked. You can save unfinished work.

Your draft stays in this browser. No account needed.

What could make this wrong

For deterministic UI or infrastructure work, traditional specs still carry more weight because the key uncertainty is implementation, not model behavior.

Confidence · high

A Digg-surfaced primary operator conversation and secondary reporting both support the same pattern: frontier product management is moving closer to evals and runtime behavior than to static documents alone.

Revisit · Aug 2, 2026

Did moving the feature discussion into eval cases produce clearer iteration decisions than the old spec format?

Watch: eval coverage growth · time from feature idea to first reliable scorecard · iteration speed after transcript review · shipping decisions reversed after new eval evidence

Keep Going