# Day 09: Why a capable model is still not a product

Users never experience your benchmark scores.

They experience the wait. The empty state before they know what to type. What happens when it fails. Whether they can tell if the answer is trustworthy. Whether the whole thing saved them any effort compared to doing it themselves.

A model can be excellent at all of that being terrible.

## The happy path is the easy path

Here is the pattern I keep seeing. A team demos an AI feature: the input is well-formed, the answer is good, everyone agrees it is ready. It ships. Adoption is poor and nobody can explain why.

The reason is almost always off the happy path. These are the states nobody designed, because the demo never visited them:

- **Loading.** Eight seconds of nothing feels broken. Streaming the response changes the perceived experience more than a model upgrade would.
- **The empty state.** Users faced with a blank box do not know what the system can do, so they ask something trivial, get a trivial answer, and conclude it is trivial.
- **Failure.** What does the user see when it goes wrong, and can they do anything about it, or is it a dead end?
- **Recovery.** Wrong answer. Now what? Retry, refine, edit, escalate to a human? If the answer is "start over," most users just leave.
- **Trust signals.** Can they tell a well-grounded answer from a guess? Without that, they either over-trust it or abandon it, and both are failures.

## Measure completion, not answer quality

This is the shift that reframes everything: **track whether users finish the job, not whether the output looks impressive.**

Answer quality is a component metric. Task completion is the product metric, and the two diverge constantly. A correct answer that took ninety seconds, or that the user could not verify, or that arrived with no way to act on it, did not complete anything.

Once you measure completion, the priorities usually reorder themselves, and the top of the list is rarely the model.

## A test for readiness

Ask the team to describe the failure states before the happy path. What the user sees while waiting, when it breaks, when the answer is wrong, when they want to try again.

If those descriptions are vague, the feature is not ready, regardless of how the model scores.

## Closing thought

Model capability creates possibility. Application design turns possibility into value, and it is where most AI products are actually won or lost.

*Day 9 of 60 Days of Production AI Systems.*

---

**Previous:** [Day 08: Why production AI needs structured outputs](https://blog.vamsiannamreddy.com/day-08-why-production-ai-needs-structured-outputs)  
**Next:** [Day 10: When to use a chatbot, workflow, or agent](https://blog.vamsiannamreddy.com/day-10-when-to-use-a-chatbot-workflow-or-agent)  

*Day 9 of 60 · From LLM Demo to AI Product (chapter 2 of 10)*