There seems to be a growing perception that evals are a novel concept in the product manager’s toolkit. I get why people feel that way, but I don’t think it’s quite right.
I’m not arguing against evals. I’m trying to work through a distinction that keeps bothering me, which is that evals are new as a mechanism, while the principle underneath feels similar to how product teams already work. They are one more way to turn “good” into shared understanding.
This came up for me during a panel conversation about building AI products, where the room seemed to treat evals as the key thing for serious AI product teams to do, like the dividing line between people who ‘get’ AI and people who don’t.
I agree evals have become one of the better techniques for building quality AI products. Still, I kept thinking: “if evals are a new idea to you, what were you doing before?” I worry some teams may latch onto evals as the answer instead of asking what problem the eval is helping them understand.
At one point, I described an open source AI tool I worked on using acceptance criteria in a way that felt pretty close to normal software development practice. The response made me feel judged, like everyone else had collectively decided, “this guy doesn’t get AI.”
Maybe I’m reading too much into it. But my reaction was: if you know how to build good products without AI, you are probably better prepared to build good products with it.
The reason AI products need evals is pretty straightforward: AI behavior is probabilistic, while a lot of our existing software practices are built around deterministic behavior. Evals give teams a way to measure how acceptably an AI system behaves across varied inputs, semantic judgments, and failures. The mechanism is genuinely different, even if the responsibility underneath it is familiar.
The connection I see
Good teams have always needed ways to make “good” visible early enough to influence what gets built, and measurable enough to improve once the product meets reality.
We often talk about product management through categories like prioritization, discovery, strategy, and execution. Underneath all of that is the less visible work of creating enough shared context for better decisions.
This is the deeper connection I see between acceptance criteria, TDD, Gherkin, and AI evals. At their best, these are all more than artifacts: they’re clarity-builders. They help a team answer questions at a level beyond functional requirements:
What are we trying to make true?
What would convince us it’s true now?
What else would we need to feel convinced if things get murky?
The structure of the artifact matters, though the conversation matters more. An acceptance scenario or eval helps most when it improves shared understanding and affects what gets built. That’s the risk I’m trying to name: mistaking the artifact for the discipline.
Three Tools, One Discipline
The difference between TDD, Gherkin, and evals is mostly about where each one belongs in the development lifecycle.
TDD asks whether a unit of code behaves deterministically as intended.
Gherkin describes how a product should behave in a specific user or business scenario and the conditions a solution must satisfy.
Evals measure how reliably a probabilistic system demonstrates acceptable behavior across a range of inputs and outputs.
These are different questions, but they come from the same instinct. Before the team gets too far into the work, each practice asks us to slow down and name what success would look like.
AI makes this harder because it’s not an option to predict all the ways an AI will respond ahead of time. You learn what good means by seeing real behavior in action, finding edge cases, and noticing where the model fails.That gives the same product responsibility a new surface area.
The Integration Mistake
I hope eval hype does not lead teams to treat evals as the whole development system. Evals feel specialized because AI behavior is specialized, so I understand why older methods can suddenly feel outdated.
I’d rather see teams weave evals into the development system they already have. Keep the standards that work and use evals as another layer in how the team decides whether the product is working.
The eval should connect back to the product promise. Acceptance scenarios explain the user or business context. Tests protect the parts of the system that should behave reliably. Research, analytics, and support feedback help show whether the product is solving the right problem.
I see these as different lenses on the same question: what does good look like here?
What Product Teams Should Hold Onto
Teresa Torres’s practical guide to AI evals helped reinforce the distinction for me. The methods are evolving, but several product principles should remain stable.
The part product teams should hold onto is pretty simple: evals do not decide what good means. We do.
That judgment still belongs to the team. If a failure can be caught with code, use code. If the question requires semantic judgment, use an eval. If the problem is that the workflow does not help the user make a better decision, the eval suite will not save you from that.
Counterpoint
When the model behavior is the product itself, evals naturally become much more central.
If you are building an LLM, chatbot, coding agent, or another experience where most of the user value comes from the model output, I get why evals deserve a lot of attention. My concern is more with teams adding AI into existing products and workflows, where model quality is only one part of the product experience.
I don’t want evals to become an escape hatch from asking whether the team is applying AI to the right judgment in the first place. Those product questions existed before AI, and they are still with us.
Quality Is the Constraint You Should Not Trade Away
You might be familiar with the old delivery tradeoff adage: quality, scope, and time. Pick two.
I tend to think quality should be protected first. AI can make that harder to care about because first versions are faster and better looking than ever. That’s why defining good early feels more important in AI work, not less. Judgment is expensive and evals are one way to make that expense visible before users pay for it.
The goal is to build clarity around the things that would be expensive to discover late. Some ambiguity is productive. You want room for learning, taste, craft, and surprise. I like evals because they give teams a way to work with ambiguity instead of pretending it’s gone.
Make “Good” a Conversation First
Evals are worth learning. Teams building AI products should understand how to use them, especially when they are dealing with probabilistic behavior, judgment calls, and failure modes that normal deterministic tests do not catch very well.
The part I keep coming back to is the product discipline underneath the mechanism. When we talk about evals, we should talk about them as part of a system because good teams have always needed ways to discuss quality before the work is too far along to change.
The question I’d ask is simple: did the practice help the team see something earlier, make a tradeoff clearer, or get more honest about what “good” means in this context? If it did, it probably helped the team build with more care.
That is where I think evals fit best. They connect to the rest of how the team builds, learns, and decides, especially in places where AI introduces new ambiguity into the product experience.
“Good” should be a conversation before it becomes a gate.