​One Executive’s Perspective on the ‘Jobs-to-be-Done’ Innovation Approach


I recently had an opportunity to interview Jeff Baker, head of customer insights, category management and strategy at Valvoline, and a former client of mine (Microsoft and NetJets).

There are very few executives in the country who have the depth of experience with the job-to-be-done (JTBD) innovation approach as Baker. He has completed over 100 JTBD projects in the past 15 years through various roles at Microsoft, Strategyn, NetJets, and now Valvoline. I asked him to share his perceptions of the approach.

But first…

A quick overview of the JTBD innovation approach

The jobs-to-be-done innovation approach is a highly effective method for discovering customers’ unmet needs in a form that is ideal for driving innovation and growth. It’s based on the insight that people “hire” products and services to get jobs done.

When we have a job to get done, we look around for a product or service to hire to do the job. A job is a task, objective or goal to be accomplished, or a problem to be prevented or resolved. Jobs explain why people make the choices they do and thereby make it possible to turn innovation into a predictable business process.

Q: If the JTBD approach is the solution, what’s the problem that it is solving?

Baker: Three things come to mind. First, companies are not short on ideas; they’re short on mechanisms for prioritizing which ideas are most likely to be good ideas, most likely to have value in the market place and lead to revenue growth, or whatever the objective is. The JTBD approach enables companies to prioritize those ideas and determine which are likely to be truly valuable to customers.

Another thing that I really love about this approach is that it provides a new way for segmenting markets. Traditionally, the segmentation variables are the easily accessible and obvious stuff — demographic, psychographic, things like that — and while those groups end up being very accessible, they are not very meaningful.

In most cases, it makes sense to use the customers’ unmet needs (jobs) as the core of your segmentation and then expand out in concentric circles from there around other key profile variables that make those segments reachable by marketing and sales. That is, don’t use reachability as the goal or how you define the segment because even though such segments are easy to reach, you’re not saying anything meaningful to customers when you reach them.

And last, but equally important, JTBD solves a resource-allocation problem by helping leaders figure out what to stop doing — when to get people off projects that are less likely to have value in the marketplace.

A good example of “what not to do” occurred back in my Microsoft days. The Visio Group, one of the business units, had a very successful niche product for people who need diagramming. They were considering building a simplified version of the product for a more general business user who had occasional needs for the same type of diagramming and visualization.

They were headed down the path of building it, so we did a JTBD project with the target audience and the business users came back loud and clear saying, “We have no interest in this product.”

It turned out that, given how infrequently these general business users need to use diagramming and visualization, they were much more likely to hand off the task to someone else to do it with the current product rather than learn how do it themselves with a new product.

This totally changed the group’s thinking and they abandoned the whole idea, which saved them 18 to 24 months of development costs building the product as well as millions of dollars they would have spent promoting it trying to get people to adopt it when, in all likelihood, it would have all been for naught. Without the JTBD research, this could have been a $50 million mistake.

Q: What makes the JTBD approach different and better than other innovation approaches?

Baker: Two things jump out at me. The first one is the solutions-agnostic foundation of the whole approach. That is, you can discover a set of any target customers’ needs (their jobs to be done) regardless of the product solutions they use. That’s what makes the approach so different and flexible. You can apply it anywhere, and that’s something really unique.

The other thing is that it incorporates customer needs that are normally treated separately by different business functions. For example, it enables you to use the same exact approach for product development by uncovering customers’ functional jobs that the marketing team uses to uncover emotional and social jobs to craft messaging and positioning and brand image.

It’s all based on the same framework, and I find that to be incredibly powerful because it really helps people to understand when you see the emotional and social job opportunities side by side with the functional jobs, it really reinforces a lot of nuance that sometimes gets lost in the product development process itself where the engineers or the developers typically focus on the product function alone.

And the customer experience people love these emotional and social jobs because it really gives them an anchor for how to architect the experience around the core functionality. So, it leads to a much more sophisticated product in my opinion.

And, equally powerful, because the three different kinds of jobs — functional, emotional and social — are integrated into one framework, it actually ties the two business functions together better. It ensures that the marketers are trying to pay off on the same emotional jobs that the engineers are building for in the product. It has a funny way of uniting disparate functions that don’t always work that closely together, and I’ve found that this leads to much better business results.

At Microsoft, the market research function and the user experience function were practically on different planets, and until we came up with one methodology that linked the two disciplines together, we essentially had two different groups fighting for the attention of the development team that had to figure out who they were going to listen to. That was essentially the dynamic.

The JTBD approach also gave the user experience people an anchor from which to do their work. It enabled us to do a lot of work where the UX team would go do observational research, ethnography, stuff like that, with an understanding of the type of needs they should be looking for, as opposed to just going out and observing everything, which runs the risk of “boiling the ocean.”

So, informing the UX team about what type of customer “needs” to uncover made their field work much more targeted and efficient.

Next time, we’ll look at Baker’s thoughts on using the JTBD approach in his current role.

(This article initially appeared in The Business Journals, August 4th, 2017)