You probably think you’re doing AI product management. You talk to users, you write lengthy Product Requirement Documents (PRDs), you align the engineering and design teams, and you ship features.
But according to the people building the most advanced AI on the planet, you’re living in the past. And if you aren’t personally writing evaluation cases and digging into every single token, you aren’t actually building a product. You’re just pretending.
This isn’t an insult. It’s a reality check from Dianne Penn, the Head of Product for AI Research and Labs at Anthropic. She was the company’s first technical product manager, joining when the entire API business was run by a single engineer. She has shipped everything from Claude 2 to the breakthrough Opus 4.5. And she says the traditional PM playbook is fundamentally broken in the age of artificial intelligence.
The eval is the new PRD. If you aren’t translating vague user complaints into reproducible test cases, you aren’t building an AI product—you’re just taking notes around it.
Here is the problem: AI models don’t improve linearly. They don’t patiently wait for your quarterly roadmap. Capabilities emerge in sudden, unpredictable jumps. A model might be completely incapable of calculating a simple math problem on Tuesday, and by Friday, after a slight training tweak, it can reliably execute complex, multi-step coding agents.
You cannot schedule a release date for a brain that suddenly learns to think. You have to constantly evaluate it, discover its hidden capabilities, and build the product experiences that can unlock them. If you don’t have a rigorous evaluation system, those emergent capabilities will happen right under your nose, and you won’t even know it.
This completely changes what a product manager actually does. In the old SaaS world, a PM would interview a user, figure out a pain point, and write a PRD detailing the solution.
In the AI world, that process is dead on arrival.
When users complained that early Claude models were “bad at following instructions,” an old-school PM would have written a PRD demanding the model be “better at following instructions.” But that is completely useless to an AI researcher. It’s too abstract.
Instead, the Anthropic product team dug into the actual conversation logs. They read the tokens. They discovered that 80% of the time, when users said “bad at following instructions,” they actually meant Claude was failing to output correct JSON format.
A user’s complaint is almost never the real problem. “It hallucinated” is just a lazy way of saying your model failed to call the right tool or read the right document.
Once you identify the real problem, you don’t write a PRD. You write an eval. You generate 30 to 40 specific cases where the model failed to output JSON correctly. You pair them with the expected golden answers. You hand this eval to the research team. Now, the researchers have a concrete, measurable target to improve. And more importantly, you have a way to verify if the next version of the model actually fixed the problem.
This is test-driven development for product management. The eval defines the goal. The eval defines the success criteria.
Does this mean the PRD is completely dead? Not exactly. PRDs are still useful for aligning legal, safety, and engineering teams on a broad, ambiguous vision. But when it comes to the actual atomic unit of improving the model, the eval has completely replaced it.
And here is the hard truth: you cannot outsource this. You cannot delegate it to a junior engineer.
If you are a senior product leader, you have to get your hands dirty. You have to read the conversation traces. You have to look at the exact tokens the model generated. You have to experience the failures firsthand. If you have never built an AI product end-to-end yourself, you have no baseline for what a good AI experience actually looks like.
You cannot pilot a rocket by reading the altitude gauge from a safe distance. You have to sit in the cockpit and feel the G-force.
This requires a massive shift in ego. The traditional PM wants to be the visionary with the beautiful slide deck. The AI PM needs to be a forensic analyst, dissecting failed prompts and token probabilities.
But this forensic work is what creates the future. When you deeply understand what the model can do today, you can start predicting what it will do tomorrow. You have to ask yourself: if Claude 8.0 comes out tomorrow and becomes perfectly reliable, how does that change user behavior? Is the product I am building today forward-compatible with that reality?
Most people are building for the limitations of today’s models. The best product managers are building the infrastructure that will catch the capabilities of tomorrow’s models when they suddenly drop.
As AI makes building software exponentially easier, the ability to just write code or write documents becomes commoditized. The real scarcity shifts. What becomes valuable is the judgment to know what is worth building, the domain expertise to know if the output is actually good, and the independence of thought to challenge the AI when it tries to agree with you.
When the cost of building approaches zero, the only scarce resource is the judgment of what is worth building. And judgment comes from getting your hands dirty in the tokens.
If you are an AI product manager, stop polishing your PRDs. Stop pretending you understand the model just because you read the release notes. Go look at the logs. Write an eval. Find the exact token where the intelligence broke down. That is the only way you are going to survive the next ten years.
FAQ
Q: Do evals completely replace PRDs in AI product management?
A: No, but their roles have shifted. When the problem is highly technical and clear, evals act as the direct target for research teams. PRDs are still necessary for aligning cross-functional teams like legal, safety, and engineering on broader, more ambiguous product visions.
Q: How should a non-technical product manager handle writing evals?
A: They can't. In the AI era, product management requires getting hands dirty. PMs must read conversation logs, analyze failed tokens, and understand the exact mechanics of model failures. If you don't understand the technical reality, you cannot define the eval.
Q: If AI models improve unpredictably, how can PMs plan roadmaps?
A: They shouldn't plan rigid roadmaps. Instead, they must build forward-compatible products. PMs need to ask if their current product design will still make sense when a massively more capable model (like a hypothetical Claude 8.0) drops unexpectedly. Agility and constant evaluation beat rigid planning.