Product Strategy
Product Validation: What the 80% Unused-Feature Finding Really Means
Product validation starts by separating feature usage from product failure. Pendo’s 2019 Feature Adoption Report found that 80% of features in the average sampled software product were rarely or never used. That is not a finding that 80% of products fail.
I use that distinction when reviewing a roadmap: unused features can expose a mismatch, but low usage alone does not explain why a business succeeds or fails. A rarely used emergency control may still be essential.
This guide shows what the evidence does support, how to check three warning signs, and how a two-week prototype test informs your next investment. Treat the worked budget example as a planning scenario, not a client result.
TL;DR — the whole guide in five lines:
- 80% describes feature usage in Pendo’s 2019 sample, not a universal product failure rate.
- Demand and usability are different risks. Test whether the problem matters as well as whether the interface works.
- Three warning signs deserve investigation: no one-sentence problem statement, a feature-list roadmap, and first user contact scheduled after launch.
- Earlier evidence changes the cost of a decision. It does not guarantee a success rate for your project.
- Drill before you excavate — a two-week validation sprint puts real users on a prototype before the production budget moves.
What is product validation?
Product validation gathers evidence to decide whether assumptions about a problem, workflow, demand, and economics support the next investment. It can recommend continuing, adjusting, waiting, or stopping; it does not guarantee business success.
Bring the riskiest workflow to Blueprint & Prototype.
The Real Reason Products Fail (It’s Not the Code)
CB Insights’ historical analysis of 101 startup post-mortems reported “no market need” in 42% of that failed-startup sample. That is a reason reported by already-failed companies, not a measured failure rate across all products.
Not funding. Not competition.
Not technical debt. They built something nobody wanted.
Here’s the sequence that produces that outcome. We’ve watched it play out dozens of times:
- Someone senior has an idea
- Stakeholders add requirements in a conference room
- A team builds for six to twelve months
- The product launches
- Silence
By the time a real user touches the product, the budget is spent. Every decision along the way — features, pricing, platform — rested on assumptions:
- “Users will pay for this”
- “The real pain point is X”
- “They’ll find us through channel Y”
Assumptions feel like facts when smart people agree on them. But agreement in a meeting room is not evidence. The only people who can confirm an assumption are users — and in the standard process, they’re consulted last.
| Meeting-room consensus | User evidence | |
|---|---|---|
| Source | Stakeholders agreeing with each other | Real users attempting real tasks |
| Feels like | Certainty | Friction and surprises |
| Arrives | Before the build — for free | In the standard process: after launch |
| Cost to change course | Cheap — it’s still a plan | The full build budget |
So the question that decides your product’s fate isn’t “can we build this?” It’s “how early does reality get a vote?”
Next: Warning Signs Your Product Will Fail.
Warning Signs Your Product Will Fail
Three signals predict that outcome with uncomfortable accuracy. We check for all three in every discovery call.
1. Nobody can state the problem in one sentence. Ask three people on the team what specific problem the product solves, and for whom. Three different answers — or any answer containing “everyone” — means you’re funding a hope, not a product. The test: “We help [specific user] solve [specific problem] so they can [specific outcome]” — in under 15 words, same answer from everyone.
Author’s note — Ganis Atmawarin: 2. The roadmap lists features, not problems. “Build dashboard, add payments, create admin panel” assumes the solution is already known. A roadmap written as problems — “help users see their progress weekly” — keeps the team honest about what each feature is for, and lets evidence change the answer before code does.
3. First user contact is scheduled after launch. If real users meet the product on launch day, the entire budget has been bet on the assumptions being right. That puts the cost of changing direction at its highest point; no universal percentage predicts your outcome.
One sign is a warning. Two is a pattern.
Three means stop and validate before spending another rupiah on development.
Next: How does earlier product validation change an investment decision?.
How does earlier product validation change an investment decision?
Earlier feedback reduces the amount you commit before learning; it does not establish a universal success multiplier. Pendo’s 2019 report measured feature usage, not whether Agile or Waterfall caused product success.
Use an explicit decision sequence instead: write the assumption, choose a test, record the result, and decide whether the next investment is justified. For usability, watch a relevant user attempt the actual task.
For demand, look for a meaningful commitment such as a paid pilot or signed order.
The useful comparison is money committed before first evidence, not a headline percentage applied to every project. A team can run short sprints and still avoid users.
A regulated project can have formal gates and still collect evidence early.
Validate it in 2 weeks. Blueprint & Prototype tests the riskiest workflow before you approve the production scope.
The Validation-First Approach: Real Users by Week Two
Think of it like mining. No serious operation excavates a mountain to find out whether there’s gold inside.
They drill core samples first — cheap, fast, targeted — and only bring in the heavy machinery where the samples prove a deposit.
Most product teams do the opposite. They buy the excavator first.
The validation-first version of that drill is a structured two-week sprint. Ours is called Blueprint & Prototype, and the shape matters more than the brand:
Week 1 — surface the bets. Extract every assumption the product depends on. Rank them by impact × uncertainty. Identify the two or three “killer assumptions” — the ones that, if wrong, sink everything.
Week 2 — test the riskiest slice. Build a prototype of just that slice. No production code. Put it in front of real users and watch what they do — not what they say they’d do.
By day 14 you have a decision-ready map, a tested prototype, and recorded user sessions. Sometimes the evidence says go.
Sometimes it says the workflow is wrong, the buyer isn’t who you thought, or the idea should die — and a no-go at day 14 is a far better outcome than a no-go at month eight.
The full mechanics are in our Blueprint methodology breakdown. And if you’re unsure what form the test should take — clickable prototype, manual pilot, or narrow MVP — we wrote a decision framework for that too.
What We’d Do with Your Next 50 Million Rupiah
Let’s make this concrete. Say you have 50 million rupiah to move a product idea forward.
Two ways to spend it.
Path A: the blind build. 50 million buys roughly six to eight weeks of development. You get a partial product — some screens, some backend — built entirely on assumptions, with most of the budget still ahead of you and zero user evidence behind you. Your first real feedback arrives after launch, when changing course is most expensive. This path commits engineering spend before collecting user evidence.
Path B: the validated path. 50 million buys the entire two-week Blueprint: assumption map, tested prototype, real user sessions, and a go/no-go decision. The production build — the 200–300 million commitment — starts only after users have signaled it’s worth building.
| Blind build | Validated path | |
|---|---|---|
| By end of week 2 | Project setup, wireframes | Real users have used a prototype |
| First user contact | After launch (month 4–6) | Day 10 |
| Wrong assumption discovered | Post-launch, budget gone | Day 14, before production |
| Cost of being wrong | The full build budget | The Blueprint fee |
| Production budget committed on | A signed spec | User evidence |
The point isn’t that building is bad. Building is the goal.
The point is sequencing: spend the smallest possible amount to find out whether the large amount is justified.
Drill first. Then excavate.
Next: FAQ.
Next Steps
Low feature usage is a prompt to investigate. Check the purpose of a feature, who needs it, and how often before deciding to remove it.
If you’re about to commit a serious budget to a build, give reality its vote first. See how the two-week Blueprint works — the target is an evidence-backed decision at the end of the sprint.
FAQ
Why do most products fail?
Causes vary across demand, economics, execution, funding, and market conditions. In CB Insights’ historical sample of 101 startup post-mortems, 42% mentioned no market need.
That is a reported reason in a failed-startup sample, not a universal measure of all products.
What percentage of new products fail?
There is no universal product failure rate established by the evidence cited here. Pendo’s 80% finding concerns rarely or never used features in its 2019 sample.
Measure your own activation, repeat usage, and business outcome instead of using it as a product failure probability.
How do you validate a product before building it?
Collect three pieces of evidence, none of them opinions: proof the problem exists and hurts (users describe it unprompted), proof your solution fits (users complete the core flow in a prototype without coaching), and proof of commitment (pre-orders, signed pilots, or money). A structured two-week sprint — assumption mapping in week one, prototype testing with real users in week two — is designed to look for all three, although buyer commitments can take longer.
Positive feedback in a demo meeting counts for none of them.
Isn’t validation just a two-week delay?
A validation sprint is useful when its findings can change a costly decision. The feature-usage study does not measure the share of your assumptions that are wrong.
Its value depends on the question, access to users, and test quality. The slowest path to a working product is shipping the wrong one first.
Can’t I just launch an MVP and iterate?
You can, but be honest about what you’re calling an MVP. If it takes four months to build, it’s not a minimum anything — it’s a full product resting on untested assumptions.
A real MVP tests one hypothesis with the least machinery possible. Validate the hypothesis first; then the MVP gets dramatically smaller.
Sources
Related Posts
Two weeks to a real answer
Need help putting this into practice?
Book a Blueprint session and we'll turn the ideas in this article into a tested prototype in front of real users—2 weeks, from $3,000.
