Understanding JTBD to Avoid Common Pitfalls
Every day, you have dozens of goals that you strive to accomplish. You drink coffee to get energy in the morning. Then you might drive to a park-and-ride to take the train while you commute to work. At the office, you collaborate with colleagues to complete a project or deliver a pitch to a new client. In the afternoon you might plan long-term financial well-being with an advisor. Back home, you might eat a piece of chocolate to reward yourself after work and then prepare a meal to enjoy with your family.
These are all jobs to be done (JTBD).
The JTBD approach offers a unique lens for viewing the people you serve. Instead of looking at the demographic and psychographic factors of consumption, JTBD focuses on what people seek to achieve in a given circumstance. People don’t “hire” products and services because of the demographic they belong to (e.g., 25–31-years-old, have a college degree, earn a certain salary); they employ solutions to get a job done.
The JTBD theory predicts adoption: people are more likely to pull solutions into their lives that get a job done better, quicker, and more complete. Instead of focusing on your own products, services, and brand, you first have to understand what people want. The job to be done serves as your unit of analysis to make innovation more consistent.
My definition of a job is simple and broad to cover variation in the field:
The process of reaching an objective under given circumstances
The use of the word “objective” is deliberate. It better reflects the functional nature of a job. I don’t use the word “goals” in my definition to avoid associations with broader aspirations, e.g., “life goals.”
My definition of JTBD also includes an explicit mention of a process, highlighting the dynamic nature of getting a job done. In other words, an “objective” isn’t just about an endpoint, rather an objective is a process that unfolds over time.
Note that measures of success for how well a job gets done are handled separately, along with emotional and social aspects. The JTBD approach, then, suggests a sequence: first analyze the functional intent a job performer has: then look at the qualifiers on how the job gets executed in a second phase. See more on the separation of objectives and outcomes below.
It took me a while to really grasp JTBD, so don’t be discouraged if you’re still working it out. The three pitfalls you need to sort out in your mind are: removing all references to technology and solutions, getting the right level of granularity, and separating objectives (tasks, goals) from outcomes (needs, measures of success). Let’s look at each briefly:
1. Remove all references to technology and solutions.
JTBD offers a structured language, with rules of grammar and formulation. The practice explicitly expunges any references to technology, solutions, methods, companies, or brands.
Remember: JTBD is not about you and your product or service. It’s about the objectives people have. To achieve this flip in perspective and remove yourself from the equation, the rules of formulation have a very intentional forcing function.
This sounds easy, but in reality it can be harder than you think. I see it all the time in my workshops: people forget that common things like email or a phone call are solutions. You can mention them. Or, that things like agile and design thinking are methods. It takes practice to remove solutions from your language.
The advantage of being technology-agnostic is longevity. JTBD research enjoys an evergreen lifespan, remaining relevant for years to come. In fact, one of the test questions you can ask yourself when creating job statements is, “how did people accomplish the objective decades ago?” If your statement is valid for past job performers, it will likely be valid in the future as well.
Solutions come and go. Technology has trends and fads that change at increasingly rapid rates. Jobs, on the other hand, are stable and durable over time.
2. Find the right level of altitude.
Before you begin with JTBD you have to answer the question, Where do you want to innovate? There is no right or wrong answer. You can innovate your entire corporate strategy or just focus on solving a very narrowly-defined problem.
The thing to keep in mind is that there is a hierarchy of goals to consider any time you’re dealing with human behavior. I recommend mapping out the hierarchy of jobs to be done before you getting started to define your scope of inquiry. I typically start with these three levels initially:
- Aspirations — These reflect the ultimate, ideal change of state. It’s something the individual desires to become.
- Main job — A broad objective that defines where you’ll innovate. All main jobs reflect a process with a beginning, middle, and end.
- Sub-jobs or job steps — Since every job is a process, you can always break it down into individual steps or sub-jobs that form a sequence of getting the job done.
Navigate the hierarchy by asking “why?” to go up and “how?” to go down. You may find another level or two in this hierarchy, e.g., a grouping of main jobs that you can express as a super-category of sorts. It depends on the domain you’re working in.
For the sake of illustration, let’s say you work for the manufacturer of power tools. To understand the needs of your market, you might want to target a large job that supports amateur handypersons as they fix things around the house, i.e., make home improvements. But you could also scope your field of inquiry to target a much smaller main job such as make a hole in the wall. Innovation can happen at any level, and it’s up to you to determine where you’ll be investigating.
As a rule of thumb, you want to start with a job that you can reasonably affect. I’ve found that if you go up to high in the hierarchy you may target innovations that are out of reach. Consequently, aspirations aren’t good places to start innovation because there are endless ways to fulfill them. This isn’t to say that you ignore aspirations, just that they shouldn’t be the starting point for innovation. Aspirations play a role later when developing and marketing a solution.
3. Separate objectives from outcomes.
Jobs don’t come in neat little packages. Instead, you have to carefully listen to the people you want to serve and translate what they are saying into a regular language. Think of JTBD as a filter with different buckets of information that you distill from in-depth research:
- Job performer (who) The executor of the main job, the ultimate end user.
- Jobs (what) The objective the job performer wants to accomplish.
- Process (how) The procedure of how the job will get done.
- Outcomes (why) The measures of success or intended outcomes from doing the job.
- Circumstances (when/where) The contextual factors that frame job execution.
The job is the functional objective a person has. It’s simply the task they which to complete that can be seen as a process. The desired outcomes are the measure of success or needs that people have while getting the job done. (This is all contextualized by the circumstances or the factors that influence how a job gets done.)
For example, if you’re an amateur archer (job performer), your primary functional objective is to shoot an arrow at a target (main job), which is composed of different steps, e.g., select equipment, form stance, shoot arrow, assess results, adjust aim, etc. (process).
The obvious result you want is to minimize the distance of the arrow from the center of the target (outcome). But there are other outcomes you want too: maximize ability to repeat consistent results or minimize effects of external factors, e.g., wind or increase your ability to select the best equipment.
By separating the objective from the desired outcomes we can better pinpoint unmet needs and find hidden opportunities. So you create two separate lists: one for jobs and job steps (functional objective) and one for desired outcomes (measures of success), and then analyze each separately. It takes practice to get that right but points to hidden opportunities that can ultimately help you outperform the competition.