Eval-Driven Product Development
Design the test for your AI product alongside the product, then hill-climb the model against it.
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
In AI products the underlying technology is fuzzy and non-deterministic, so you can't assume a fixed input yields a fixed output. Evals — quizzes or unit tests for a model — are how you measure whether the model is good enough for your specific use case and how you make the model measurably better over time. Weil argues writing evals is becoming a core skill for product builders because the ceiling of your product is set by how well you can define and measure success.
Origin
Articulated by Kevin Weil (CPO, OpenAI) from building products like OpenAI's Deep Research, where evals were designed in parallel with the product and used to fine-tune the model.
Core principles
- 01An eval is a quiz/unit test that gauges how well a model performs on a specific set of tasks
- 02Whether the model is right 60%, 95%, or 99.5% of the time dictates a fundamentally different product design
- 03Model performance is not static — you can teach the model and turn improvement into a continuous, measurable process
- 04Your product quality is effectively capped by the quality of your evals
How to run it
- 1
Define your hero use cases
Identify the specific questions or tasks your product must handle well. Write down concrete examples of a query and what an amazing answer to it looks like.
Pro tip Models are good at helping you write evals — use them to draft cases.
- 2
Turn hero use cases into evals
Convert each ideal question/answer pair into a repeatable test that scores how close the model's output is to the target answer.
Watch out Don't rely on vibes or one-off spot checks — non-deterministic models need scored, repeatable measurement.
- 3
Measure current model performance
Run the evals to learn whether the model gets your use case right 60%, 95%, or 99.5% of the time, and design the product around that reality.
- 4
Hill-climb by fine-tuning against the evals
Fine-tune or otherwise improve the model, re-running the evals each time to confirm performance is climbing on the measures you defined as important.
Pro tip Route human corrections back in as fine-tuning data so the system keeps improving from real usage.
In the wild
For Deep Research — a product that spends 25-30 minutes to produce work that would take a person a week — the team designed evals at the same time as they designed how the product would work, going through hero use cases (a question, and an amazing answer for it), turning those into evals, then hill-climbing and fine-tuning the model on them.
→ A shippable product whose improvement was continuous and measurable rather than static and hoped-for.
Common mistakes
Treating the model as static
Assuming the model just does what it does and hoping it performs; instead you can teach it and make improvement a continuous, measured process.
Building before you understand the hit-rate
Committing to a product design without knowing whether the model is 60% or 99.5% right on your use case leads to the wrong product architecture.
Is it for you?
Best for
Product managers and founders building products on top of LLMs who need to know whether a use case is production-ready
Not ideal for
Deterministic software where the same input always yields the same output and correctness is trivially verifiable
From the transcript
“writing evals is going to become a core skill for product managers”
“we were designing eval uh sort of at the same time as we were thinking about how this product was going to work”
“turning those into eval and and then hill climbing on those evals”
“If the model's 60% right on something, you're going to need to build your product totally differently”
From the episode
OpenAI’s CPO on how AI changes must-have skills, moats, coding, startup playbooks, more
Kevin Weil (CPO at OpenAI, ex-Instagram, Twitter)