People purchase products and services to get a “job” done to make progress in
their life. We use Jobs-to-be-Done to understand the progress people are
trying to make in their lives, how they are currently
achieving that progress, and the forces at play when switching solutions.
Introduction to Jobs-to-be-done
People are always evaluating where they are in life and deciding where they want
to be. They’re looking to make progress to make them better versions of
themselves and improve their situation in life.
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.
Conduct a Switch Interview
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 doc
Highlight their language
Create a Jobs Profile and Forces Diagram
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]
For many of our Product Design Sprints, we’ll create this statement together. As
a team, review the research that you’ve collected and the insights that you’ve
gained during interviews. On the whiteboard, work together to wordsmith the
During the rest of the Design Sprint it 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. Refer back to it throughout the sprint to create
the smallest product to prototype and test.
After the design sprint, keep the statement as the left topmost card in the
projects Trello board. This card acts as a reminder of the overarching
Job-to-be-Done that we’re trying to solve. As we take on new cards in Trello, 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.
Jobs Stories are a Jobs-to-be-Done way to write out feature stories. Instead of
providing solutions, Jobs Stories communicate the value that our designers and
developers are creating for the user and the business. They frame the progress
that the user is trying to make, the outcomes that we want for the business and
users, and put more focus on the situation the user is in. Building this
understanding allows us to question how we’re solving it, together, as a team.
Jobs story format:
I want [Motivation]
So that [Desired Outcome]
Why we prefer Jobs Stories over User Stories
In our experience, user stories are more solution and task-oriented. They leave
the team less room to work on solutions together and instead have solutions
handed down to them. User stories are great when your team doesn’t need
We believe that solving problems together generates the best outcomes and want
to validate all solutions before taking the time to build them.