Strategyn 12re

Innovation Assessment Research – fINDING 03

Understanding customer needs is the goal of innovation. It’s also the most misunderstood.

Most organizations are doing customer research. The problem isn’t effort. It’s framing.

393 innovation leaders helped us prove it.

Table of Contents

Only 15% of innovation leaders say they understand their customers’ needs well.

71% of innovation leaders rate understanding customer needs as very or extremely important. Only 15% say they do it well. That gap isn’t explained by a lack of research investment.
Most organizations are running customer interviews, fielding surveys, reviewing support tickets, tracking feature requests. The work is happening. What the data reveals is something more precise: the work is producing something that looks like a clear picture of customer needs but functions like a blurred one.

The result is that product, marketing, and strategy end up working from their own version of what customers want. The organization isn’t aligned around customer needs. It’s aligned around competing interpretations of them. Investments get made based on whoever argues loudest rather than on data. Solutions get built for the symptom rather than the cause.

This is not a research problem. It is a framing problem. And it starts earlier than most teams realize.

Four reasons customer research misses the mark

In our study of 393 innovation leaders, four of the six most critical innovation decisions share one root cause: organizations don’t know what their customers need with enough precision to act on it. These four breakdowns aren’t separate. Each one makes the next harder to solve. Fix them in sequence, or the ones further down the chain don’t improve.
  • 15 %
    satisfied with how precisely they define customer needs

    Your team isn’t working from the same definition of customer needs

    In most organizations, needs get captured differently by different people: requirements specs, user stories, support transcripts, executive recollections from last quarter’s customer call. Each is an honest attempt. By the time product, marketing, and engineering sit down together, they’re working from different versions of the same thing. The result looks like alignment. It isn’t.

  • 17 %
    satisfied capturing a complete set of customer needs

    Your research only finds the needs your current product already addresses

    The set of needs your research finds is bounded by the frame it brings. Research organized around an existing solution finds what that solution already addresses. The needs that fall outside its scope stay invisible. Until a competitor finds them.

  • 17 %
    satisfied identifying the root causes of unmet needs

    You’re solving the symptom, not the cause

    Teams are often skilled at solving problems once a clear target exists. The failure is in the targeting. When a need is identified without understanding why it’s unmet, the solution addresses the surface. The underlying cause stays intact and resurfaces in the next product cycle, attributed once again to execution.

  • 15 %
    satisfied knowing which customer needs are most unmet

    You’re prioritizing the loudest needs, not the most unmet ones

    Knowing what customers need is different from knowing which of those needs are most worth solving. Without a quantitative way to measure unmet need across the full market, priority defaults to whoever argues loudest: the most vocal customers, the most persuasive executive, the strongest interpretation of qualitative data. Teams build for what they heard about most, not what represents the greatest opportunity.

    • “Research framed around your solution can only find the needs your solution already addresses.”

Why research anchored to your product can’t see beyond it

Research framed around your solution can only find what it already addresses

Customer needs captured in solution language
Blurred Picture		Customer needs captured using outcome language
Sharp Picture
Capture what customer “say” they wantCapture what customers are trying to achieve.
Surface product complaints and feature requests.Surface measurable results, independent of any solution.
Anchor to the solutions that customers can imagine today.Anchor to customer outcomes that won’t change when the technology does.
Every interpretation is defensible. Non is decisive.Every need is stable over time and quantifiable.
The difference matters. A company doesn’t buy scheduling software because it wants scheduling software. It buys it because it’s trying to coordinate work across teams. Frame the research around that Job, not the product, and you surface every outcome that matters when coordinating work, whether the current software addresses it or not. Frame it around the product, and you get opinions about features you already built.

This is the methodological difference at the center of Outcome-Driven Innovation® (ODI®). Define the research question around the Job, not the solution. The research then surfaces Desired Outcomes: measurable statements of what customers are trying to accomplish, independent of any specific product. What becomes visible changes. What becomes possible to build changes with it.

If your team is already using a Jobs-to-be-Done approach, the question worth asking is whether it produces a quantitative Opportunity Score (a ranked view of which outcomes are most unmet across the full market) or qualitative insight. Both are useful. Only one produces the priority ranking an investment decision requires.

How ODI defines customer needs: the methodology behind Desired Outcomes and Opportunity Scores

Microsoft Case Study

Microsoft: A declining business doubled its revenue

Microsoft’s Software Assurance business was declining. The research question had been: what do customers think of this product?
Strategyn reframed it: what are IT decision-makers trying to accomplish when managing software assets across an enterprise?
Research question · Before
What do customers think of this product?
Bounded by the offering. The answer is feedback about what the product already does.
Research question · After
What are IT decision-makers trying to accomplish when managing software assets across an enterprise?
The Job is larger than the product. Unmet outcomes outside the current offering become visible.

