How To Create A Product Innovation Strategy Using JTBD

A product strategy is more than just the path towards the product vision. It should be guided by the motivation to create value that will fulfill the most pressing needs and wants of your user base.

Normally, a complete product strategy is made up of these core parts:

The target market and needs
Pricing strategy
Differentiation and innovation
Business goals (which inform the product goals)
A product roadmap

On top of that, you’ll have different goals for each phase along the product lifecycle, which in turn should also be factored into your product strategy. Here are some examples of the different initiatives that might inform your product strategy as the product grows:

Introduction phase: This is the beginning stage of the product. The strategy is mostly focused on the first core part defined above: discovering the target market’s needs and perfecting the go-to-market strategy.
Growth phase: After you successfully define the product-market fit, you move on to developing growth strategies and exploring ways to expand the product beyond that initial go-to-market definition.
Maturity phase: At this phase, your strategic focus as a company and as a product leader will be to scale teams and operations, consider opportunities to grow globally and add new products or services, continue investing in growth initiatives.

But your product strategy shouldn’t stop there if you want consistent, sustained impact and growth. This is where an innovation strategy comes in.

When you include an innovation strategy that informs those elements, you’re extending the shelf life of that value and deepening the user satisfaction that those core parts create.

Ready to level up your product roadmap? Check out our complete guide for product managers.

What's a product innovation strategy?

Andrei Draganescu put it best in his article for Hackernoon. Here’s what product innovation isn’t:

optimizing profits or increasing returns
improving feature delivery times
increasing market share

These are the outcomes of a successful product innovation strategy, not the goals it should aim for. Instead, he proposes that good product innovation should define goals around the following two pillars:

Increase the size of the core user base
Increase the amount of added value for the product

The benefits are obvious just from that definition. What product doesn’t want to increase the size of their user base or add value to their product? But it’s worth noting that product innovation strategies don’t come without any risks.

Some of the most pressing disadvantages include:

High costs and uncertain success rates: no innovation strategy or approach can guarantee success, it can only provide a “best practice” framework for either increasing the size of the core user base or the amount of added value to the product.
It requires a massive culture shift: Implementing an innovation-mindful philosophy requires reinventing the culture so it becomes heavily experimental and iterative. This requires a lot of resources (time, cost, effort) at multiple levels: the business, the product, the leadership team, the product team.
Product innovation initiatives have long-term returns: this can put a lot of pressure on the product manager who has to answer to an executive team or investors.

In spite of those risks, product leaders understand the importance of including a product innovation strategy along with their core product strategy.

Why is product innovation important?

Product managers have a few common concerns that tie into product innovation. According to alpha’s 2019 Product Management Insights report, many of the product managers they surveyed wished they could spend more time running product experiments and building a culture of continual experimentation.

In that same survey, they lamented that they don’t spend enough time interacting with users, running surveys, carrying interviews and using the results to build prototypes and experiments that inform the product strategy.

And the product managers we’ve spoken to can confirm that these findings are pretty consistent. Some common concerns PMs have shared with us when it comes to the product strategy include:

They want more value for the customer
They’d like to spend more time and resources validating their strategies at every level
They want to spend more time gathering the quantitative and qualitative data they need in order to deliver more innovation to the market

The right product innovation framework can act as a compass that points product teams towards moving closer to achieving more value for the customer. The right innovation framework can act as a validation tool, and provide a process for gathering the right customer data to inform innovative product decisions.

Ready to start building your own product roadmap? Try our ready-to-use product roadmap template.

What’s the Jobs To Be Done framework?

The idea behind the Jobs to Be Done framework (JTBD for short), was first proposed by Clayton Christensen, a professor at Harvard Business School. It was then quickly adopted by the design and product development worlds. The heart of Christensen’s initial theory is this: your users aren’t just buying products, they’re “hiring” them to get a job done.

Anthony Ulwick, a JTBD evangelist, then took that theory further. He created the Outcome-Driven Innovation Framework so teams can apply JTBD in an actionable, measurable way using a template of steps and processes. He believes that the goal of innovation should be to understand unmet user needs and then come up with solutions that address those needs.

"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 Outcome-Driven Innovation (ODI) process defined by Ulwick in his book is a “rigorous, controlled approach” to building products based on what customers really want and need. In order to identify these opportunities for innovation, he suggests following the following framework of steps:

Start by defining the market and the core functional job to be done
Then, uncover the customer’s needs using a job map with desired outcome statements
Finally, quantify and plot the degree to which a need is underserved or overserved and prioritize the opportunities

After all this research is done into the jobs, needs and desired outcomes your users are trying to fulfill, you can then move onto discovering hidden segments of opportunity for your organization to focus on (classified into over-served, served right and under-served needs), aligning the organization’s existing products with those opportunities (a market strategy) and conceptualizing new products and features to address unmet needs (a product strategy).

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

Here’s how product teams can get start making the switch to adopting a Jobs-to-Be-Done framework when building new products and features.

