Jobs 2.0: Troubleshooting the Adoption of Jobs to be Done
When I first started helping companies deploy Jobs to be Done within their organizations, people were largely unfamiliar with the concept. Maybe a few people — likely the project sponsors — had read an article about Jobs or seen the famous milkshake video in which the late Harvard Business School professor Clayton Christensen describes the theory. But not a single company I worked with had a detailed understanding of the theory and a framework for turning the theory into product ideas, service offerings, or business model innovations.
If you fast forward to today, Jobs to be Done is far more widespread. Hiring managers seek applicants who have experience conducting Jobs research. Companies as diverse as Clorox, Home Depot, and Facebook are giving talks on the theory at conferences. The question I get from companies is no longer “What is Jobs to be Done?” but rather “How can we improve the way we’re using Jobs to be Done?” Those who are farthest along in the journey are wondering how they can take the concept to new levels, such as using Jobs to be Done to size markets and compare vastly different ideas. Others, however, have encountered hurdles as their organizations begin using Jobs to be Done for the first time. For those in the latter group, I’ve gathered five of the most common challenges that companies have when they adopt Jobs to be Done, as well as some solutions for avoiding those struggles.
Issue 1: “We say we’re applying Jobs to be Done, but really we’re just paying it lip service.”
At a recent innovation conference, someone who works at a large fast food company explained to me that although her organization uses Jobs language, they simply apply it to problems they want to solve rather than problems articulated by customers. She told me, for example, about a colleague who wanted to work on a job that was essentially “having a burger I can handle easily with one hand coming out of the drive-thru.” An opportunity for innovation, perhaps, but hardly a customer’s job to be done.
This kind of problem occurs for a few reasons. First, organizations that introduce the idea of Jobs to be Done typically do so in a theoretical way, and they often fail to address the other parts of the framework. Having only learned about jobs, people try to force fit other elements such as “pain points” and “success criteria” into the form of a job to be done. Second, because the training is theoretical, it tends to get tied to ideas and pet projects already floating around the organization. Jobs insights need to be derived from real customer research, and the jobs that come out of that research should be solution agnostic.
People who are getting used to Jobs to be Done need to be exposed to it regularly, not just as a one-and-done training. A large tech company that I work with achieved this by orienting the strategies of each of its business units around a small number of jobs. Projects within each business always focus on one of those core jobs. New initiatives are consistently being led by those who have built up some expertise in applying Jobs to be Done, and their work — which uses Jobs terminology correctly — is shared company-wide via short presentations and podcasts to get everyone familiar with using Jobs the right way.
Issue 2: “Our research uncovered too many jobs, and we don’t know how to prioritize dozens or hundreds of jobs to be done.”
Another issue that many companies have shared with me is that their first attempt to roll out Jobs to be Done resulted in the organization uncovering more jobs than they knew what to do with. They interviewed dozens of customers, only to realize that the more interviews they did, the more jobs they uncovered. More importantly, there was nothing to explain which jobs were the most important to the customer, or which jobs the organization should focus on in developing new solutions.
When doing qualitative Jobs to be Done research, it’s important to ask questions that go beyond uncovering jobs. Your discussions need to dig deeper to understand how jobs relate to one another and how particular customers prioritize one job as compared to another. Ultimately, this allows you to build hierarchies of jobs that ladder into a relatively small number of North Star jobs that a team or organization is better equipped to focus on. Those lower-level jobs may be important as you get into the details of new product design, but they’re rarely a good focal point for beginning your ideation and prioritization efforts.
A healthcare organization I once worked with had developed a marketing campaign — based on primary research — around the idea of giving patients adequate attention during office visits. While patients had certainly mentioned the need for attention, it was a lower level job. Other North Star jobs were shared by larger numbers of patients and were more top-of-mind. In particular, one higher-level job was that they wanted to be sure their doctors had the collective expertise necessary to treat complex ailments. Given the organization’s breadth of specialists, focusing on that higher-level job allowed the organization to develop a marketing plan that leveraged one of its biggest assets, create marketing collateral that was more differentiated than broad promises about how its physicians really cared, and craft messaging about something that was far more important to patients.
While asking the right questions in a qualitative research interview is important, there are times when qualitative research may not be enough. Quantitative surveys are a good way to understand which jobs are most important, as well as which ones customers struggle most to get done with the solutions currently available to them. Moreover, quantitative research allows you to segment customers, make determinations about which segments the company is best suited to serve, and identify the jobs that are particularly relevant to the segments you’ll be focusing on.
Issue 3: “I don’t know how Jobs to be Done should fit in with Design Thinking and the other methodologies we use.”
People often ask me how Jobs to be Done differs from Design Thinking. The reason many people ask is that companies have a habit of providing regular trainings without giving much thought to how new skills fit with those that are already being deployed. It’s often unclear whether a particular methodology replaces another or complements it. Employees struggle to figure out the contexts in which they use one tool versus another. The investments in past trainings seem wasted as everyone rushes to use the new tool in every situation they encounter.
One of the most important pieces of advice that I give clients is never to do Jobs to be Done training simply for the sake of learning about a new framework. Jobs to be Done training needs to be tied to real business objectives and real projects that the organization plans on carrying out. That gives me an opportunity to understand what approaches teams are currently taking, where they struggle, and where Jobs to be Done has a place. It lets me guide the teams on when to choose Jobs to be Done, as well as when they already have a good solution in place. It’s not a substitute for Design Thinking, but rather a component of it. The Jobs to be Done framework lets teams understand why customers make the decisions they make, ensuring that you ask the right questions and fully understand the decision-making process. It’s also a common language for discussing customer insights and a prompt for ideation sessions. But it’s simply one piece of the toolkit, and there’s value in determining how it best fits with the other innovation tools and processes that may already be in place.
Issue 4: “We understand Jobs to be Done, but we fall back on our traditional ways of thinking when it comes time for a real project.”
One thing that’s particularly appealing about Jobs to be Done is that it’s easy to understand. While it may be a different way of thinking about challenges, the logic behind it is pretty intuitive. That’s also a challenge. Because people catch on quickly, they don’t spend a lot of time digging into the nuances and understanding how it applies in real situations. Then, when time is short and an idea is needed, people fall back on their typical ways of gathering insights and innovating.
For market researchers, I encourage those getting used to Jobs to be Done to color-code their discussion guides. By matching each question to an element of the Jobs to be Done framework, you can ensure that you’re covering all the important elements of how customers make decisions. This also safeguards against scope creep, making sure you’re not asking questions that aren’t tied to your project’s research objectives.
On the innovation side, ideation sessions need structure. Rather than just generating ideas that respond to a problem or sound like they’d be good, it’s important to keep the focus on the jobs that are being addressed. I make teams identify the job to be done that their idea responds to, and I also force them to think about the customer types the idea is targeted at and the success criteria that those customers use to determine whether they’re getting the job done.
Issue 5: “We understand our customers’ jobs, but we don’t know how to translate insights into products.”
Companies don’t generally do research for the sake of doing research. Not successful ones anyway. While there are a lot of best practices out there on customer-centric product development, I’ll focus on three lessons that address areas where I often see companies get it wrong. First, I encourage teams to do a diagnostic to determine how their existing products and their competitors’ products address the Jobs to be Done they’ve uncovered with their research. This does two things. It highlights where there may be gaps in the market, based on the customer’s perspective. It also forces people to start thinking about how features relate to jobs, hopefully minimizing the temptation to simply mimic or upgrade features they’re already familiar with.
Second, I urge those responsible for innovation to get early buy-in from those who will be responsible for commercialization. That may be a Product team or a particular business unit. A senior leader at a large financial services company once shared a story with me about how its innovation team had invested hundreds of thousands of dollars and months of work in generating a truly customer-centric solution only to find out that it wasn’t going to be a priority for the business that would have to sell the solution.
Third, teams often benefit from frameworks and templates that ensure they’re covering all the key elements of product development. The Jobs Atlas I use, for example, ensures that I think not just about customers’ jobs, but also about how customers view the competition and what obstacles will stand in the way of them adopting and using new solutions. Further, Jobs to be Done helps you understand the desirability component of a new solution. Other resources may still be necessary for thinking about whether it’s feasible for the company to offer a new solution and whether there’s a financially viable business model that supports the solution.
Jobs to be Done is a valuable tool for ensuring that innovation responds to the needs of your customers. While it’s an easy concept to understand, it can take some time to make sure your organization is using it correctly. Hopefully, the struggles of early adopters provide some guidance on how others can ensure they’re getting the best experience. And if you have encountered other difficulties in adopting Jobs to be Done, I’d love to hear about them.
Dave Farber is a strategy and innovation consultant at New Markets Advisors. He helps companies understand customer needs, build innovation capabilities, and develop plans for growth. He is a co-author of the award-winning book Jobs to be Done: A Roadmap for Customer-Centered Innovation.
