Using the Jobs To Be Done Framework for Product Management
Translate user actions into user needs
Hi there, Product People. Carlos here with another edition of All Things Product Management. Behind every user action there’s a need, and for every need there’s a solution. The Jobs To Be Done framework helps us see behind the actions and get to the root of the need.
PS - Starting next week I’ll start sending these newsletters on a weekly basis instead of biweekly. What do you think? Leave a comment below and I’ll take it into consideration!
User knowledge is one of the pillars of Product Management, and Jobs To Be Done Framework (JTBD) helps you get inside your user's head in a surprising way: by getting rid of people.
Wait. Is that right? How is removing the human factor from the equation going to help me understand my users any better? Keep reading to understand what JTBD advocates mean by this.
Explaining the Jobs to Be Done Framework
What is business? This is a broad question with many interpretations, think pieces, and webinars dedicated to answering it. But fundamentally, business implies doing something in a market that turns a profit. Anything else is just a hobby. Thus, there is constant pressure on business people to generate a good or service that users will purchase at a price higher than its production costs.
One of the ways this is done is by aligning development with user needs. One of the most important phases, therefore, is research. There are many user research techniques, from interviews, focus groups, surveys, feedback… All of them aim to collect data, reflect on past mistakes, build on strengths, and reiterate.
At the same time, they can be plagued by assumptions: you need to have a preconceived understanding of your destination before drafting your survey, building your focus group script or conducting a phone call. How can we limit these personal inputs in the user research process? And how can we streamline the whole Product Development process along with Product Discovery, process, and growth?
That's where the Jobs To Be Done framework comes in.
The JTBD comes from business authors Lance Bettencourt and Anthony W. Ulwick, and it's very simple. First, we must assume the principle that customers pick goods and services to complete a certain task (from filling their paperwork to delivering their shopping). These are the "jobs to be done." The interesting part is breaking these jobs into bits and understand how different tasks are actually business opportunities.
The main aim is to go beyond what customers are doing to focus on their actual goals. For instance, someone purchasing sports equipment at a specialized shop is not simply purchasing this equipment. They might actually be embarking on a complete fitness program, seeking to change their behavior around other areas like the food they eat, the kind of relationships they lead, or the approach they take to dealing with difficult situations. Would this provide an opportunity to pivot into the market for healthy drinks or lifestyle coaching?
We must map these interactions and act accordingly; but the most important factor is to switch the vision from the customer to the actual task they are undertaking.
Thus, JTBD is already opening a lot of possibilities. The method works because, following Bettencourt and Ulwick, all jobs have three common features:
They can be broken up into steps. Jobs are processes and therefore their execution is divided by milestones. Any research on a targeted opportunity must begin by mapping out these different steps. This allows for value propositions down the line: the more precise these steps are, the better.
They share the same structure. Across sectors and technologies, all jobs have similar patterns. It is at any of these points where your application can be a useful service to your customer:
Establishing job requirements.
Uncovering necessary inputs.
Getting features and production environments ready.
Confirming they are set and fit to launch.
Fulfilling the task.
Supervising its execution.
Adapting the application to unexpected events.
Finishing the task.
Jobs are not the same as “solutions.” At the moment, your product might be offering a very clear approach towards fulfilling a particular need: a solution. However, this tried-and-tested application might age rapidly. If you keep an open mind, you'll realize that your functionalities are used for different things, or that your current framework could go really big with a small addition. On top of these, there are many ways of reaching the same goal, and you can take advantage of that for your next release. This is because you will understand that your customers are seeking to complete a task, not “solve the problem” you are laying out for them.
Simple, but complex, right? The following scenario will help the theory seem way more practical.
Picture a SaaS company that provides certain CRM tools that allow for efficient scheduling of calls with the sales team. Now, the B2B customers who hire these services eventually realize that can also use the nifty and detailed sheets to store and act on customer feedback. In fact, there is a growing body of relevant information online which explains how to employ this SaaS for many other different things.
If the SaaS company keeps doing what they do really well (facilitating communication through the marketing funnel), it is likely they will stay in business. However, if they really aim to grow dramatically, familiarity with the JTBD framework would allow them to understand how customers are actually completing a wider “job” with their software. That is, a section of their customer base is going beyond what they are providing and re-purposing their tools for additional tasks.
This is exactly where the pivot for enlarging operation lies. Of course, one needs to develop solid research, mapping, and execution process to unlock the possibilities. However, just by switching the mindset JTBD can increase returns or at least facilitate innovation processes within any firm.
Product Management and the JTBD Framework
Now, for PMs, there are many practical ways of using the Jobs To Be Done framework for Product Management. As stated above, you must go beyond the superficial to improve your Product practice.
The first lesson you should apply is to forget about “personas”. Yes, of course, building user personas is one of the most common PM tasks. Your internal stakeholders (from engineers to marketers) demand that you understand your potential customers better than they do themselves.
However, what you are seeking here is to clarify the goals users seek to accomplish with your product. Thus, the story built with JTBD is way different. Rather than starting with the “I am…”; focus on the “I want to…” and “So I can…” Why? Well, does it really matter who this user is? Maybe at later stages, but at this point, you are aiming to align functionalities with market potential. So really the most important factors are the user’s immediate need (the task they want to complete), and their long-term goal towards which they are traveling (the job).
Once you have defined both task and goal, this is where the fun begins. You can employ a digital whiteboard or a physical one; the important thing is to portray graphically the many intersections these two factors bring. If you are familiar with drafting customer journeys, this step should not be difficult.
What we are trying to flesh out here is the many ways in which you can satisfy your potential market with your current or future product. A PM is always on the lookout for new features or iterations: this involves examining the competition or attending industry conferences, for example. However, the benefit of this approach is that you are likely to discover unexplored waters before your rivals.
For example: Spotify’s task was fulfilled by many other music sites: playing your music, organized by artists and genres. However, the particular job that the Swedish success sought to complete was having universal, free and simple access to virtually any piece of relevant music ever generated. iTunes, on the one hand, was focused on obtaining profitability by translating the physical distribution and sales model onto the digital world; including the paywall. On the other hand, piracy sites offered all these for free but with very poor interfaces and high technical barriers of entry.
Under the JBTD framework, on-demand music services could have realized that their users’ goal was not to “buy” music.” In the old times, yes, it was nice to own your own collection. Today, however, most people would rather “rent” access to music, offering in exchange their time to advertisers or a subscription fee.
There are several ways you can conduct this mapping. One suggestion is to start with a general aim for your customer (e.g. having breakfast, saving money), unpack it and distribute it among categories. To save money, it's not just about opening a savings account and have a clear graphic expression of their expenditures. Customers also need to switch their lifestyle. The first components involve functions; the second components deal with behaviors. Your diagram will begin to grow as you add more and distribute them among these and other useful categories (when is the task performed, which features does it involve, etc.).
Soon, opportunities will begin to emerge. You will notice that either you or your competition offer solutions with better value than others. You will start to see gaps in your operations: these are the opportunities. You can assemble an expert team with market acumen to develop criteria and discriminate between the different opportunities: which ones are feasible? Out of the possibilities, which ones have the most efficient cost and profit relation?
Make sure that you have proper metrics: rely on your intuition, but trust your data even more!
Never lose sight of your guiding light: achieving an outcome. Your customer is seeking to fulfill a want and will employ any interchangeable strategy to do so. You can list those that seem accomplished; and those that do not. Of course, at this point, your work can be supplemented with interviews. Make sure that you insist on the right questions: turning back on the JTBD method could set you back.
Then start aligning your roadmaps with these conclusions. It is not so difficult to structure your work around the JTBD framework, because it is meant to provide directionality in motion. So, as you move forward in your development, you should constantly update your assumptions and ensure that you are aware of the expanding options that the “jobs” perspective provides.
JTBD: A Useful Addition to the Product Management Toolbox
In short, what the Jobs To Be Done framework proposes is to change your development starting point. By looking at desired outcomes from users, it can help you understand which tangential functions can make you grow. Maybe a group of users is already applying your features to a particularly attractive business opportunity. Follow their “job” path!
Another benefit of JTBD methodologies is their sustainability. By making you aware of the interconnections between past, present and future solutions, it forces you to plan for the long-term. Your products become more modular, in preparation for the expected adaptations that the present iteration will require.
The main benefit is removing the assumptions both you and your external stakeholders have about your current operations. Rather, as with the best business approaches, the framework keeps you open to future innovations and encourages you to encounter opportunities in unexpected corners.
Check out some of the previous issues:
11 Must-Read Product Management Books