Jobs to be Done: The First 3 Steps + Practical Examples to Help You Get Started

Using Jobs to be Done efficiently requires a mindset shift – from focusing on the user to focusing on what they’re trying to achieve and why. Many JTBD experts argue that the Jobs to be Done theory made UX personas useless because we’re no longer interested in their common characteristics. What we should care about is the pain points and goals they have in common.

In our previous article, we explained what Jobs to be Done is and how it could be used by product managers, founders and designers. The challenge with JTBD is that there’s no specific framework that we all could learn and apply, so the theory is still pretty much open to exploration and interpretation. Despite dozens of attempts by popular JTBD practitioners to productise it, there’s no universal formula that works for everyone.

Since we like things systematic and structured, in this post we’re focusing on giving you practical examples of how you can approach Jobs to be Done when “hiring” it for your project.

As explained, Jobs to be Done is a theory, a process focused on discovering the real needs of a specific market segment (or the needs of your users if the product is live).

The worst thing to do when starting with JTBD is to ask users what they like or dislike about a specific product, or what they need to solve their problems.

The most important step when starting with JTBD is to detach the user from the product or the product concept and try to understand their real needs, goals, and motivation. Or using the JTBD terminology – we need to identify the job they’re trying to get done.

Step 1: Job Identification

Identifying what job areas to focus on is often underestimated, coming from the presumption that Jobs to be Done is a miracle solution that when applied correctly will solve all your product challenges. Well, good luck with that!

To make the process more efficient you need to identify and prioritise the jobs before you start with the job statement phase.

To do this, you could use a mixture of popular UX research and marketing techniques such as user interviews, stakeholder interviews, surveys, focus groups, etc.

The goal is to detect the areas of focus, so you can narrow down the job statements you’ll be formulating and the potential solutions you’ll be implementing.

In an ideal world, you could start with a blank sheet and explore all potential jobs that a user is trying to get done, but in the real world we work with project deadlines and budgets, so having the Job identification phase first would help you be more efficient.

Step 2: Structure a Job Statement

The most essential part of using Jobs to be Done is the ability to correctly formulate jobs statements. Here’s how we structure a job statement when we use JTBD, inspired by Alan Clement‘s approach, but modified by us:

I want to … (when I …), so I can/without …

Jobs to be Done Statement

Using the above example you can create high-level and more detailed job statements to help you identify different jobs, depending on your project. Sometimes this could be a job for wider market research, whilst in other cases, it could be a very specific task related to a new product feature.

Examples of Jobs to be Done statements that let to new product discoveries

The below examples are just for illustrative purposes to help you understand better what statements you should be after when using JTBD. They’re a collection of popular JTBD examples, our own case studies and easy-to-understand examples that we formulated for the purpose of this article.

In all of the above examples, a solution already existed but it was not good enough for the consumer’s demands. Jobs always evolve, depending on the circumstances, situations and context. For example, 200 years ago having a private bank account was a fantastic solution for money management, while in 2015 it was apparent that people needed more than a safe place to keep their savings.

In our job statement formula, we added “without” because we figured out that it would help us identify the user pain points and opportunities for innovation more efficiently, and will give us an identification where to look for a solution.

Step 3: Prioritise Opportunities and Solutions

The most critical element of using JTBD is – can you identify a solution that’s considerably better than the current solutions? Can you get the job done faster, more efficiently, cheaper?

Correctly formulated job statements can give you an amazing insight into market and growth opportunities, but offering a substantially better solution than what’s currently available to the user is what makes JTBD impactful.

Generally, you’d have a list of jobs that are:

1. Over-served or perfectly served jobs, but the user is not familiar with the solution.
2. Under-served jobs that are beyond the scope of your project, because of time, budget or capabilities limitations. These are great idea generators, but not very actionable (for example, an airline company can invent new ways to make your journey more pleasurable or slightly quicker, but they can’t transport you from London to New York in 2 hours which might be your ideal “job” as a traveler)
3. Under-served jobs that you can build a solution for. That’s where the opportunities for innovation and growth are.

It’s self-explanatory that you should focus on 3, where you can add value and generate positive results.

So what comes next?

See our process for evaluating if a feature is worth building, which you can use for prioritising job outcomes.