Six weeks building with Claude taught me more about Evals than any product conference

Why Evals are an 'old school' PM skill in disguise

There's a moment when you're building an AI product where you stop and think: "Is this actually working?"

Not "Does it run?" Sure, it runs. The API returns a response, the pipeline doesn't error out, the data lands in the right table. That's not what I mean.

I mean: "Is the AI doing what I need it to do, for a real person, in a real moment?"

That question is an evals question. And before I started building Wrapt last month, I assumed it belonged to engineers and researchers; people with labelled datasets and test suites and benchmarks. People who weren't me.

Six weeks in, I realised I'd been thinking about evals wrong. The core skill evals requires isn't technical. It's one PMs have been using for years. We just hadn't named it that way.

What I am building

Wrapt is an app that captures screenshots from your phone, classifies them using Claude API, and surfaces them back to you in an evening digest with a suggested next action. The idea is simple: instead of good intentions dying in your camera roll, they become a gentle prompt at the end of the day.

The classification step is where evals got real for me.

Every screenshot that comes in gets read by Claude and assigned a category - Recipe, Event, Product, Article, Inspiration etc - and an intent (is this something the user wants to do, remember or buy? That intent shapes what action Wrapt suggests when the card appears in the digest.

Get it wrong and the product experience falls apart. A recipe surfacing incorrectly as inspiration with no cook action. An event with no 'add to calendar' prompt. A product with no buy link.

This got me thinking: is Claude getting it right most of the time? And when it isn't, which wrong answers matter most?

The PM skill hiding inside evals

Product managers make priority calls constantly. Which bugs are launch-blockers? Which features get cut? Which user problems are urgent and which are nice-to-haves?

We've always been the ones deciding what "good enough" looks like, and more importantly, what "not good enough" costs.

Evals are the same conversation. The failure mode is just an AI output instead of a broken button on your product's UI.

In Wrapt, I had to rank my classification categories by cost of failure before I ran a single test. Events at the top of the list; a wrong classification here could mean a missed action with a real deadline. Inspiration at the bottom; a misclassification is annoying but doesn't cause as much 'damage'.

Now imagine measuring classification accuracy as a single percentage. An Event misclassified and a Recipe misclassified count the same. But they are not the same. One is a minor inconvenience. The other is potentially trust-ending.

The question that unlocks better evals isn't "What's our accuracy score?" It's the one PMs already know how to ask: "What does failure actually cost here, and for whom?"

“Your accuracy score will tell you how often the model is right but it won't tell you whether your product is working.”

Ekaete Inyang. Lead Product Manager @ Valtech

What I did without a proper eval pipeline

I'm a solo builder. I don't have labelled datasets, a robust test suite, a ML team. What I have is a practice I've started calling 'structured gut-checking'. I know it sounds like an oxymoron but it worked, so hear me out.

• Error hierarchy first. Before testing anything, I ranked categories by cost of failure. This ranking shaped everything as it determined which edge cases I stress-tested hardest, where I iterated on the prompt most aggressively, and where I built explicit fallback handling into the product design.

• Stress-testing what matters most. I didn't test with easy screenshots. I went looking for the ones most likely to produce high-cost errors. I chose mixed-intent content, screenshots that had minimal text, screenshots sitting awkwardly between two categories. The goal wasn't full coverage. It was to build my confidence specifically where failure was most expensive.

  
  

• Evaluating in context, not in isolation. I built the digest UI first so I could see the classification outputs the way a real user would, as a card with a suggested action, not as a row in a database. A misclassification reads very differently in context. "Ready to cook?" appearing on a news article lands differently than seeing a wrong label in a database. If you're reviewing AI outputs outside the product experience your users will actually have, you're reviewing something that doesn't really exist.

  
  

• Prompt iteration as a feedback loop. When I saw consistent misclassifications in high-cost categories, I went back to the prompt. Tightened definitions. Added examples for edge cases. Made intent criteria explicit. Before making each change I had a clear problem statement and an expected outcome, which is just another way of saying I was treating prompt iteration the way I'd treat any product decision.

Why Evals belongs in product, not just engineering

The AI industry built its eval culture in research settings, where accuracy against a benchmark is a reasonable proxy for model progress. That made sense when the goal was advancing capability.

It makes less sense when the goal is building something a person will trust with their attention every evening.

When you're building a product, quality isn't just a model property. It's a user experience. And user experience is shaped by which errors happen, how often they happen, the consequence(s) of said error, and whether there's a graceful path back. None of that lives in an accuracy percentage.

PMs have always owned the definition of "good enough" when it comes to building products. We've always been the ones evaluating and deciding which failures are acceptable and which are not, and designing products that account for both. Evals in AI products are the same job. The vocabulary is newer. The skill isn't.

If you're building with AI and you're not in the room when the eval criteria are set, you're letting someone else define what good looks like for your users. That's not a handoff that's ever made sense. It still doesn't.

What to do about it

You don't need to overhaul anything overnight. But a few shifts make a real difference:

Define your error hierarchy before you start measuring. Which failures are trust-ending? Which are merely annoying? That ranking should shape your test coverage, your prompt investment and your fallback design - before you write a single test case.

Evaluate in context. See AI outputs the way users will - inside the product, with the surrounding UI and copy that frames them. A spreadsheet of outputs is not the same as experiencing them.

Own the prompt. Prompting is essentially requirement-writing for AI. It requires knowing what the product needs to do, for whom and in what context. That's product work.

Build recovery into the design. Assume the model will get things wrong. Design the fallback before you need it.

My final takeaway

your accuracy score will tell you how often the model is right but it won't tell you whether your product is working. That question - and the judgment call it requires - has always been yours.

This piece was originally published on the author's portfolio site, ekaeteinyang.com.