Should Designers Hire Jobs to be Done? Yes (and How)
A no-nonsense guide for UX Designers and product teams to mix JTBD with other design methods.
Cassie is a freelancer illustrator who struggles to organize herself during working hours, especially when tackling multiple projects.
She knows there is a better version of herself. A better version that allows her to have more spare time, feel in control of deadlines, and be sought-after by her colleagues.
But she is not quite there yet. She is struggling.
She has a Job to be Done, and she is willing to hire anything that gets her closer to getting it done. It could be software, a training course, or a productivity book. What matter is becoming a better version of herself.
By no means is Jobs to be Done a new framework, although it got major attention after Clayton Christensen introduced it in The Innovator’s Solution. Ever since, it has been adopted by large companies, but also criticized by UX experts for its lack of rigor in the way research is conducted.
It is true that JTBD is not a silver bullet to solve any design problem. As any model, it has its limitations and downsizes. Nonetheless, it is a powerful tool product and design teams can leverage to frame problems and customer needs, when being successfully combined with other techniques.
All models are wrong, but some are useful
— George Box
The focus of this writing is exploring how Jobs to be Done can be a useful UX tool from a practical approach, as well as how it can be mixed with other design frameworks.
Jobs Theory in a Nutshell
If we are looking to maximize the value of JTBD, the first step is learning its underlying concepts.
As Kurt Lewin said:
There is nothing more practical than a good theory
The most straightforward definition I’ve encountered comes from Jim Kalbach, who defines it as:
The process of reaching objectives under given circumstances
The key word is process, describing the existence of a current state and a future state, the Job to be Done being the process transition in-between.
In addition, some elements to grasp the foundations of JTBD are the following:
- Jobs are stable over time. The vehicle to accomplish them done is what changes
- Jobs have three dimensions: functional (what do I want to accomplish), emotional (how do I want to feel), and social (how I want to be perceived by others)
- A JTBD structure is composed by: job performer (who has the struggle), the job (main goal), process (how I go about getting the job done),the needs (how the job performer measures success), and circumstances (where and how the struggle happens)
- Jobs can vary in levels: from aspirations (I want to be a better freelancer) to micro-jobs (I want to be able to export invoices)
Three JTBD tools of the trade
The JTBD framework has several tools UX Designers can employ on our day-to-day work. In this writing we’re focusing on three:
- The job story: The atomic unit of JTBD that can help us articulate struggles and goals from our users
- The jobs interview: Discovering the underlying motivations and jobs from our users
- The job map: The artifact that will help us understand context, mental models, and steps our users take to get their job done
In addition, we will mix these tools with tried-and-true UX frameworks and apply them to a case study, to better grok the ideas behind JTBD.
JTBD in Practice
Let’s start by defining a fictional scenario to apply JTBD with other UX frameworks.
As the Product Designer, you are collaborating with your Product Manager and a Technical Lead on a new experiment. The team has a strong hypothesis to expand the company’s portfolio by addressing better ways for freelancers to work on multiple projects: task management, pricing work, documenting, invoicing, to mention a few. Eder, the PM, has read about Jobs to be Done, and is willing to give it a try.
Where to start?
1. Stakeholder Interviews
Great projects start with interviewing key stakeholders, to get as much context as possible about the initiative, the problem space, and how the team will measure success.
Key stakeholders can be subject-matter experts, leaders in the organization, and anyone who can provide insights about business goals, what are the opportunities they see in the market, as well as which resources the team can have at their disposal to address the challenge.
Some of the conversations to have during this phase can be:
- What are some of the business opportunities we can focus on?
- What do we know about our potential users?
- What would be the definition of success for this project?
- What inputs, resources, and documentation do we have?
You can use a tool such as Notion or Airtable to take notes of the interviews and tag them to find themes.
Learn more about stakeholder interviews.
2. Lean UX Canvas
With the debrief of the interviews, you are in a better position to gather the product team and key stakeholders and facilitate a workshop session, to obtain shared understanding of the challenge to solve.
A Lean UX Canvas can be a great tool to facilitate such discussion, as it enables conversations around business challenges, outcomes, users, their needs, as well as potential solutions to transform into hypotheses and experiments.
The output of the Lean UX Canvas will be a series of hypotheses to test, as well as the first assumptions about the customers, users, and the expected benefits.
With these outputs, you can start building Proto-personas.
3. Proto-Personas
Proto-personas are models that represent groups of users who share common behaviors, goals, and pain points.
They are not user personas. Proto-personas are based on empathy and assumptions, whereas user personas are based on research. However, building proto-personas first can be a lighthouse to identify how to better focus your research; what type of questions to ask potential users, and what gaps of information the team has.
One persona you might come up with for the fictional project might be Cassie, whose goals are to be more efficient, finish work before 5 pm, never miss a deadline, and some pain points might be spending too much time writing proposals, answering emails, and hunting clients for payment.
Learn more about Proto-personas.
4. Job Stories
Our first JTBD tool comes into play.
Once you have 1–3 main Proto-personas, it is time to put them to work. By considering their main behaviors, goals, and pain points, you are going to extract Jobs to be Done and format them into job stories, including situation (when the job to be done happens), motivation (what the job performer attempts to accomplish), and outcomes (why is important and how is it going to be measured).
An example of a job story for Cassie, our freelancer persona, could be:
When I am working on multiple projects for clients, I want to avoid working more hours than what I budgeted, so I don’t give away free work
You will end up with a backlog of job stories you can prioritize based on their level of uncertainty. Remember that these stories are assumption-based, which you will validate in the next phase.
5. Jobs Interviews
Jobs interviews are qualitative interviews that focus on discovering what people define as value. During this stage, you are focused on getting more context about the job stories you just defined, as well as the job performer, their jobs, processes, circumstances and context.
Every Job story can be a research question, which in turn can be an interview question to ask potential customers and users.
Framing research questions into interview questions can be challenging, as you might be biased to get an answer you are expecting to hear. This is a great resource to avoid such biases and maximize the qualitative learnings during interviews.
Learn more about jobs interviews
6. Job Map
As mentioned before, a key element of the JTBD theory is process: understanding the mental models and steps users take when striving to getting their job done.
With the interviews, you will be able to better understand how your users make decisions, and what sequence of steps they take to reach their goal. A job map is a great way to map such process, which not only will allow you to tell a story of your users to your stakeholders, but also analyze every step and formulate ideas to improve it.
By now, you are in a great position to smoothly transition from the problem space to the solution space, and capitalize all the models and artifacts you have built to translate them into user flows and sitemaps, as well as running ideation sessions with your team to tackle tricky challenges.
After such ideation phase, you can start prototyping your ideas, test them with users, and incrementally hand-off to the dev team to launch first versions of the product.
Takeaways
JTBD can create synergy when being applied with other UX techniques. You can consider it as a plugin for UX, rather than an operating system.
I oversimplified JTBD theory in the interest of making it more accessible for designers to start experimenting with it. However, if you want to go the deep route, I recommend the following resources:
- Kalbach, James. JOBS TO BE DONE PLAYBOOK : ALIGN YOUR MARKETS, ORGANIZATION, AND STRATEGY AROUND CUSTOMER NEEDS. New York, New York: TWO WAVES Books, 2020. Print.
- Intercom on Jobs to be Done
- Lightweight JTBD for StartUps
