Tempo logotype

Develop a product innovation strategy using the Jobs-To-Be-Done framework

How to use the Jobs-To-Be-Done framework to identify unmet customer needs and build a product innovation strategy grounded in real outcomes.
From Team '23

Tempo Team

Key Takeaways

  • A product innovation strategy should point at unmet customer needs. Once the underlying need is right, feature velocity and market share tend to follow.

  • Clayton Christensen's Jobs-To-Be-Done framing names the core job, and Anthony Ulwick's Outcome-Driven Innovation extension scores which needs are underserved enough to invest in.

  • Underserved needs are the outcomes users rate as highly important but poorly satisfied, and that gap is where innovation effort earns its return for a product team.

A product innovation strategy built on Jobs-To-Be-Done anchors roadmap debate on what customers need the product to do, so the team stops arguing about features in the abstract.


Think of the JTBD framework as a way to extend the useful life of your product's core value proposition. It points your roadmap at unmet needs that competitors haven't solved yet.

While that's a useful exercise, most teams stop at outcomes. They understand what customers need from the tool. How do you rank the options so you can make better decisions?

That's where Anthony Ulwick's Outcome-Driven Innovation brings the value. Use it to score every desired outcome on importance and satisfaction – that's how to surface underserved needs worth investing in. Here, we'll outline how to bring these methods together.

What is a product innovation strategy?

Andrei Draganescu puts it clearly in his article for Hackernoon. Product innovation is not:

  • Optimizing profits or increasing returns

  • Improving feature delivery times

  • Increasing market share

Those are outcomes of a successful innovation strategy. They're not what the strategy should aim for. Draganescu proposes that a sound product innovation strategy should focus on two goals:

  1. Increase the size of the core user base

  2. Increase the amount of value added by the product

The benefits follow directly from those two goals. But product innovation isn't without risks.

No framework can guarantee success – it can only provide a structured approach to either growing your user base or adding product value. Genuine innovation requires a culture built around experimentation and iteration, which takes real investment at the business, product, and leadership levels. And innovation initiatives often take years to show returns, creating pressure on PMs answering to executives or investors who want short-term results.

Despite those risks, product leaders consistently include innovation strategy alongside their core product strategy. The alternative is stagnation.

Why is product innovation important?

According to Alpha's 2019 Product Management Insights report, many of the PMs they surveyed wanted to spend more time running product experiments and building a culture of continual experimentation. They also said they don't spend enough time talking to users, running surveys and interviews, and using that data to build prototypes and experiments that actually inform the product strategy.

The PMs we've spoken to confirm this. They want to deliver more value to the customer. They want more time to validate their strategies at every level. And they want better access to the quantitative and qualitative data they need to make innovative product decisions.

The right innovation framework acts as a compass – pointing teams toward higher customer value, giving them a process for validation, and producing the customer data they need to make decisions with confidence.

What is the Jobs-To-Be-Done framework?

The Jobs-To-Be-Done (JTBD) framework was first proposed by Clayton Christensen, a professor at Harvard Business School. The central idea: Users don't just buy products – they "hire" them to get a job done.

Anthony Ulwick took that further. He created the Outcome-Driven Innovation (ODI) Framework to give teams an actionable, measurable way to apply JTBD. His argument is simple: The goal of innovation is to identify unmet user needs and build solutions that address them.

"How to get a handle on customer needs is an unsolved mystery – and that mystery is killing innovation. Before a company can succeed at innovation, managers must agree on what a need is – and the types of needs that customers have. Jobs-to-be-Done Theory provides a framework for (i) categorizing, defining, capturing, and organizing all your customer's needs, and (ii) tying customer-defined performance metrics (in the form of desired outcome statements) to the Job-to-be-Done." – from Jobs to Be Done: Theory to Practice by Anthony Ulwick

The ODI process Ulwick defines has three stages: Define the market and the core functional job to be done, map the customer's desired outcomes using a job map, and quantify and prioritize based on which needs are underserved or overserved.

After that research, teams can identify hidden segments of opportunity – classifying needs as over-served, appropriately served, or under-served. From there, you align existing products to those gaps (market strategy) and conceptualize new products and features for unmet needs (product strategy).

– Source: Jobs to Be Done: Theory to Practice by Anthony Ulwick

Define your market and the core job to be done

The target market in JTBD is defined as: a group of people + the job they're trying to get done. Teachers who want to save time on grading papers. HR professionals who want to onboard new employees without friction. Designers who want to validate prototypes quickly.

The core functional job to be done is anything – problem, task, goal, objective – the user is trying to accomplish, improve, or avoid. Ulwick uses the example of a kettle. The wrong definition: "to boil water for tea." The right one: "to make a hot beverage." That distinction matters because it opens up what you can build. A narrow job definition leads to a narrow product. A broader one leads to a Keurig.