Define the market and the core functional job to be done

The target market is defined as “a group of people + the job they are trying to get done.” Here are some examples of what this means in practice:

Teachers (group of people) who want to save time on grading papers (core functional job to be done)
HR professionals (group of people) who want to onboard new employees smoothly (core functional job to be done)
Designers (group of people) who want to validate the right prototypes (core functional job to be done)

In this definition, the core functional job to be done is defined as anything (problem, task, goal, objective) the user is trying to accomplish, improve or avoid. Ulwick uses the example of a kettle; the wrong job to be done definition for it would be “to boil water for tea.” The correct core functional job to be done is “to make a hot beverage.”

This distinction is important because it expands the possibilities of what a company can build as a product that address the job to be done (a kettle vs. a multi-functional Keurig machine, for example, that can make different types of hot beverages like tea, hot chocolate, apple cider and coffee).

There are other job categories on top of the core job. The idea is that the more of these categories a solution fulfills, the likelier it is to achieve sustained, long-term success in the market.

Related jobs to be done: these are the functional jobs the user is trying to do along with the core job. So, for example, if the core job is “to support my family”, the related jobs would be “send children to a good school” and “set up a college fund.”
Emotional jobs to be done: these are statements that describe the way users want to feel or be perceived when doing the core job.

Use a job map to uncover desired outcomes

Once the core functional job is defined, it’s time to create a job map that shows the steps the customer carries out to complete the job. A job map—broken down into 8 categorical steps—should depict the goals that users are trying to accomplish in order to fulfill that core job.

—Source: Strategyn

It’s important to note that this is an observation exercise meant to outline the current process that users are undergoing to achieve the core job. It’s not speculative, and it’s not the place for generating new ideas (that step comes at the end).

The job map should be based on real qualitative data gathered from interacting and observing current users of the product. It should be need-focused (sharing a file externally with stakeholders) instead of solution-focused (choosing a png, jpg, html or pdf file and saving it).

A job map isn’t a customer journey. The goal is to deeply understand what the road to success towards achieving the core job to be done looks like. Product teams can then use this job map to generate customer-desired outcome statements. These act as the metrics users use to measure how successful they are towards achieving the core job to be done. Here’s an example of a job map and desired outcome statements using the example of storing and retrieving music:

—Source: JTBD.info

In general, desired outcome statements need to fulfill a few guidelines in order to be useful to product teams devising solutions:

They should state the different ways the users would like to do the core job more efficiently
The ideal number of desired outcome statements that apply to the core functional job should be extensive (between 50 and 150 desired outcomes)
They should follow the standards of a quantitative metric: desired outcome statements must be actionable, manageable, not a solution statement, measurable and independent of time constraints

Discover and prioritize the needs you’ll solve

After identifying that core job to be done and the desired outcome statements, the next step is to identify the needs that your product or feature solve for. The idea here is to classify those desired outcome statements into buckets that can then be prioritized.

This can be done by surveying or interviewing (e.g. by using a Likert Scale) the users whose core jobs to be done were mapped out and asking them to rate and rank how important each desired outcome statement is to them, and whether or not the current solution they have in place to fulfill that is satisfying (and to what degree).

Underserved needs: Very important and very unsatisfied
Overserved needs: Very unimportant and very satisfied
Irrelevant needs: Very unimportant and very unsatisfied
Appropriately served needs: Somewhat important and somewhat satisfied
Table stakes: Very important and very satisfied

—Source: Mike Boysen

The best innovation opportunities can then be found in the outcomes that are most under and overserved.

Looking ahead: The Jobs to Be Done Canvas

The Jobs to Be Done framework leaves no stone unturned in the process towards uncovering the best approach towards product innovation.

Companies like Intercom and Invision have successfully adopted this innovation process to do a few things:

make sure they’re collecting the right insight into why customers use their products
Identify potentially underserved needs based on real core jobs to be done that can then be translated into a real product solution

One of the best ways to get started with this framework (other than by reading Anthony Ulwick's book), is to carry out a Jobs to Be Done workshop with the product team. Before the user interviews, the surveys, the Likert scales, the qualitative measurements and user behaviour observation exercises, teams can get started with a simple Jobs to Be Done canvas exercise:

The goal of filling in the canvas as a team is to achieve an understanding of the Jobs to Be Done framework before it’s put into practice. It helps teams theorize what segment of customers they’ll target, reach a common understanding of what core jobs to be done and desired outcome statements are, and how that information will then be used to inform an innovation strategy.

Use a product innovation roadmap to visualize your plan

Plan how your company will innovate over the upcoming quarters and years—and prepare for risks along the way.

Organizations use innovation roadmaps to map new areas for opportunity, test ideas and keep up with evolving technologies. To remain competitive, companies are required to look forward and discover new business models, product opportunities, and value-added improvements.

Innovation roadmaps are most often built by product managers and executives to align departments on strategic initiatives. They ensure companies achieve disruption—and don’t get disrupted themselves.