How Do You Know Experience First Is Working?
Experience resists metrics — but the signals still show up. The directional evidence we saw after going experience-first, and the trap that makes it look expensive.
Every argument for experience-first eventually hits the same wall: prove it.
It's a fair challenge. Most of what this manifesto asks for — clarity, trust, recovery, treating everyone impacted as a user — resists clean measurement. You can't put "trust" on a burndown chart. And the moment you try to reduce experience to a single KPI, you've usually missed the point of it.
So this post comes with a caveat up front: what follows is not a controlled study. We didn't run an A/B test on our own philosophy. These are directional signals — things we noticed moving together after we shifted to an experience-first approach, observed across enough initiatives that the pattern stopped looking like coincidence. Treat them as evidence, not proof.
The interesting part isn't just that the signals improved. It's why they're connected — and the one condition under which they quietly reverse.
The signals moved as a chain, not a list
When we looked back at what changed, the metrics weren't independent. They formed a sequence, each one feeding the next.
1. Functional bugs went down.
This was the first thing we noticed, and the most counterintuitive to outsiders. Spending more time on experience before writing production code meant we discovered the contradictions early — the workflow that didn't survive a second persona, the state that had no recovery path, the configuration the customer would inevitably need. We were finding these in prototypes, where a fix is an afternoon, instead of in production, where a fix is a regression risk. Fewer unknowns reaching engineering meant fewer defects leaving it.
2. Sprint velocity went up.
This follows directly from the first. Velocity doesn't collapse because people type slowly — it collapses because teams rework, firefight, and re-litigate decisions that were never really settled. When the hard questions are answered in discovery, engineering builds against a stable target. The work stopped thrashing. Velocity is a notoriously gameable metric on its own, so we don't lean on it in isolation — but rising velocity alongside falling bugs tells a coherent story that neither tells alone.
3. Sales sentiment improved.
A coherent product demos like a coherent product. When the experience is designed end-to-end, there's no seam for a prospect to fall through mid-demo, no "ignore that part, it's still rough." Sales stopped apologising for the edges. The thing felt like it was built on purpose, because it was — and that confidence is contagious in a room.
4. Retention and renewals improved — specifically where we'd demoed prototypes.
This is the signal we trust most, and the one hardest to fake. Customers who saw the experience-first prototype during discovery renewed at a higher rate. The reason is simple: the prototype made a promise, and the production system kept it. There was no gap between what they were sold and what they got. The trust established in the demo survived contact with the real thing.
Read the chain top to bottom and it's almost obvious: internal quality signals (bugs, velocity) surface as external trust signals (sales, renewals). Experience-first doesn't improve these things separately. It improves the one underlying thing — coherence — that all four of them measure from different angles.
Of the four, anchor on the last one. Bugs and velocity are real but noisy. Renewals hit revenue and are very hard to game. If you can only watch one number, watch whether the customers who saw the prototype stay.
The trap: experience-first looks expensive when it's done against the grain
Here's the part that matters most, because it's where the signals reverse.
In the cases where experience-first seemed slow or expensive, the problem was never experience-first itself. It was that we'd tried to achieve it while violating systems-first thinking. Two patterns did the damage.
Anti-pattern 1: Rebuilding the foundation to deliver the experience.
On more than one initiative, delivering the desired experience kicked off a rebuild of deployment pipelines or core infrastructure mid-flight. The end product stalled — not because the experience work was wasteful, but because we'd entangled it with a foundation rebuild that should have been sequenced separately. The velocity gains evaporated. To anyone watching, "experience-first" got the blame for what was really a systems-sequencing failure.
Anti-pattern 2: Force-fitting experience-first features into legacy systems.
When we bolted experience-first features onto systems that weren't designed to carry them — ignoring the structural reality underneath — the bug count climbed back up and the work got expensive fast. You can't paint a coherent experience over an incoherent foundation and expect it to hold. The seams come back. And when they do, "experience-first is expensive" becomes the lesson people take away, when the actual lesson is experience-first divorced from systems-first is expensive.
Both anti-patterns are really the same mistake: treating experience-first and systems-first as a trade-off instead of a partnership.
The real conclusion
The signals improve when experience-first and systems-first reinforce each other. Discovery proves what's worth building and what earns trust; a sound foundation makes that experience cheap to deliver and keep. That's the engine. (We've written about that handoff in From Discovery to Delivery, and about why cheap implementation makes this viable in The Death of the 'Code Is Too Expensive' Excuse.)
The signals degrade the moment you trade one for the other — when you chase experience by rebuilding foundations at the wrong time, or by force-fitting it onto systems that can't hold it. That's also exactly what experience-last looks like from the inside: the friction shows up, and experience takes the blame.
So how do you know experience-first is working? You don't watch a single number. You watch whether bugs, velocity, sentiment, and renewals start moving together — because when they do, it means the experience and the system underneath it are finally telling the same story.
And if it starts feeling expensive, don't conclude that experience-first failed. Check whether you stopped doing systems-first.