Works, Usable, Used
Three layers of validation, each looking at different things.
Validation comes in three layers. Each layer answers a different question and uses different methods. Mix them together and you validate nothing clearly. Nor is validation a pre-launch ritual — it's a judgment you make after every piece of a feature.
What you'll run into:
- It's live, but you don't know which number to look at, so you watch how many people open it each day
- The numbers are bad, and you can't tell whether it's a bug, the flow is too convoluted, or nobody needs it
- Acceptance is you clicking around, and you always click the path you already know
What each layer looks at
| Layer | It answers | How to validate | What failure looks like |
|---|---|---|---|
| Works | Is the function correct; do abnormal cases crash it | Walkthrough checklist, real-data stress, security checks | White screen, errors, data loss |
| Usable | Can a stranger finish on their own | Five-second test, three to five people trying while you watch | They get stuck, or need you to explain beside them |
| Used | Do they come back and would they pay | Tracking, retention curves, conversion funnels | Used once, never again |
The "usable" layer is the easiest to skip because it requires finding people, which is inconvenient. But three to five people, twenty minutes each, surface more problems than you clicking a hundred times yourself. Usability testing is the standard method for assessing whether real people can use a product smoothly. usability
The three layers answer three sets of questions: does it run, is it usable, is anyone using it. The first two rely on walkthroughs and observation; the third relies on tracking and data — different tools, and mixing them means using the wrong method on the wrong layer. Also, "works" isn't a one-time pre-launch pass: every change can introduce a regression, so the state checklist plus a real-data stress run is a fixed step after each feature.
The order can't be shuffled
The three layers are dependent. If the lower layer doesn't hold, the upper layer's conclusion is meaningless.
- If it doesn't pass "works," don't look at retention. If it crashes mid-flow, low retention is guaranteed — it has nothing to do with whether the need is real.
- If it doesn't pass "usable," don't rush to drive traffic. Pulling people in only to lose them at step two is paying for churn.
- If "someone uses it" doesn't hold, the first two layers being polished is wasted effort. Something nobody needs, no matter how smooth, won't bring anyone back.
- But the order you discover things is often reversed. Bad numbers, find someone to try it, a step doesn't work, dig into the code and find a bug. So you need to be able to work all three layers — whichever layer you find the problem on, chase it down from there.
Knowledge work adds a layer: trustworthy process
All three layers assume one thing: the result you're looking at is trustworthy. But when what you're validating is AI-generated knowledge work — analysis, proposals, models, copy — that assumption stops holding. Code can be validated by its output with tests; knowledge work can't. No matter how pretty the numbers in a deck are, they prove nothing about the reasoning behind them. You have to be able to inspect the process, the inputs, and the citations to believe the result. This layer is trustworthy process — an extra validation layer AI knowledge-work products need. For the specifics, see How to Validate Knowledge Work.
When judging an AI product, keep this layer in mind: does it show you the work in progress, the citations and inputs, the reasoning? If it can't give you those three, it only delivers conclusions — you can never verify it. Add this layer to the other three, and validation is complete.
Doing it solo
Running solo, you can schedule the three layers across time:
| When | What to do |
|---|---|
| After finishing a feature | Go through the state checklist row by row; run empty data and extra-long content once each |
| Before launch | Run the whole walkthrough checklist, security items included; go through the full flow with a brand-new account |
| At launch | Tracking must already be in place. A feature without tracking is a feature that didn't ship |
| First week after launch | Watch three to five real users, and don't coach them |
| One month after launch | See whether the retention curve flattens — that decides whether to keep investing |
The hardest part of observing users is keeping your mouth shut. The ten seconds they're stuck are the most information-dense ten seconds of the whole test — the moment you start explaining, those ten seconds are gone. The layers work together: layer one after finishing a feature, layer two before launch, layer three after launch. Only when all three pass is it truly delivered.