Actionable jobs to be done framework for business analysts

In today's dynamic business environment, understanding and meeting customer needs is more critical than ever. The framework called 'Jobs to Be Done' (JTBD), first coined in the early 1990’s by Anthony Ulwick and popularized by Clayton Christensen in early 2000’s, has increasingly dominated product management and software development. You can even see how the term has been gaining popularity over the last 2 decades with Google's trend search:

And yet, true potential of JTBD framework remains largely misunderstood and misapplied. There is no shortage of articles and courses on the subject, and a lot of product managers and business analysts want to and attempt to utilize it. But in reality the adoption of the JTBD framework is mostly superficial at best.

In this article, I want to introduce you to a 3-level hierarchical analysis approach to jobs to be done I’ve been cultivating for a couple of years. It has given clarity to our product management, allowing us to form a single reference point of communication with sales, marketing and customer success. Most importantly however, it is this approach that has driven Elements.cloud’s streak of innovation in the change intelligence space.

Jobs to be done in a nutshell

In essence, a job to be done is a functional, social, and/or emotional objective a given type of customer aims to achieve in a specific context, guiding their choices and actions. It's not a task or a solution, in fact a good JTBD statement should be solution agnostic! A JTBD statement should capture the outcome the customer has in mind. For instance:

• Functional JTBD: "As a remote worker in a different timezone from my team, I need to coordinate my working hours and tasks effectively to ensure productivity and communication."
• Social JTBD: "As a new parent attending a parenting support group, I need to share experiences and gain advice to feel more confident and connected in my parenting journey."
• Emotional JTBD: "As a teenager dealing with academic stress, I need to engage in relaxing activities that allow me to express my emotions creatively and provide an escape from study pressures."

A widely known quote by Ted Levitt states:

People don't want a quarter-inch drill [solution], they want a quarter-inch hole [outcome].

But I never quite liked it. The outcome in the quote is too close to the solution (how else are you going to get a quarter-inch hole?!). A more modern revision of the original quote captures, in my view, the true essence of JTBD:

People don't want a quarter-inch drill [solution], they want to hang a picture on the wall [outcome].

The power of context in JTBD

'I want to go enjoy a cinematic experience' may sound like a clear JTBD, but is it? That is how most job to be done examples on the internet sound like. There are a ton of online Coursea courses out there that give following examples of JTBD:

• Get my clothes clean and fresh
• Nourish my body
• Find my documents easily

These are NOT JTBD statements. Contrast the 'I want to go enjoy a cinematic experience'  with following 2 statements:

• I want to enjoy a romantic date with my wife at the movies
• We want to have an enjoyable family experience with our kids at the movies

The context of when and who performs a job to be done has a direct impact on how it gets executed and what is and isn't in its scope. What movie is chosen, what snacks and beverages are bought, what day and time is selected, even what seats you sit in - EVERYTHING would be different between those 2 situations. 

Jobs to be done do not exist in isolation

Another obstacle in fully leveraging JTBD framework is understanding the lifecycle and interplay between many different Jobs to be done. Let's take an example of a platform like Salesforce, built to support '360 view of the customer' from the perspective of marketing, sales, and customer success teams. There is no single JTBD for each department or employee. Instead, there are many different Jobs to be done, that need to happen is particular order or sequence. Let's take a few examples:

• As a marketing manager, when dealing with a lot of leads,  I want to be able to prioritize them based on their engagement, so I can focus on the ones most likely to convert.
• As a sales rep, when I am on the sales call, I want to be able to access key information about the prospect on-the-go, so that I can make well-informed, tailored pitches to the prospect.
• As a customer success manager, when dealing with accounts I helped close, I want to be reminded when to follow-up with them and check their progress, so that I can continue nurturing the relationship and make sure they renew.

It is no coincidence that I prefer to capture Jobs to be done in a user job story format. In my view, this encapsulates the full context of the Job to be done. However, rather than viewing these jobs as separate entities, we need to recognize their symbiotic relationship.

For instance, if marketing understands the criteria sales use to identify high-value leads, they can fine-tune their lead generation efforts accordingly. Also, if marketing does not produce leads, the sales team has no opportunities to identify etc. There is a clear lifecycle, order, sequence and co-dependence to which Jobs to be done are done when. 

