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)