How To Use Jobs To Be Done Framework: A Guide For Product Managers
The idea of users 'hiring' a product might sound a bit weird at first. This might have even led you to think that the so-called Jobs To Be Done framework is something of an inside joke for product managers.
In reality, though, jobs to be done (also known as jobs-to-be-done, JTBD, or Jobs Theory) is not only something real, but it is also one of the most effective and impactful frameworks that you can use for developing your products.
As a senior product manager with hands-on experience applying the JTBD theory in practice, take it from me: learning how to use this fascinating methodology will completely change how you think about your product.
Principles of Jobs To Be Done Theory
Before looking at the structure of this framework and explaining to you how to use it, let me introduce you to the core ideas and principles behind it in order to help you understand the essence of this framework (instead of just getting you to memorize the steps of implementation.)
Product and management veterans claim that the first “way of thinking” behind JTBD dates back to the 1960s when the famous Harvard Business School professor and marketing scholar Theodore Levitt brought forward the concept of “desired outcomes” and said this famous phrase:
The brilliance of this way of thinking is how you start approaching product development.
Spotify wanted to enter the music industry. However, instead of creating a marketplace where they would sell songs (just like iTunes back then), they realized that what people wanted was to be able to listen to music, not to be able to buy it.
Therefore, they had the freedom to build something fundamentally different (and better) from music stores—a streaming service, which balanced a sustainable business model with their users' desired outcome of listening to music.
Since its origins in the '60s, the approach to prioritizing desired outcomes has developed significantly with many famous management experts and scholars building their own frameworks and “philosophies” upon it.
Some of the most prominent milestones were:
Clayton Christensen’s idea of Disruptive Innovation which he coined in his book "The Innovator's Dilemma." Clayton noted that any world-changing innovation starts by covering the needs of a small group of customers (a.k.a. Early Adopters), then improving the solution to be able to cover the additional needs of larger masses of latecomer users.
The central point of this “start from niche then expand” structure was the founders’ and product managers’ ability to properly identify the needs and the desired outcomes of the niche users, then do the same for the wider audience.
Bob Moesta’s “struggle-first” approach which he described in his book "Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress," Bob argues that customers constantly try to make progress in their lives (be it financial, relationship-related, or anything else) and they face numerous struggles along that path. Great product leaders are able to see these struggles and offer products that the users can “hire” to handle these struggles for them.
Tony Ulwick’s Outcome-driven Innovation (ODI) framework (here’s a good Harvard Business Review piece on it). According to Tony, the ultimate factor that drives the decision-making process in the heads of customers are the eventual outcomes that they want to achieve by using your product.
The idea is that, when there is a choice between multiple competitor products, customers will end up with the one that is best able to help them reach their desired outcomes.
How Does JTBD Work?
With all of these ideas and frameworks in our minds, we finally arrive at JTBD. There are several interpretations of the JTBD theory (all of them are quite good), but I personally prefer Tony’s version that he describes in his book “Jobs to be Done: Theory to Practice.”
According to him, customers will need to perform a “job” that will allow them to reach their desired outcome. They can do this job by using various paths and solutions, including “hiring” products that can handle the job for them.
If we visualize this concept, this is what it looks like:
The starting point for your customers is the non-ideal current state that is not satisfying them. For instance, for a work-from-home customer support agent, this current state is her living room where she usually does their work as her apartment does not have a dedicated home office.
Why is it a non-ideal current state? Well, because of all the background noise she gets from her dog, kids, and neighbors, she worries she might sound unprofessional during her support calls with her customers.
So, she has the desired outcome of having noise-free support calls.
To get this done, she needs to change her current status and make progress toward her desired outcome by decreasing her background noise. This is a job that she needs to accomplish.
One of the ways is to keep everyone out of the living room—but this is a tall order for a full workday in a small apartment. Another way is to move out of her apartment and into one that has a soundproof home office space—but that's labor-intensive, stressful, and comes with a lot of long-term costs. Finally, there is the option of hiring noise cancellation software to remove all of the noise in real time.
Considering the cost of the alternative solutions, she would be more than happy to pay a dozen bucks a month for this kind of service!
Thus, the noise cancellation software has successfully completed her job of removing background noises from her calls and helped her reach the desired outcome of taking distraction-free calls.
The Laws of JTBD
In his definition of the JTBD framework on his consultancy website Strategyn, Tony is bringing up a couple of interesting “facts” about these jobs that can help us further understand the essence of JTBD.
- A job will remain the same as time passes. People would hire minute takers in the past to take notes for them during the meeting. Now, they hire AI summarization tools instead. Different solutions, same job.
- Jobs are “solution-agnostic.” This means that customers can hire different types of solutions to handle the same job. It also means that your product does not have to look similar to what your competitors offer to be able to do the job well.
- The best solution always gets the job. If there is competition, the winner is the product that handles the job better, faster, or cheaper (or any combination of these three).
- People want a single solution for a single job. Customers prefer products that are able to cover the entire job end-to-end and will avoid cases when handling the job requires hiring several products.
To sum up, the Jobs To Be Done framework relies on the idea that what people really want is the eventual outcomes instead of the tools they use for it.
They do, however, care about the process. In order to help them reach their end goals, they need to complete certain tasks (or jobs) and they are ready to hire someone or something (a service or software) to handle these jobs for them.
By identifying these jobs and tailoring your products to handling them seamlessly, you are increasing the chances that people will pay for your product and use it continuously.
How To Use JTBD Framework In Your Day-To-Day Product Development
Hopefully it's clear how important it is for you to understand the essence of the JTBD framework before learning how to use it, as the following steps make a lot more sense in context.
What I'm about to share with you is not the “vanilla” version of JTBD (which you can read about it in the many books mentioned above).
Instead, I want to share the variant of JTBD that I have successfully used in real life for some of my products.
Here’s a Jobs to Be Done example from my own professional experience.
Learning About the Customer Needs and Desired Outcomes
The heart of every successful product is well-executed user research. Considering just how reliant JTBD is on the notion of “people want outcomes, not tools,” you should always start by identifying your users and learning about what they want.
I do not have a specific “JTBD-tailored” way of doing this research. Instead, my product team and I have relied on our traditional ways and tools for learning about users. The only difference was that we focused our questions on discovering the eventual outcome that our users wanted to get.
Let me share an example from the web push notifications service we worked on.
Note: This tool lets websites send push notifications to their visitors. It was a new lucrative marketing channel that websites could use to promote their products.
In order to develop the user personas for this service, we would interview the people who have used the products of our direct and indirect competitors. When interviewing a competitor’s user, you would traditionally ask questions like this:
Although we did ask these questions during our interviews, too, our main focus was to get answers to these:
And there was a good reason we were interviewing both direct (e.g. OneSignal and iZooto) and indirect (e.g. Mailchimp and Twilio) competitors. We mentioned earlier that jobs and desired outcomes are solution-agnostic. It meant that the answers we would get about the outcome would be the same (or at least similar) no matter which tool our interviewees used.
That’s exactly what we got. Apparently, the most common desired outcome for our target market (which was eCommerce shops at that moment) was to decrease the number of so-called “abandoned carts”—when people add products to their shopping cart and leave them there for days or weeks.
The job that both email and web push notification services were doing for them was to remind users about the abandoned cart and offer a discount if they came back and made the purchase.
This is what we eventually decided to focus on, and we built a product that could do it better than anyone else.
The example I brought up above was about user interviews, but it is not the only way that you can discover what your customers want. You can also consider doing:
- Market research along with determining different customer segments and demographics.
- User surveys which you can conduct using our curated list of survey questions.
- Focus group interviews, in which you are inviting a select group of people to discuss their needs and experiences with you.
But no matter which type of customer discovery you are doing, always remember to prioritize the questions that uncover the eventual outcomes that your customers want to get.
Formulating the Job Statement
As a result of all the learnings you have gathered from our interviews and surveys, you should have a pretty good understanding of both the outcomes that your users want and the tasks that they usually perform to reach them.
Now, it is time to materialize these learnings by formulating the main deliverable to the JTBD methodology—a job statement. Here is what it looks like:
This format for describing the outcomes and jobs like this is quite useful as it contains crucial information such as:
- The situation and the environment where the customer is experiencing a problem. In our case, it was people abandoning their shopping carts.
- The job that our customer needs to perform to reach the desired outcome. For eCommerce owners, it was about sending reminder messages to those who had abandoned their carts.
- The emotional and rational reason behind the customer’s desire to get to the outcome. If people add products to their carts and forget about it, this is lost potential revenue for our customers and they have a rational reason to reduce these cases.
- Finally, we have the desired outcome. In this example, shop owners wanted to get rid of these abandoned carts.
You may have noticed we used the term “reminder messages” instead of “reminder emails” for push notifications. The reason is that our customers did not really care about the physical channel for sending this message as long as it successfully decreased the abandonment rate.
Creating a Job Map
Documentation of many of your customer’s job-to-be-done and outcome statements is an achievement in its own right. But it’s only half the battle, as you will need to convert these jobs into a decent value proposition, new product requirements (including a roadmap), and user experience.
For this, we can take advantage of another JTBD deliverable—the job map.
The job map is the visual representation of the entire journey that your customers need to go through in order to successfully complete their job. It serves as an intermediary step between your job statements and the customer journey map or product requirements that you will hand over to your engineering team.
Here’s an example template of a job map developed by GitLab.
The structure above is the brainchild of Tony Ulwich who proposed using it for mapping jobs in his Outcome-driven innovation framework.
Now, let me fill this in for you with the example of Spotify and the job of “Customer creating a custom playlist for their specific mood.”
- Define: Users understand that they need to have a personalized playlist based on their mood.
- Locate: They find the playlist creation feature and navigate there.
- Prepare: Users search for and select the songs that they want to add to the playlist.
- Confirm: They review the playlist to make sure that they have all the songs they wanted for their mood.
- Execute: Users save the playlist and give it a name.
- Monitor: They look at metrics such as the number of streams and likes to evaluate the popularity of their playlist.
- Modify: Users incorporate the feedback of others into their playlists by adding or removing songs.
- Conclude: When they experience the mood this playlist was made for, users turn it on and enjoy the music.
Depending on the job that you want to map, you might consider omitting some of the steps here if you feel like there is no proper action that users need to do for that step.
Creating a Solution That People Will Hire for that Job
Finally, we have reached the point where you can create your regular product management deliverables such as PRDs, designs, user stories, and more by using your day-to-day product management tools.
You already have the list of steps that your users take to cover their unmet needs, so all you need to do is create features that cover the necessary actions that users take for each step.
For the “prepare” step of the specific job above, for instance, you will need to develop a feature letting your users search for songs, filter the playlists of other users, as well as input these songs to your own playlist.
Apart from developing features that cover your jobs, do not forget about the more “administrative” ones too, like your pricing and payment logic, your customer experience in terms of managing their data and account, and their ability to access support.
It’s All About Making Your Product “Hireable”
Jobs To Be Done is an exceptional framework and way of thinking as it helps you focus your efforts on features that will make your product more attractive to users who want to hire you to handle their jobs for them.
No matter if you are in a startup, or a tech giant (like Intercom or Microsoft), I assure you that JTBD will help you increase the impact of your product management work. If you enjoyed reading my thoughts about JTBD, then make sure to subscribe to our newsletter to get similar content into your inbox.