The Hidden Reason Teams Can’t Learn Why Their Products Fail
The Meeting They Keep Having
The product launched six months ago, burned through $4M in development, and significantly underperformed projections. The portfolio review meeting is running two hours over. Leadership needs to decide: kill it, pivot, or double down on a redesign?
Design has data showing 60% cart abandonment at the payment screen due to a confusing workflow. Product has data showing that the target persona was wrong: they should have focused on CFOs, not VPs of Operations. Sales has consistent feedback that pricing was the barrier. Marketing has metrics suggesting the value proposition messaging didn’t resonate. The SVP of Innovation needs to recommend a path to the CEO and board by Friday.
Everyone has data. Each interpretation seems defensible. But the suggested fixes are impossible to substantiate without knowing the customers’ metrics for success. Doing everything better is not a good strategy.
Post-mortems yield ambiguous findings that can take months and significant resources to clarify, if they can be clarified at all. Despite all the work and data collected, the real problem is that the foundational information about the customers’ unmet needs was never obtained.
This common scenario isn’t the result of organizational politics or poor leadership. It’s what happens when teams treat discovery as experimentation rather than investigation. Customers can tell you what jobs they’re trying to accomplish and how they measure success. But teams skip this discovery work, jumping straight to MVPs to “test” what customers need, when they should be investigating first, and only then generating ideas and experimenting with solutions.
Like a doctor prescribing treatment without doing a diagnosis first, when the treatment fails, it is difficult to tell if you misunderstood the problem or if the solution did not work.
Most organizations do not realize they are testing two fundamentally different things at once. The industry trains us to “talk to customers” and “validate concepts,” but few teach the critical distinction between understanding what jobs customers are trying to accomplish versus testing their perceptions of your solution. Conventional wisdom sets teams up to fail.
Why Even the Best Teams Can’t See This Pattern
Your organization likely has excellent UX researchers revealing how users interact with products. Strong market researchers tracking competitive dynamics. Talented product managers validating concepts. Yet discovering what customers are fundamentally trying to accomplish, independent of any solution, falls into an invisible gap between these functions. This isn’t anyone’s failure; it’s how the industry has organized customer understanding.
Recent research in Technovation by Tao Wang tracked 2,064 drug development projects and shows a clear pattern: early-stage failures in preclinical research improve both early-stage and late-stage performance, while late-stage clinical failures primarily improve late-stage execution.
Although Wang’s study focuses on solution-side stages in biotech development rather than discovering customers’ unmet needs, the same pattern shows up in product innovation. The failure to understand customer needs cannot be fixed by iterating on solutions. These require fundamentally different knowledge and skills.
Wang’s research examined only solution-space failures, looking at the differences between early and late-stage drug development. It did not study the more fundamental gap between discovering customer jobs and outcomes versus developing solutions. If teams can’t learn clearly when mixing solution stages, they certainly can’t learn when mixing discovery with development. The industry uses the terms “discovery” and “development,” but treats discovery as experimentation with prototypes rather than systematic investigation. This conflation is the root of the problem.
Here is a simplified composite example inspired by what repeatedly shows up in Business Intelligence and postmortems. Under pressure to show progress, a team interviews executives who all say they would “definitely use” a real-time analytics dashboard if it existed. The signals look strong, so the team does what most organizations reward: they invest, build, and launch. Adoption is minimal, churn is high, and subsequent iterations don’t fix it.
Whether testing an MVP, running an A/B test, or measuring post-launch metrics, negative signals create the same interpretation problem: you are trying to learn two fundamentally different things from a single experiment:
- Did we understand what customers are trying to accomplish? (The diagnostic question)
- Did we build and deliver on the customers’ unmet outcomes? (The execution question)
But here is the causality that matters: Question 1 must be answered first. It is the diagnosis that makes Question 2 meaningful. You cannot evaluate treatment effectiveness without knowing if you diagnosed the problem correctly.
Most organizations skip or shortcut discovering what job customers are actually trying to accomplish and how they measure success. They make assumptions based on a few interviews, then jump straight to building.
When the solution fails, the ambiguity is structural: you don’t know if you addressed the wrong need or if you addressed the right need poorly.
The Front End of Innovation: Diagnosis Before Treatment
To correct this problem, consider the front end of innovation to be the process of discovering target customers’ unmet needs and then generating solutions to address them. Just as a doctor must diagnose before treating, product teams must systematically discover what unmet jobs and outcomes customers are trying to accomplish before building solutions.
Here’s what this actually means:
Discovery (Diagnosis): What jobs are customers trying to accomplish? How do they measure success (their desired outcomes)? Which outcomes remain unmet with their current solutions?
Discovery requires systematic interviewing, not experimentation with prototypes. You do not need an MVP to learn what jobs and outcomes customers are trying to accomplish. But you do need to know what customer inputs to obtain and how to get them.
This is not a question of “would they like this feature” or “does this concept sound interesting.” It is systematic investigation of what customers are trying to get done and how they evaluate whether they’ve accomplished it successfully.
Theodore Levitt said it clearly: “People don’t want to buy a quarter-inch drill; they want a quarter-inch hole!” The drill is the solution. The hole is the job to be done. They’re separate and distinct. Asking customers about their interest in a drill can confirm they need holes but it does not tell you what kind, where, why, or how they will measure success. That’s the difference between solution validation and job discovery. The best way to reveal this critical information is to ask them!
If you get this wrong, nothing else matters. You could build the most elegant, well-executed solution in the world, and it won’t matter unless it addresses an important unsatisfied job.
Solution Development (Treatment): The most effective innovation teams discover their target customers’ unmet jobs and outcomes before generating solutions. Then ideas are generated to address the most attractive market opportunities. With this information obtained upfront, you can run solution tests that get clearer signals about its effectiveness in helping customers get their job done.
In many organizations, customer interviews are still used primarily to validate concepts and features, rather than to systematically uncover customers’ underlying jobs and the outcomes they use to measure success. When people say, “It sounds interesting, I’d probably use it,” teams don’t know what else to ask beyond solution interest. The product gets built on those assumptions, launched, and then results are measured.
But when it underperforms, the data doesn’t tell you what went wrong. Engineering is arguing about the product’s effectiveness (“this feature can be improved”). Product is questioning the diagnosis (“We targeted the wrong job entirely”). Sales is somewhere between both. Marketing might be arguing both simultaneously.
The problem isn’t the quality of analysis, it’s process: the diagnostic work was skipped so when treatment fails, you don’t know if the diagnosis was wrong or the treatment was ineffective.
No amount of sophisticated post-mortem analysis can fully fix this, because the ambiguity comes from never collecting the foundational information in the first place. This is why you keep having variations of this same meeting about different products across your portfolio.
You’ve probably tried multiple approaches to fix this: better stage gates, more customer interviews, faster iterations. But without the missing diagnostic step, knowing what type of customer inputs to obtain and how to get them, these improvements are like prescribing stronger medicine without confirming the diagnosis. The harder you try using current methods, the more frustrating it becomes. You’re not failing at innovation. You’re succeeding at a flawed process.
What This Actually Costs You
The visible cost is obvious: wasted development investment on products that don’t perform.
The invisible costs are larger:
Decision paralysis – You can’t confidently kill projects or double down on redesigns because you don’t know what failed. Projects limp forward consuming resources while leadership debates.
Resource misallocation – Teams spend months rebuilding the solution when the fundamental job understanding was wrong. Or worse, they abandon a sound concept because execution wasn’t good enough on the first attempt.
Team demoralization – Smart people exhaust themselves through multiple iterations that don’t clarify anything. They’re working hard, analyzing thoroughly, and still can’t figure out what’s wrong.
Board and investor confidence erosion – You’re explaining why you didn’t know this before you invested $4M. The pattern of ambiguous failures makes your innovation process look unsystematic.
Personal career risk – Your reputation is attached to a portfolio of ambiguous failures. You can’t point to clear learning because the failures didn’t teach anything definitive.
Opportunity cost – Resources and attention locked in ambiguous iterations instead of being deployed to opportunities where the unmet need to address has been validated.
The most expensive cost: Your organization isn’t actually getting better at innovation. Your failures aren’t teaching you whether the diagnosis was wrong or the treatment was ineffective, so you can’t systematically improve success rates.
The Pattern That Is Hard to See
Here’s why this is nearly impossible to see from inside the organization: Teams operate from two common but invalid assumptions: (1) innovation begins with an idea, so they skip discovery and jump to solutions, and (2) customer needs must be discovered through experimentation with prototypes, rather than through systematic investigation of jobs and outcomes. Both assumptions feel logical, but both create confounding results from experiments.
So, you do what looks rigorous: customer interviews, concept validation, then build. You’re following best practices. But here’s what may be hard to see: those interviews asked about solution interest (“would you use something like this?”) while assuming you understood the job customers are trying to accomplish.
In the BI example above, when they finally step back and do systematic discovery, they learned that the real job those executives are trying to accomplish is “prepare quarterly board materials that frame performance in a coherent narrative,” not “monitor performance in real time.”
The original interviews validated interest in a solution category without discovering the underlying job to be done. They skipped the diagnostic work, jumped to treatment, and when treatment failed, couldn’t tell if the diagnosis was wrong or the execution was poor.
The Missing Step: Systematic Discovery Before Solutions
Organizations that learn how to conduct jobs-to-be-done customer discovery before generating ideas or development accelerate learning because they have clarity about:
- The target customer
- The core job they are trying to get done
- How they measure success (their desired outcomes)
- Where they struggle given their current solutions (important, unsatisfied outcomes)
This reveals where to focus and what to do to create new value.
Now when you build and launch:
If you obtain this information upfront, before generating ideas, you avoid confounding what should be two separate tasks of innovation: First, discover the target customers’ unmet needs and then generate ideas to address them.
With this information, when your product solution underperforms, you will know it is because the solution is not effectively addressing the customers’ known unmet outcomes. You can iterate on the solution with confidence because you know your understanding of the foundational job is sound. Or you can kill the project quickly knowing that the product will never be able to deliver the satisfaction required.
Portfolio review meetings become far less likely to devolve into two-hour circular debates. Everyone up and down the organization and across all departments understands where the opportunities lie and what you must help customers accomplish to be successful.
This reduces the number of iterations required to achieve product-market fit and accelerates learning with every iteration because your experiment is no longer confounded with two unknown variables.
The Investment Almost No One Makes
Systematically discovering your customers’ unmet needs with a Jobs-to-Be-Done (JTBD) approach is often criticized for taking time and resources that most organizations don’t allocate. There are two issues driving this behavior:
- A lack of knowledge about how to implement a lean qualitative JTBD approach
- The unrecognized waste of time and resources that are inevitably spent building and pivoting without a solid understanding of the customers’ jobs and outcomes.
Without this upfront work, you’re back in the circular portfolio review meeting. Engineering says execution. Product says wrong diagnosis. Sales says pricing. Nobody can prove their case because the foundational information about what customers want was never obtained.
Most innovation portfolios right now have multiple projects where teams skipped or shortcut the diagnostic work and jumped straight to building. Smart teams, rigorous process, real investment, but failures that can’t teach you what actually went wrong, because the foundational jobs and outcomes were never clearly defined.
After 20 years helping organizations navigate this missing discovery step, including seven years working with Tony Ulwick who pioneered these distinctions, I’ve seen how transformative Lean JTBD OS™ discovery becomes. This critical infrastructure transforms innovation from an ad hoc activity into a systematic business process grounded in validated market opportunities.
I help business leaders and innovation professionals reduce market risk by systematically revealing their customers’ unmet needs so they know what to build and how to position it.
