Every product manager has heard the stat. “95% of new products fail.” It shows up in pitch decks, MBA textbooks, and LinkedIn posts. The number traces back to a Harvard Business School classroom reference by professor Clayton Christensen. According to MIT Professional Education, he estimated that 30,000 new consumer products launch every year. And 95% of them disappear.
But that number is wrong.
Not completely wrong. But misleading in a way that hurts teams trying to build something new. The 95% figure bundles finished products with half-baked concepts that died in R&D, line extensions that got quietly pulled, and ideas that never left the whiteboard. When researchers focus only on products that are actually launched, the failure rate drops to 35–45%. That’s still bad. Roughly 4 out of every 10 launched products fail to meet their commercial goals. But it’s a very different story from “almost everything fails, so why bother.”
The real question isn’t whether products fail. They do. The question is whether your team is making the same avoidable mistakes that cause most of those failures. The reasons products fail aren’t mysterious. They aren’t random. They follow the same patterns, again and again. And most of them could’ve been caught before a single line of code was written, if someone had just tested the idea first.
This article breaks down what the research actually says, why products keep failing for the same five reasons, and what the fastest product teams do to test ideas before they commit.
The Real Product Failure Rate (It’s Not 90%)
The 95% number has a life of its own. It gets repeated so often that it feels like a law of nature. But it doesn’t hold up.
According to Nielsen, as reported by Inc., the failure rate for consumer packaged goods sits at around 85%. That’s high. But CPG is a narrow category with tight margins and razor-thin shelf space. It doesn’t represent all products.
According to LA New Product Development Team, decades of academic research put the average commercial failure rate at roughly 35–45% for products that actually reach the market. That figure comes from meta-analyses of product launch studies, not a classroom anecdote.
The gap between 95% and 40% matters. It changes how you think about risk. If you believe that basically nothing works, you either become reckless (“why bother with research”) or paralyzed (“the odds are too bad to try”). Neither attitude produces good products.
There’s also a gap between startups and established companies. According to Highlight, startups face failure rates between 60% and 80%. Established companies sit closer to 30–40%. That’s not because big companies are smarter. It’s because they start with built-in advantages: distribution channels, customer data, and brand recognition.
The 40% number is honest. Product failure is common, serious, and worth studying. But the inflated 95% stat scares more teams than it helps.
5 Reasons Products Fail (That Teams Keep Repeating)
If product failure were random, there’d be nothing to learn. But it isn’t. The same five problems show up over and over in case studies, post-mortems, and research papers.
1. The Product Solved a Problem Nobody Had
This is the biggest one. According to Highlight, about 30% of product failures come down to this: the product didn’t solve a real need.
The Segway is the textbook example. When it was announced in 2001, the hype was enormous. Investors called it bigger than the internet. The technology was genuinely impressive: a self-balancing electric scooter with sophisticated gyroscopic sensors.
But nobody needed it. Walking was free. Bikes existed. Cars existed. The Segway was priced at $5,000 and targeted consumers who had no painful gap in their daily transportation. It became a punchline.
The problem wasn’t engineering. The problem was that no one asked enough regular people, “Would you actually pay $5,000 to avoid walking?”
Product-market fit (the match between what you’re building and what people actually need) is the single biggest predictor of success or failure. According to Busy Rebel, weak product-market fit causes 35% of all new product failures. Skip this step and you’re gambling. The house usually wins.
2. The Price Told the Wrong Story
According to Highlight, pricing kills about 25% of new products. Not because the product is bad, but because the price doesn’t match what people think it’s worth.
Google Glass launched in 2013 at $1,500. The tech was impressive: a heads-up display built into a pair of glasses. But $1,500 put it in the same bracket as a high-end laptop or a vacation. For most consumers, the value didn’t come close to justifying the cost. According to Supahub, the price tag was a major reason for its failure, making it inaccessible to most potential buyers.
Amazon made the same mistake with the Fire Phone. It was priced at $199 with a contract, the same as an iPhone. But it lacked the app ecosystem, the camera quality, and the brand loyalty that justified Apple’s price. Consumers compared them side by side and the Fire Phone lost every time. Amazon reportedly took a $170 million write-down on unsold inventory.
Pricing isn’t about being cheap. It’s about alignment. Your price has to match what your customers believe the product is worth.
3. The Team Built First and Asked Questions Never
Joan Schneider and Julie Hall studied product launches for over a decade. Their findings appeared in Harvard Business Review. The biggest problem they found wasn’t bad products. It was bad preparation.
Their core finding: companies get so focused on designing and manufacturing new products that they postpone getting ready to market them until too late in the game.
New Coke is the classic case. Coca-Cola ran extensive taste tests in the 1980s and found that consumers preferred a sweeter formula. What they didn’t test was the emotional attachment people had to the original brand. The taste tests measured flavor. They missed loyalty, identity, and nostalgia. New Coke lasted 79 days.
Then there’s Juicero, as reported by Product Focus. A $400 juicing machine that squeezed proprietary fruit packets into a glass. The technology was polished. The investors were impressed. But Bloomberg reporters found that you could squeeze the juice packets by hand, with your bare fingers, and get the same result. Nobody had asked ordinary consumers whether they’d pay $400 for a machine that did something their hands already did for free. Juicero shut down 16 months after launch.
Research isn’t just about “do people want this?” It’s about “do people want this enough to change what they’re already doing?” That second question is harder. Most teams never ask for it.
4. Users Couldn’t Figure It Out in Five Minutes
A good idea poorly executed still fails. According to Brainkraft, a McKinsey survey found that 80% of customers expect a new product to work flawlessly from the first interaction. If users can’t figure out your product within the first few minutes, most won’t try again.
Windows Vista launched in 2007 to massive anticipation. Microsoft had spent five years and billions of dollars on it. But the experience was painful. The system was slow. The drivers didn’t work. Programs crashed. Users were frustrated from minute one.
Apple seized the moment and launched its “I’m a Mac / I’m a PC” ad campaign, painting Vista as bloated and unreliable. Within a year, Vista had become shorthand for “software that doesn’t work.”
Google Wave had the same problem. It was a real-time collaboration tool combining email, messaging, and document editing. Ambitious concept. But Google produced an 80-minute introductory video to explain how it worked. Eighty minutes. If your product needs a feature-length film to explain, something has gone wrong.
Usability isn’t a nice-to-have. It’s a gatekeeper. If your product creates friction where it should create flow, your users will find something simpler.
5. The Market Moved While the Product Was Still Being Built
Timing is the most underrated factor in product failure. According to SGW Design Works, the Center for New Product Development found that the average product development project exceeds its schedule by 120%. A product planned for a six-month build often takes over a year.
During that extra time, things change. The customer needs a shift. Competitors ship their own versions. The economy turns. The market that existed when you started building may not exist when you finally ship.
Microsoft launched tablet PCs in the early 2000s. They were heavy, ran full desktop Windows, and had clunky stylus-driven interfaces. The market wasn’t ready. The technology wasn’t right.
Apple waited. They watched others fail. They studied why. When they launched the iPad in 2010, they had the right device at the right moment: lightweight, touch-based, with a mature app ecosystem behind it. The iPad sold 300,000 units on its first day.
Being too early can be just as deadly as being too late.
One Root Cause Connects All Five Failures
These five problems look different on the surface. One is about demand. One is about price. One is about research. One is about usability. One is about timing.
But they share a single root cause: the team built before they tested.
They assumed demand existed instead of checking. They assumed the price was right instead of asking. They assumed the design was clear instead of watching someone try it. They assumed the timing was good instead of studying the market.
Not all of these failures could’ve been prevented. Some products are genuinely ahead of their time, and no amount of research will change that. But the expensive, embarrassing ones? The ones that burn through millions before anyone notices the problem? Those are almost always testing failures.
The pattern is simple: teams treat building as the starting point. They should treat testing as the starting point. Build the cheapest possible version of your idea (a mockup, a wireframe, a clickable screen) and put it in front of real people. Watch what happens. Listen. Then decide whether to keep going.
How to Test a Product Idea Before You Build It
The fix isn’t complicated. It’s not expensive. It’s just frequently skipped.
Interview 10 Potential Users Before You Write a Line of Code
Before you write code, before you hire designers, before you order materials: talk to the people you’re building for. Not your team. Not your investors. Not your friends. Your actual target customers.
Sit down with 10 to 15 of them. Ask open questions about their problems, frustrations, and workarounds. Don’t pitch your solution. Just listen. Lisa Richards, who built The Candida Diet into a successful health brand, told Tremendous: “We go through surveys, interactions on social media, we do focus groups, and we just ask our clients what their needs are.”
You’re not listening for “would you buy this?” (people almost always say yes to be polite). You’re listening for the intensity of the problem. Do they already spend money trying to solve it? Do they complain about it without being prompted? Have they built messy workarounds? If yes, the demand is real. If they shrug, it’s not.
Build a Prototype, Not the Full Product
A prototype is a working model of your idea. It looks like the real thing, but it isn’t fully built. It might be a set of clickable screens, a wireframe showing layout and flow, or a paper sketch you walk someone through.
The point of a prototype isn’t to impress. It’s to learn. According to Brainkraft, a CB Insights study found that thorough concept testing (including prototyping and user feedback) increases the chance of a successful product launch by up to 30%. That’s a massive edge, and it costs a fraction of what full development costs.
This is where tools matter. Teams that can prototype fast have a structural advantage over teams that can’t. Visily lets non-designers build high-fidelity wireframes and clickable prototypes in minutes, using AI-powered design features and drag-and-drop editing. That means a product manager can test an idea with real users before a single developer writes a single line of code. The cost of learning drops to near zero.
Your prototype doesn’t need to be perfect. It needs to be real enough that users react honestly. If they get confused by the flow, you’ve found a usability problem. If they ask “why would I need this?” you’ve found a demand problem. If they say “I’d pay $10 for this but not $50,” you’ve found a pricing insight. All of that is gold, and dramatically cheaper to find during prototyping than after launch.
Watch a Real Person Use Your Product Before Launch Day
Usability testing is the simplest form of product validation. Sit someone down with your prototype. Give them a task. Watch.
Don’t explain. Don’t guide. Don’t say “click there.” Just observe. Where do they hesitate? Where do they look confused? Where do they try something and it doesn’t work the way they expected?
If your prototype needs an 80-minute explainer video (like Google Wave), you’ve got a design problem. If users can’t complete a basic task within two minutes, you’ve got a usability problem. Both are fixable, but only if you catch them before you ship.
The best teams run usability tests in cycles. Build a version. Test it. Fix the problems. Build the next version. Test again. Each round gets cheaper and faster. By the time the real product ships, the biggest problems are already solved.
Product Failure Isn’t the End. It’s Data.
One more thing about the 40% failure rate: it doesn’t mean those products were wasted.
Every failed product generates information. It tells you what the market didn’t want, what the price ceiling was, what the design got wrong, what the timing missed. That information is expensive to acquire, but extremely valuable if you use it.
The companies with the best long-term track records aren’t the ones that avoid failure. They’re the ones that fail fast and fail cheap. They test before they build. They prototype before they commit. They run small experiments instead of big bets. And when something doesn’t work, they learn from it instead of pretending it didn’t happen.
Startups have a natural advantage here. They can move quickly, test cheaply, and change direction without wading through layers of corporate approvals. But big companies can do it too, if they’re willing to treat early-stage product ideas with the same experimental mindset.
The teams that win aren’t the ones that avoid failure. They’re the ones that find it fast, before it costs them everything.
Stop Guessing. Start Prototyping With Visily (It’s Free)
Every product failure in this article shares one thing: the team skipped the cheap test that would’ve caught the problem. They built the full product before anyone outside the building had touched it.
You don’t have to make that mistake.
Visily lets you turn a product idea into a clickable, high-fidelity prototype in minutes. No design skills required. No weeks of wireframing. Just describe what you want to build, drag and drop the pieces into place, and put it in front of real users before you spend a dollar on development.
The next time you’re excited about a product idea, don’t start with code. Start with a prototype. Test it with five real people. Watch where they get stuck. Fix it. Test again.
That single step cuts your risk of joining the 40% by more than you’d expect.
Try Visily for free and build your first prototype today.
