95% of AI projects fail to scale. The PMs who know evals are building the ones that don’t.
Every AI PM interview at OpenAI, Anthropic, Google, and Meta now tests for the same thing. Not whether you can talk about evals conceptually. Whether you can define eval dimensions, build a test dataset, write eval criteria, and set blocking thresholds that prevent bad releases from reaching production.
Most PM candidates can say “evals are important” and explain what they are at a high level. Almost none of them can walk through the end-to-end process of actually building one. That gap is where offers are won and lost right now.
Ankit Shukla walked through the complete process on the Product Growth podcast and what he described is the operating system for any AI PM shipping a product where the LLM output actually matters.
The end-to-end eval process most PMs can’t articulate
Start with success criteria and expected behavior. What does good output look like for this specific use case? Not generally. Specifically. If you’re building a customer support summarizer, good means the summary captures the resolution, the customer sentiment, and the next action. If you’re building a code assistant, good means the code runs, handles edge cases, and follows the team’s style guide.
Transform those criteria into measurable metrics. “Good summary” isn’t measurable. “Contains resolution status, sentiment classification matches human label 85%+ of the time, and includes next action when one exists” is measurable. This translation from qualitative to quantitative is where most PMs get stuck because it requires deep domain knowledge about what actually matters in the output.
Build a dataset from four sources. Production data from real users gives you the messiest, most realistic test cases. Research datasets give you academic benchmarks. Synthetic generation lets you create edge cases that production data might not contain yet. Domain experts contribute the cases that require specialized knowledge to evaluate.
Run the dataset through your product. Get expert analysis on the outputs. Use the failures to define your eval criteria. Set thresholds that block bad releases from deploying. Run offline evals before every deploy. Run online evals on production traffic. Close the loop by feeding production failures back into the dataset.
That loop is what separates AI products that ship and scale from AI products that demo well and die in production.
Why 95% of AI projects fail and what evals fix
95% of AI initiatives fail according to research from MIT. The major driver is what researchers call the “learning gap.” Teams either solve the wrong problems or build systems that don’t evolve with user needs after launch.
A strong eval practice is the direct antidote to both failure modes. It forces you to define what good looks like before you build anything, which prevents solving the wrong problem. And it forces the product to keep evolving after launch because production evals constantly surface where the model is degrading or where user needs have shifted.
The five specific reasons AI prototypes fail to scale are data drift, cost explosion, engineering limitations, missing guardrails, and collaboration failure. Evals directly address four of those five.
Data drift. Production data changes over time. Users find new ways to use your product that your training data didn’t anticipate. Online evals catch this because they’re running on actual production traffic, not the static dataset you tested against before launch. When accuracy drops on a specific input pattern, you see it in the eval results before you see it in user complaints.
Cost explosion. A model that costs $0.15 per query at launch might need to be replaced by a cheaper model at scale. Evals let you validate that the cheaper model still meets your quality thresholds before you switch. Without evals, you’re guessing whether GPT-4o mini produces acceptable output for your use case. With evals, you know.
Missing guardrails. Every AI product has outputs that should never reach a user. Medical advice that’s wrong. Financial recommendations that violate regulations. Customer communications that are offensive. Eval thresholds act as blocking gates. If a release doesn’t meet the threshold, it doesn’t deploy. That’s not a nice-to-have safety measure. That’s the difference between a product incident and a product that catches the problem before anyone sees it.
Collaboration failure. Building evals forces PMs, engineers, and domain experts to agree on what good looks like. That alignment conversation is valuable even if you never ran a single eval. The process of defining criteria together surfaces disagreements about product quality that would otherwise show up as arguments after launch.
The fifth reason, engineering limitations, is the one evals don’t directly solve. But a strong eval practice gives you the data to argue for engineering investment. “Our latency eval shows p95 response time exceeds 4 seconds on complex queries, which correlates with a 30% drop in task completion” is a more compelling engineering request than “users say it feels slow.”
What this looks like in an interview
When an interviewer asks you about evals, they’re testing whether you’ve actually built them or just read about them.
The conceptual answer sounds like this. “Evals are important for measuring model quality. We should test our outputs against a benchmark dataset and track accuracy over time.” That answer gets a polite nod and a mental note that you’re not ready for the role.
The operational answer sounds like this. “For our summarization product, I defined five eval dimensions. Factual accuracy measured by entity extraction match rate against source documents. Completeness measured by whether all resolution steps were captured. Tone measured by sentiment classifier agreement with human labels. Latency at p50 and p95. And cost per summary at current volume. Our blocking threshold was 80% on factual accuracy. Anything below that stopped the release pipeline. We found during online evals that accuracy dropped from 87% to 72% on multi-turn conversations, so we added those to the dataset and retrained.”
That answer demonstrates product judgment about AI at a level that most candidates can’t match because they’ve never done the work.
The resources that actually teach this
Ankit’s podcast episode is the most complete walkthrough I’ve found of the end-to-end process. Hamel Husain and Shreya Shankar went deep on LLM-as-judge methodologies in a separate episode that covers how to use one model to evaluate another model’s output and when that approach breaks down.
I also published a complete AI evals guide covering eval types, dataset construction, threshold setting, and the specific eval frameworks that top AI companies use in production.
The PMs who learn this skill now are going to be the ones building the AI products that actually make it to scale. The ones who keep talking about evals conceptually are going to keep losing offers to candidates who can walk through the process step by step.