A declining business 2X its year-over-year revenue.

The Job was larger than the product. When it was mapped in full, unmet outcomes around workforce productivity, deployment efficiency, and license management became visible: outcomes a product-first question couldn’t have surfaced. Microsoft restructured the offering around those needs.
…we realized that we were only really engaging with the customer in one tiny piece of their job—the purchase of the software. But this was just part of a much bigger challenge that they faced. We were not engaging with them in many of these other areas that were very important to them and where they were very dissatisfied.”
Dave Wascha, Director
See where your customer needs process stands.

What becomes possible when needs are defined correctly

What getting customer needs right makes possible

When customer needs are defined precisely, completely, and at the right level (the Job, not the product), the decisions that depend on them become reliable.

  • Internal Alignment

    Teams stop debating what to build.

    When everyone means the same thing when they write down a customer need, the competing-interpretations problem dissolves. Product, marketing, and engineering work from the same picture.

  • Complete Coverage

    Competitors stop beating you to the things you missed.

    When research is framed around the Job, the set of needs it surfaces is complete. Nothing stays invisible because it lives outside the boundary of what you already offer.

  • Quantitative priority

    Investment goes to the right problems.

    Knowing which needs are most unmet, across the full market and not just among the loudest customers, turns roadmap decisions from political to analytical. The Opportunity Score replaces the persuasive argument.

  • Durable solutions

    The solutions you ship last.

    When you understand why a need is unmet, the fix addresses the cause. The same problem doesn’t resurface in the next cycle.

    • Once the needs are defined this way, the segmentation question follows naturally: which customers have the most unmet ones? Once you know the needs, this is the next gap
“Strategyn’s process is the only one I know of that can reliably identify unmet needs and predict which innovations will succeed in the market.”
— Philip Kotler, Kellogg School of Management, Northwestern University

Innovation Assessment

Find out if customer needs definition is your biggest gap

Your organization almost certainly has customer research. The question worth asking is whether it’s precise enough to guide you to the right problems. Not the loudest ones. Not the ones your strongest internal advocates have already decided to solve. The right ones.

The Innovation Assessment measures exactly that. It evaluates where your organization’s innovation process is strongest and where it’s most at risk, across all five stages from strategic direction to market impact.

Free. 10 minutes. Personal score.
Take the innovation assessment→ See all four findings→

FAQ’s

In innovation, a customer need is the measurable outcome a customer is trying to achieve when performing a Job — not a feature request or product preference. Outcome-Driven Innovation® (ODI®) defines customer needs as Desired Outcomes: stable, quantifiable statements of what customers want to accomplish, independent of any specific solution. This definition matters because it determines what research can find. Needs defined as product preferences shift every product cycle. Needs defined as Desired Outcomes remain stable for decades, and can be surveyed, scored, and prioritized with the same rigor as any other business metric.

71% of innovation leaders rate understanding customer needs as very or extremely important. Only 15% say they do it well. That gap explains most product failures. When needs are imprecisely defined, teams work from competing interpretations rather than a shared picture. Investment decisions get made based on whoever argues loudest. Products get built for the symptom rather than the cause. Understanding customer needs is not one research activity among many — it is the foundation that every downstream innovation decision depends on. Get it wrong and execution inherits the cost.

Customer wants are solution preferences: features, products, or services customers say they’d like. Customer needs are the outcomes customers are trying to achieve, regardless of what solutions exist. Wants shift as markets evolve. Needs are stable. Asking customers what they want produces a wishlist bounded by what they already know exists. Asking what they’re trying to accomplish — the Job-to-be-Done — surfaces the complete set of needs, including those no current solution addresses. The distinction determines what research can find, and what products can be built.

The key is framing research around the Job-to-be-Done rather than the current solution. Most customer research asks what customers think of the product — which produces opinions about what already exists. ODI instead asks what customers are trying to accomplish across the full scope of the Job, independent of any solution. The outputs are Desired Outcomes: structured, measurable statements that can be surveyed at scale. Quantifying which outcomes are most unmet produces an Opportunity Score — a ranked view of where the greatest growth potential lies. This turns a judgment call into a data-driven priority.

Most customer research is framed around the current solution. It asks what customers think of the product, what features they want, what they would change. That frame produces answers about what already exists. The needs that fall outside the current offering — the ones that often represent the greatest growth opportunity — stay invisible. Research framed around the Job-to-be-Done finds the complete picture: every outcome customers are trying to achieve, whether the current product addresses it or not. The frame the research uses determines what it can find. And what it cannot find never gets built.

Learn about where you stand