Most MVPs answer the wrong question
Building a minimal version of your product still tests whether you can build it. It rarely tests whether anyone wants it.
Aug 4, 2026 · 4 min · KPIndicator
An MVP answers "can we build a working version of this." That's a real question. It is not the question that kills most startups.
Most startups die from building something nobody asked for, competently. The MVP process — sprint, ship, iterate — assumes you already know the thing is wanted and you're now refining how you deliver it. If that assumption is wrong, every iteration afterward is refining the wrong answer faster.
The order most people run it in
- Have an idea
- Build a version of it
- Put it in front of people
- Find out if they want it
- Iterate, pivot, or quit
Steps 2 and 3 are expensive and slow, and they happen before step 4 — the only step that actually tells you anything about demand. You've spent your cheapest, fastest resource (time before you've built anything) on the step that teaches you the least.
The order that actually tests demand
- Have an idea
- Put a specific offer in front of the right people
- Measure what they do — not what they say
- Build the thing that already has evidence
Step 2 doesn't require a working product. It requires a landing page that makes a specific, falsifiable claim, and enough real traffic to see whether people respond to it. That's a week of work and a few hundred dollars of ad spend, not a quarter and a headcount.
"But talking to customers is validation"
Talking to customers tells you what people say they'd do. It's necessary and it's not sufficient — people are generous in conversation and expensive in reality. The gap between "I'd definitely use that" in an interview and a completed checkout is where most false positives live. Behavioral data — clicks, signups, deposits — closes that gap because it costs the respondent something, even if it's just five minutes and an email address.
What this doesn't mean
It doesn't mean don't build. It means sequence the spend correctly: cheap, fast demand tests before expensive, slow product builds — and build the thing that already has a demonstrated buyer, not the thing that seemed obviously good in a planning meeting.