Jobs to be done: A useful framework for driving customer value

By Hugh North (opens in new tab), Carolyn Bufford Funk, Ph.D. (opens in new tab), and Veronika Sipeeva (opens in new tab)

Image credit: iStock

“Customers will always surprise you with the creative ways they use your product. They don’t do it deliberately – they’re just adapting your product to their needs.” Des Traynor, Intercom on Jobs-to-be-Done,” 2017 

“Why would the customer buy our product or service?” is a question that guides nearly any value prop discussion. But if we put this into the customer perspective, what the company needs to understand is what people are trying to get done, what problems they are trying to solve, and what successfully solving these problems really means.  

As researchers we’re well-equipped to answer these questions using different approaches and frameworks, including the Jobs-to-be-Done (JBTD) framework that is gaining more and more traction among our research community. If you have been following the Jobs-to-be-Done discussions, you probably already heard of the milkshake story (opens in new tab), where Harvard Business School professor Clayton Christensen and his team were working with a fast-food restaurant chain to improve the sales of their milkshakes. If you’re new to the JBTD, you may be taken aback by different approaches to defining a job and different schools of thought, and Jim Kalbach’s “The Jobs to be Done playbook” (opens in new tab) can be a great resource to guide you through your exploration.  

Note: A framework is just that – a framework. It is designed to help you describe what is happening in a simplified way. As with any framework, you’ll need to define what you’re trying to get done and how you want to use it. 

What these jobs are 

Here, we’ll use Jim Kalbach’s definition of a job as “the process of reaching objectives under given circumstances”, where he deliberately chooses the word “objective.” A quick search on the difference between the goal and the objective gets us to an editorial article on Indeed.com (opens in new tab), where “Goals are the outcomes you intend to achieve, whereas objectives are the specific actions and measurable steps that you need to take to achieve a goal.” Sounds easy, right? Often, one of the hardest parts in the framework is defining the right level of abstraction or altitude for your job. Jobs vary in size, from micro-jobs like “writing a letter” to bigger jobs like “taking care of a family member who is far away.” A good example of how the jobs might stack might be a situation when your dog unexpectedly chews on the pair of your hiking boots. 

You will need to decide for yourself which level is the most useful to choose for your project. We found that if you’re thinking big and long-term it might be helpful to focus on the bigger jobs and aspirations. But if your goal is to make improvements to the existing product or service, focusing on big and smaller jobs, defining what success looks like for these jobs from the customer viewpoint is a helpful approach.  In this example, you need to find a pair of hiking boots because you want to go on a hike. There might be many reasons why you want to do so: Maybe you just want to get outside and get some fresh air, maybe you want to get some exercise and you aspire to be a healthy person. You notice how by asking ‘Why’ you can move up and by asking ‘How’ you can move down – a useful tip from The Jobs to be Done Playbook by Jim Kalbach. 

You would also notice that all the jobs above, even the micro-ones, are tool agnostic. Because of this, the competition is not just what you are building, but everything else out there — even non-technological or non-intelligent solutions. A good example of this might be note-taking: People have many options for this job, from sticky notes or a sheet of paper to dictating a message to themselves, or sending themselves an email, and they could choose from a whole host of applications. What makes the most sense and is easiest in the moment will often influence the choice of tool or tools. 

In our experience, it is very rare to be building a technology solution for a user job that does not have a pre-existing solution in some form – a critical concept in successfully using jobs to be done in product design is to recognize your solution is always occurring in a competitive landscape. Research-backed innovative design of a solution that helps users is never enough. Your solution needs to be better than all other available options, and those options are not limited to the same frame as you are working in (like software).

Extending our example of note-taking, we’ll see that our text-focused applications (like Microsoft Word or Notepad) are, for example, in daily competition with each other, pen and notepads, post-its, Microsoft Excel (often used to record lists and other note-like text or to-dos!), and decorative leather-bound journals as well as technology solutions built by our software and service competitors. Now imagine going one level up, thinking about why someone is taking notes. Maybe they want to keep track of the project they are working on. In that case, your solution is going to compete not just with note-taking tools per se but also in the project-management space.  

The context of the job 

People tend to shift between various physical, emotional, and social contexts. If you take our hiking boots example, different emotional contexts come to mind: You may want to go on a hike to “find solitude” or you might be “meeting with friends.” Maybe you are someone who wants to be seen as fashionable, and how you look on a hike is important for you.  

The context, circumstances or, per Stephen Wunker, “job drivers,”  (opens in new tab)are essential to the Jobs-to-be-Done framework, especially when you’re thinking about segmentation or are working on products that span multiple contexts. 

We also know, from research that we and our colleagues have done, that people shift frequently between applications and identities during a typical day. As they do, they use many different apps (both free and paid), devices, and endpoints – across ecosystems – for both work and personal use. We saw this with high-intensity users (opens in new tab), and similar patterns have been observed with very small business owners (opens in new tab) as well. 

Context can significantly impact how successful your solution is – the optimal solutions take into consideration a user’s context and how those contexts change. In addition, designers and researchers should consider how the context of their solution or product will change over time. Since jobs to be done are almost always competitive with some other option, novel or new applications or features have headwinds at launch their known, successful competitors don’t have.  To ‘win’ attention and share, new solutions for a user job often need to be significantly better than alternatives to overcome the challenges users experience in discovering and successfully using the new solution. The products you will be competing with go beyond your list of direct competitors, so your solution needs to be better at supporting what the customer is trying to get done. That might include eliminating the micro-jobs and making it easier for the customer to achieve the bigger objectives. 

Note: We know that the discussions on JBTD often lack the descriptions of research methodologies. In this post, we haven’t touched on how to design your qualitative and quantitative research in order to get to your job statements. That is a topic for another discussion.

How to track if users are achieving their JTBD 

As with any framework, it is important to track whether Jobs to be Done is delivering on its promise. Usability would be the most direct test of JTBD success, but some additional measures could include:  

• Usage and engagement – with fully supported JTBD, people would experience fewer pain points and would make better use of existing functions.  
• App perception and experience – when people can solve their JTBD, they would be more satisfied with the solution and perhaps more likely to recommend it. They should also need to refer to help documentation or contact customer support less often, and should make fewer requests for help learning the app. 
• User emotions – when people can quickly and easily complete their JTBD, they would report more positive emotions and fewer negative ones. 

These signals can be used in multiple ways. They can be used to benchmark improvement in JTBD success, when measured before and after a design change intended to improve how frequently people achieve their JTBD. Some can be used competitively, to compare your solution against competing solutions (remember that these can include non-technical options).  

How JTBD improves our products

Focusing on JTBD rather than applications (or what we want users to do within an application) gets to the heart of how people are using tools to achieve their day-to-day objectives and long-term aspirations.  

Good tools should facilitate, not prevent, what the customer is trying to achieve. Good tools should also work across different versions of the app, in bright and low light, no matter how focused or distracted you are, etc. Applying a JTBD framework helps you to improve the quality, usability, value and even the ‘wow’ factor of the products we make.  

What do you think? Does this help clarify JTBD methodology? What thoughts would you add? Tweet us your thoughts @MicrosoftRI (opens in new tab) or follow us on Facebook (opens in new tab) and join the conversation.