Using the Jobs To Be Done Framework for Product Management

Out of ideas? Employing the Jobs to Be Done Framework (JTBD) for Product Management can inspire your team and help you reach goals. Understand and deploy the JTBD system today!

No product management method is universally going to get you out of trouble. The most popular frameworks, like agile, are more about the general approach your office takes. Team structure, work patterns, timing, tool deployment… They are holistic in the way they seek to address your overall operations.

The Jobs To Be Done Framework (JTBD, for short) is different.

Ever wondered what your customer is thinking? Well, of course! User knowledge is one of the pillars of product management (along with market and technical acumen), so you should really have your own way of getting into your users’ minds. JTBD helps you in that process in a surprising way: 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? If anything, we need to add humanity to product, rather than subtract it!

Keep reading and you will understand what JTBD advocates mean by this.

Explaining the Jobs to Be Done Framework

What is business? It might seem like a very broad question, but there is really one right answer. In a market, business implies doing something that turns a profit. Anything else is just a hobby. Thus, the constant need for entrepreneurs is generating a good or service that will be acquired 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, logically, is research. There are countless techniques that prioritize finding out what the customer is really thinking. Interviews, focus groups, surveys, feedback… All of them aim to reflect on past mistakes, build on strengths and reinforce the iteration process.

At the same time, they are sometimes 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 into the user research process? What is more, how can we streamline the whole product development process along with product discovery, process, and growth?

Let’s look at the theory behind the Jobs To Be Done framework. 

The JTBD vision stems from business authors Lance Bettencourt and Anthony W. Ulwick. And it is 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“. What is interesting, however, is breaking these jobs into bits and understand how different tasks are actually business opportunities.

According to these authors, 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. He or she 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 will 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 way 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? It might do 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 roadmaps or user 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.

A brief 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, customers need to open a savings account and have a clear graphic expression of their expenditures. They 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 should 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, go back to your headquarters and 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.

All in all, it is important not to lose sight of the goal, which is removing the assumptions both you and your external stakeholders can 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.

Is it good to apply the Jobs To Be Done framework for Product Management? What is your personal experience? Let us know below!