Jobs to be done: processes, not statements

Every job, from transplanting a heart to cleaning a floor, has a distinct beginning, middle, and end, and comprises a set of process steps along the way.

The Customer-Centered Innovation Map by Lance A. Bettencourt and Anthony W. Ulwick (2008).

Every Job to be done (JTBD) that we identify for our target customers comprises of a set of steps. If you think about the job of cooking a dinner, it is not just cooking. You check the recipe, you gather the ingredients, you verify if you have everything you need, you adjust the recipe if not, you cook, you taste, you serve etc. And that applies to every JTBD.

When we identify those steps and their order, we can create value in a number of ways, e.g.:

• we can improve or accelerate execution of specific steps
• we can eliminate the need for providing certain inputs
• we can automate certain steps (thereby removing it from customer's responsibility)
• we can identify steps that are not supported by the current solutions

Job diagrams vs Process diagrams

In the world of IT and managing internal systems such as Salesforce, SAP, Oracle and others we are used to the concept of mapping business processes. But these are radically different from job diagrams. Business process maps capture how users are executing their jobs today. Every business process is unique to each company, specific to the systems, practices and standards they choose to adopt.

Job diagrams, in contrast, are meant to capture what the customers are trying to get done. It requires we look beyond the existing tools and understand what the JTBD requires. We might often find out that existing solutions do not even support every step involved in executing the JTBD.

The goal of creating a job map is not to find out how the customer is executing a job—that only generates maps of existing activities and solutions. Instead the aim is to discover what the customer is trying to get done at different points in executing a job and what must happen at each juncture in order for the job to be carried out successfully.

The Customer-Centered Innovation Map by Lance A. Bettencourt and Anthony W. Ulwick (2008).

Universal structure of Jobs to be done

Every job map follows a universal structure. Picture this structure as a series of interconnected steps that guide the customer through their journey:

• Define : What aspects of getting the job done must the customer define up front in order to proceed? 
• Locate : What inputs or items must the customer locate to do the job?
• Prepare: How must the customer prepare the inputs and environment to do the job?
• Confirm: Once preparation is complete, what does the customer need to verify before proceeding with the job to ensure its successful execution? 
• Execute :The most important part of the job (it is the most visible). What must customers do to execute the job successfully?
• Monitor : What does the customer need to monitor to ensure that the job is successfully executed?
• Modify : What might the customer need to alter for the job to be completed successfully?
• Conclude :  What must the customer do to finish the job? 

Download the best practice cheat sheet below to make it easier to draw job diagrams going forward.

3-level hierarchical approach

This finally brings me to the actionable framework I mentioned in the beginning. There are, as I have outlined in this article, a lot of best practices to keep in mind when dealing with JTBD framework. And there are a lot of details to remember when doing our market and customer analysis.

What I recommend, and what my product management team has been using for years, is a 3-level, hierarchical analysis approach to jobs to be done:

 Using Universal Process Notation as our notation, we capture 3 level diagrams:

1. Jobs to be done lifecycle: At the highest level we capture the interplay of general categories of 'jobs to be done'. When I say 'general categories' I mean what most people understand as JTBD statements. For instance, if you think about HR lifecycle, 'Recruit new employee' and 'Onboard new employee' are both examples of a 'category' of JTBDs.
2. Contextual Jobs to be done: At the 2nd level we capture specific, contextual job to be done statements as stand-alone use-cases. Think of it as 'variants' of the general JTBD category. For instance, you can have a general category of JTBD in HR like 'Recruit new employee'. But specific JTBDs would be: "Recruit highly skilled employee ASAP" vs "Recruit for a junior role in the coming months" vs "Recruit interns for summer internship program". Just like in our cinema example, the details of what is needed and how these jobs get executed would be completely different.
3. Individual Job diagrams: Once we have identified the detailed JTBDs, we drill down into them to capture the job diagram, i.e. what is the process of executing the job in a solution-agnostic way.

What's next?

The hierarchical approach to Jobs to be done analysis is a clear, logical way of organizing our analysis into customer needs. But it is only a part of a bigger, more nuanced framework for designing innovative solutions called 'Total Story Visualization'. 

You can learn the entire framework with practical examples to hone your skill and understanding in my masterclass in Total Story Visualization: