Applying Jobs-to-be-Done Theory to build successful products
Introduction to Jobs-to-be-Done
Jobs-to-be-Done is a mental model (developed by Clayton Christensen) that can be used to orient product development around solving meaningful problems.
A product or service succeeds by providing a solution to a problem people face in their lives. The Job-to-be-Done (JTBD) articulates the desire for a solution. For example:
- Melissa hires The New York Times to make their commute more enjoyable.
Crucially, users may "hire" the same product to do different Jobs:
- Melissa hires The New York Times to make their commute more enjoyable.
- Jabari hires The New York Times to monitor events that may affect their restaurant.
They may also hire different products to do the same Job:
- Melissa hires Audible to make their commute more enjoyable.
- Jax hires Instagram to make their commute more enjoyable.
Jobs-to-be-Done help a product team understand:
- the progress people are trying to make in their lives
- how (and how well) people are achieving that progress
- the forces at play when selecting or switching solutions
Switch Interviews
Let's pretend that we're making a documentary about your purchase…
Switch Interviews are a timeline-based interview to help us understand the forces at play when switching to a new solution created by Bob Moesta and the Rewired Group. It will inform our understanding of a user's switch/purchase timeline and help us build a forces diagram. It helps see how users are framing competition for the Job-to-be-Done and gives us an idea of pricing.
Jobs Profile and Forces Diagram
After we conduct Switch Interviews, we'll listen to the recording of the interview again and add detail into a document highlighting their emotion and language.
Create a Jobs Profile and Forces Diagram
Jobs Statement
A Jobs Statement is an alternative way of describing the problems and pain-points that we're trying to solve for and the outcomes that users and the business expectations. It should propose the progress that the product is making for the people that are using it.
Jobs Statement Format
[Pain-point / Opportunity] + [Desired Outcome / Progress Made]
We'll create this statement together. As a team, we'll review the research we've collected and the insights gained during interviews. On the whiteboard, we'll work together to wordsmith the statement.
The Job Statement acts as a guide to the ideas that we come up with and the solutions that we generate. It helps us decide which features we might want to validate and which should be shelved for the future or thrown away all together. We'll refer back to it to define the smallest product to prototype and test.
We'll keep the statement in the reference section of our project management board. This statement acts as a reminder of the overarching Job-to-be-Done that we're trying to solve. As we take on new tasks, it allows us to continually question how the features we're designing are helping us get to the outcomes in the statement. It also gives new people on the project a quick way to understand the core problems we're trying to solve for and progress that we're trying to make for the people using the product.
Job stories
Job stories are a way to contextualize the pain-points we're trying to solve for by describing the situation a person is in, their motivation in doing a task, and the outcome that person expects.
When I'm buying a baseball card, I want to know if it is fairly priced, So I can have confidence in my purchase.
When I'm viewing an event, I want to know which comedians are performing, So I can decide if the event is worth attending.
When I've paid my energy bill, I want to see how much it was and how much I saved, So I can understand my energy spending.
In addition to capturing the desire of the JTBD, a job story encapsulates the problem being solved by the code changes:
When I'm buying a baseball card, I want to know if it is fairly priced, So I can have confidence in my purchase.
When I'm viewing an event, I want to know which comedians are performing, So I can decide if the event is worth attending.
When I've paid my energy bill, I want to see how much it was and how much I saved, So I can understand my energy spending.
In this way, job stories force the team to focus on delivering changes that help users solve real problems.
How to write and use Job stories
A Job story is written from the user's perspective with the following structure:
Jobs Story Format
When I {situation}, I want to {motivation}, So I can {outcome}.
Job stories answer:
- When does the problem occur? (situation)
- What is the problem? (motivation)
- Why does this problem need to be solved? (outcome)
Notably, Job stories are agnostic to solutions, and avoid answering:
- How are we going to solve the problem? (solution)
Depending on your project management tools, you can map Job stories onto tickets, todos and/or epics:
The user motivation in a Job story often provides a good title for tickets and pull requests.
Writing Job stories for technical tasks
Development tasks like updating dependencies and writing documentation ultimately improve the product/service (or the ability to do so), and can be framed using Job stories where the user is the developer or administrator:
When I'm maintaining the app, I want to use the most recent stable version of {dependency}, So I can extend the lifespan of the app.
When I'm developing the app, I want to eliminate {flaky test}, So I can have confidence in the reliability of the test suite.
When I'm joining the development team, I want to know how to set up my local dev environment, So I can quickly contribute to the codebase.
Why we prefer Jobs Stories over User Stories
In our experience, User stories tend to become solution- and task-oriented, giving the team less room to discuss the problem and determine the optimal approach to solving it.
User stories rely on personas, which create assumptions about users that may not be validated. By focusing on the specific context a user is in when working to solve their problem ("When I'm scheduling a social media post" vs. "As a creative"), we avoid making generalized assumptions about users.
We believe that defining and solving problems together generates the best outcomes. We want to validate all solutions before taking the time to build them. If your team is already problem-oriented and focused on validation, the choice of story syntax is less important.