Your Innovation Process Starts Too Late
Most innovation efforts do not fail because of poor execution. They fail because the process begins after the most important decision has already been made.
The pattern is familiar. A team has an idea. They build a minimally viable version of it, test it, iterate, and pivot if necessary. And yet, many months later, they still don’t have product-market fit. Not because the team lacked talent or discipline. Because no one identified a problem worth solving in the first place.
Airbnb nearly went bankrupt iterating on the wrong problem. The founders spent months tweaking growth hacks and site design before talking to hosts and guests in person. When they did, they discovered the real job was not “find a place to crash.” It was “feel safe booking a stranger’s home.” High-quality photos, trust signals, and clear expectations unlocked the growth that months of iteration had not.
Lean Startup practitioners point to Airbnb as validation of the build-measure-learn process. And the iteration loop did eventually work after the true JTBD was identified. But months of waste and existential risk came from iterating before discovering. The conversation with customers that changed everything could have happened first. You don’t need a minimally viable product to uncover what customers are trying to accomplish independent of products and services.
Airbnb survived long enough to have that conversation. Many teams do not.
The Step That Is Missing
Innovation is two sequential steps. First, discover the target customers’ unmet needs. Second, devise solutions to address them. Most organizations start at step two. They treat the idea as the beginning of the process and build rigor around testing it. Credible voices have been advocating for customer needs discovery before solution development for years. But in most organizations, the work before the idea still has no budget line, no systematic discipline, and no consistent language for what a “customer need” actually is.
The absence of a consistent language for customer needs is more consequential than it sounds. Many teams believe they are capturing customer needs before generating ideas. But what they capture is often vague needs entangled with solutions. “Customers need a faster dashboard” is not a need. It is a solution preference wearing the language of a need.
Jobs and outcomes work differently. A job describes what the customer is trying to accomplish, independent of any solution. An outcome describes how the customer measures success when executing a step of that job. Both are stable, because they belong to the customer’s reality, not to product or technology that is constantly changing. And because they are structured consistently, they can be measured, compared, and prioritized. The team can see which outcomes matter most to customers and which are least satisfied, and allocate resources accordingly. That stability is what makes them actionable. It is what allows a team to generate solution concepts against a target that does not move.
When a team starts with an idea, they are laying the foundation of a building before knowing its function. The foundation may be expertly constructed. But if the building is a hospital and the market needed a school, no amount of craftsmanship saves it. The function determines the design. In innovation, the customer’s job and unmet outcomes determine the function.
This happens because innovation has become synonymous with creativity. If innovation IS creativity, the work begins when someone has an idea. The step before the idea feels philosophical, not operational, and not manageable. So, it gets skipped.
Iterative frameworks are valuable, but they start after the need is assumed.
Lean Startup, Design Thinking, and Agile have brought real discipline to innovation. Build-measure-learn, rapid prototyping, and continuous iteration are genuine advances that have improved how teams develop and refine solutions. They can surface customer needs, but only as a byproduct of testing a specific solution. The learning is always filtered through whatever was built. If the solution is pointed in the wrong direction, so is the learning. They were created in an era when everyone believed “Customers cannot tell us what they want.”
It turns out that, when we decouple customer needs from product and service solutions as jobs and outcomes do, customers can tell us what they want, because we are asking them what they want to accomplish rather than asking them for product or service specifications.
Discovering jobs and outcomes is the equivalent of conducting a customer diagnosis to inform the development of the treatment plan. A treatment may be well-designed, carefully administered, and rigorously monitored, but if the diagnosis is wrong, the treatment cannot succeed. The issue is not the quality of the treatment. It is the absence of the diagnostic step.
What Starting Earlier Makes Possible
When a team discovers customers’ jobs and unmet outcomes before ideation, three things change.
1) The opportunity space is defined by customer reality, not by anyone’s hypothesis. The team knows which needs are important to customers and which remain underserved. Ideation happens within a validated opportunity space rather than in a vacuum.
2) Because jobs and outcomes are solution-free, the team can evaluate which opportunities are most attractive to the firm and determine the best way to address each one. Where to play and how to win. That might mean build internally through ideation and development, messaging and positioning of existing offerings, M&A, partnerships, or organizational alignment. The range of strategic options opens up because the opportunity has been separated from any particular solution.
3) And innovation conducted this way is not inherently risky, messy, or expensive. The common belief that innovation is always uncertain reflects how most companies execute it: jumping into ideas first and discovering problems later. Starting with validated unmet needs removes the largest source of risk, which is building something customers do not need. The team achieves conceptual product-market fit before development begins.
A Discipline for the Front End of Innovation
Lean JTBD OS is a qualitative, AI-augmented customer discovery discipline built on the language of Outcome-Driven Innovation, pioneered by Tony Ulwick at Strategyn. I use ODI language with his permission for its precision and clarity. It is designed to precede and complement Lean Startup, Design Thinking, and Agile, not compete with them. Iteration is the right tool for refining solutions. Discovery is the right tool for revealing which problems are worth solving first.
Your target customers are the source of truth when it comes to determining their unmet needs. Discovering those needs is where innovation really begins.
If This Resonates With You
Email me for the article “Why Brilliant Teams Build Products Nobody Wants to Buy” to be completed shortly. It goes deeper on the discovery questions and what it looks like when organizations build the discipline to answer them before they build anything else.
If you would like to be notified when the ISO-certified, online, self-paced Level 1 course on Lean JTBD OS, sponsored by the Global Innovation Management Institute (GIMI), launches in Spring 2026, register here: https://revealgrowth.com/lean-jtbd-os-course-priority-notification/
Confidential. All rights reserved by Reveal Growth Consultants, Inc.
