Every product team is measured on velocity, because velocity is easy to see. Features shipped, tickets closed, sprints completed. What almost nobody measures is confidence: whether the thing being shipped is the thing that should have been built. Those two numbers can move in opposite directions for a long time before anyone notices, and by the time they do, the cost is already compounding.
Velocity is easy to measure. Confidence isn't.
This isn't negligence. It's structural.
Shipping is visible. Learning isn't. A feature that went out last Thursday can be pointed at in a review. A decision not to build something, made because the evidence didn't support it, leaves no artifact at all. In a quarterly planning cycle, shipping something almost always feels safer than shipping nothing, even when nothing is the correct answer.
So teams optimize for the thing they can show. The questions that determine whether the work was worth doing get asked less rigorously, or later, or not at all. Are we solving a problem people actually have? Will this be adopted at any meaningful scale? Does it move a number the business cares about? Are we building on something we've tested, or something we're hoping is true?
None of those are hard questions. They're just harder to put in a status update.
Shipping the wrong thing isn't one mistake
It's a cost that keeps arriving.
Engineering time goes into building it, and then into maintaining it. Design time goes into iterating on something with no upside. Product time goes into defending a decision that stopped making sense months ago. And the code itself constrains what can be built next.
Then the politics start. Once something ships, it acquires weight. People have invested in it. Reversing course means someone admitting the original call was wrong. Roadmaps start bending around prior decisions rather than current evidence, and ROI conversations quietly turn from forward-looking evaluations into retrospective justifications.
Meanwhile, users mostly don't complain. They disengage. Extra steps, unclear labels, features that add cognitive load without adding value rarely generate a support ticket. They generate a slow drift in the numbers that gets noticed a quarter after the team committed to the direction that caused it.
The false choice
Here's where the conversation usually goes wrong. Someone says validation matters, and everyone hears slow down and do more research.
That's a false dichotomy, and it's the reason validation gets treated as a tax rather than a tool.
The teams that move fastest over time aren't choosing between speed and validation. They get speed through validation, because they spend less time reversing course, less time defending failed bets, and less time rebuilding things that were wrong from the start.
Validation isn't a twelve-week discovery phase. It's removing uncertainty as early and as cheaply as the situation allows. Three things are worth knowing before committing real build effort: that the problem is real and has consequences for someone, that the proposed solution resolves it without creating new friction, and that it plausibly moves something the business measures. How you learn those things can be lightweight. What matters is intent and timing, not ceremony.
Start with Learn, not Build
Lean Startup is usually invoked as permission to move fast. Read carefully, it says close to the opposite.
Build-Measure-Learn isn't "ship something and see what happens". The word doing the work is minimum: build the smallest thing that tests the assumption you're least sure about. The goal isn't an incomplete product. It's an answer before the commitment gets expensive.
The teams that get value from it run the loop backwards. What do we need to learn? How would we know? What's the least we have to build to find out? Starting at Build and adding analytics afterward isn't validation. It's hope with instrumentation.
Context decides which one wins
The balance isn't universal, and pretending it is does more damage than either extreme.
Speed should win when a competitor is shipping comparable functionality and timing genuinely matters. When a regulatory change or a seasonal window forces action on incomplete information. When the decision is reversible, what Bezos called a Type 2 decision, the kind you can undo cheaply. And when you already have the infrastructure to validate in production: feature flags, real instrumentation, the ability to roll back without drama. That last one is validated speed, not unvalidated speed, and the distinction matters.
Validation should win when the decision is expensive to reverse: core architecture, positioning, platform investments. When you're entering territory you don't know, where your assumptions are most likely to be wrong. When the change touches security, pricing, or a workflow people depend on. And, counterintuitively, when you're early. Startups should move fast, but the thing they need to be fast at is learning, not building.
The difference between high-performing teams and struggling ones isn't that one moves faster. It's that one knows which situation it's in.
AI widened the gap, it didn't close it
This is the part that has changed most, and not in the direction most people assume.
AI made production dramatically cheaper. Generating variations, drafting copy, producing screens, standing up a prototype: all of it collapsed in cost. Validation got cheaper too, but nowhere near as much, because the expensive part of validation was never the analysis. It was deciding to look, finding the right people, and being willing to act on what came back.
So the ratio moved. Teams can now produce far more, far faster, while their capacity to know whether any of it is right has improved only marginally. The gap between things built and things verified is wider than it has ever been.
The consequences are already visible. Nielsen Norman Group's State of UX 2026 describes users growing tired of AI features that exist so a product can say it has them, and identifies trust, not capability, as the central design problem of the year. That is what unvalidated speed looks like at scale: not a dramatic failure, but an accumulation of things nobody asked for, eroding confidence in the product that shipped them.
There's a second-order version of this too. AI is genuinely useful for synthesis, for finding patterns across a pile of interviews, for reducing the drudgery that made research feel expensive. But a faster path to insight is worth nothing if the team still hasn't decided that insight should change the plan.
Research theater
Which brings up the distinction that matters most, and it has nothing to do with tooling.
There's a difference between testing to find out whether something works and testing to build stakeholder confidence in a decision already made. Both produce a deck. Only one changes anything.
The tools enable validated speed only if the findings are allowed to alter the next move. If the answer was never going to change the plan, the research wasn't validation. It was cover.
The question worth asking
There's a diagnostic that surfaces this quickly. Ask a team: if this turns out to be wrong, when would we find out, and what would we do about it?
If the answer is that nobody would know for two quarters, there isn't enough confidence to justify building yet. If the answer is that people would know quickly but the plan wouldn't change because of a deadline or an executive commitment, the problem isn't validation. It's that evidence isn't allowed to matter, and no amount of research will fix that.
The goal was never certainty. Certainty isn't available. The goal is confidence proportional to what the decision costs to get wrong.
The bottom line
Teams that win over time aren't the ones shipping the most. They're the ones shipping the right things, learning from each one, and compounding that understanding until they need fewer attempts to get somewhere.
That isn't slower. It's faster, in the only measurement that matters, which is how long it takes to arrive somewhere worth being.
References
Nielsen Norman Group, State of UX 2026: Design Deeper to Differentiate, January 2026. Eric Ries, The Lean Startup, 2011.