Beyond the core functional job, there are two other job categories to map. Related jobs are the functional jobs the user is trying to do alongside the core job. If the core job is "to support my family," related jobs include "send children to a good school" and "set up a college fund." Emotional jobs describe how users want to feel or be perceived while doing the core job.

The more job categories a solution addresses, the more likely it is to sustain long-term market success.

Use a job map to uncover desired outcomes

Once the core functional job is defined, the next step is a job map – a breakdown of the steps a customer takes to complete the job, organized into eight categorical stages.

– Source: Strategyn

This is an observation exercise, not a brainstorm. The goal is to document what users are actually doing to achieve the job – based on real qualitative data from interviews, observation, and interaction with current users. Keep it need-focused ("share a file externally with stakeholders"), not solution-focused ("choose a PNG, JPG, HTML, or PDF and save it"). That distinction trips up a lot of teams.

A job map isn't a customer journey. The goal is to understand what success looks like on the path to completing the core job. From the job map, teams generate desired outcome statements – the metrics users use to measure how well they're accomplishing the core job. Here's an example using music storage and retrieval:

– Source: JTBD.info

Desired outcome statements need to meet a few criteria to be useful. They should describe ways users would like to do the core job more efficiently. Aim for 50 to 150 statements per core functional job – breadth is the point. And each statement should be actionable, measurable, and independent of any specific solution or time constraint.

Discover and prioritize the needs you will solve

After mapping the core job and generating desired outcome statements, classify them into buckets using a prioritization approach like the Kano model. Run a needs assessment – survey or interview your users using a Likert scale – and ask them to rate each outcome statement on two dimensions: how important it is, and how satisfied they are with current solutions.

Mike Boysen describes five resulting categories.

- Underserved needs (very important, very unsatisfied) are the best innovation opportunities.

- Overserved needs (very unimportant, very satisfied) are candidates for simplification or removal.

- Irrelevant needs (very unimportant, very unsatisfied) are safe to deprioritize.

- Appropriately served needs (somewhat important, somewhat satisfied) deserve current investment levels.

- Table stakes (very important, very satisfied) must be preserved – but they won't be a source of differentiation.

– Source: Mike Boysen

The best innovation opportunities live in the underserved and overserved buckets.

Looking ahead to the Jobs-To-Be-Done canvas

Companies like Intercom have applied this process successfully to identify why customers use their products and where real unmet needs lie.

One of the best ways to get started – before user interviews, surveys, and qualitative measurement exercises – is a JTBD canvas workshop with the product team. Reading Anthony Ulwick's book is another good starting point. From there, a Jobs-To-Be-Done canvas exercise lets the team:

  • Theorize which customer segment to target

  • Build shared understanding of what core jobs and desired outcome statements actually are

  • Agree on how that information will feed into the innovation strategy

The canvas isn't the research – it's the setup. It gets everyone speaking the same language before they go talk to customers.

Build a product innovation roadmap

Once you've run the JTBD process and identified the highest-opportunity needs, the next step is planning how your organization will pursue them over the coming quarters. That's what an innovation roadmap captures.

Organizations use innovation roadmaps to map new opportunity areas, test ideas, and stay ahead of the technologies that could reshape their markets. To remain competitive, companies need to look forward – at what customers need today and what they'll need next.

Innovation roadmaps are most often built by product managers and executives to align departments on strategic initiatives. They make disruption intentional rather than reactive.

Start a free Strategic Roadmaps trial and use our product innovation roadmap template to map your plan.

Sign up for a demo

Request Demo

Tags

  • 2026 State of SPM report
  • Strategic Roadmaps

2026 State of SPM report

This is the data you've been looking for

This original research from almost 700 PMO leaders shows you what is working, what is wobbling, and what it all means for SPM in 2026.

Download the 2026 State of SPM report
Special Offer

Frequently Asked Questions

Couldn't find what you need?Go to ourHelp Center

Product improvement refines what already exists – better performance, fewer bugs, a smoother interface. Product innovation addresses needs that are currently unmet or underserved, often in ways the user wouldn’t have explicitly requested. The JTBD framework is specifically designed to find innovation opportunities – not routine improvements – by starting from jobs and outcomes rather than features.

Ulwick recommends 50 to 150 per core functional job. The number seems high, but the breadth is the point – the more outcome statements you capture, the finer your view of where customers are and aren’t satisfied. Teams that work with fewer than 30 statements tend to miss important nuances in the underserved bucket.

Survey data is what separates an underserved need from a blind spot. If users consistently rate an outcome as highly important but poorly satisfied by current solutions – including yours and competitors’ – that’s a real signal. If the importance rating is also low, the team may simply have dismissed something that doesn’t actually matter to customers.

Yes, but it requires running the process separately for each distinct user type. A project management tool, for example, might have very different core jobs for an individual contributor, a team lead, and a portfolio manager. Mapping only one of those jobs and treating it as representative of all users will produce incomplete results.