Jobs To Be Done
Jobs To Be Done (JTBD from now on) is a theoretical framework that helps you understand the motivations and constraints of your customers. With JTBD, you can build better products, improve your service, and understand how to create value for your customers.
What Is JTBD?
Jobs To Be Done is a framework using which you can create more value for your customers. A Job in this context is a process that a person undertakes when they improve themselves. The Job To Be Done have constraints that are working against the change.
Your product is a tool that Customer hires to get their Job done. Through this hire, the person evolves and has more potential for new Jobs. With every hire, the customer fires competitors that were solving his Job before.
Summarised, your role in the Job is to:
- Understand your Customer
- Identify the Job (not Activity)
- Understand contrast and competition (The carp pâté can be a competitor to wine bottles)
- Let Customers hire your product
- Make your Customer improve
- See that your Customer stops using other products but yours
- Thus create unique value for your Customer
JTBD has a different point of view for demand. Through this view, you look at demand creation (push and pull) and how demand reduction (anxiety and habits).
- Push is what makes people change
- Internal is when a person doesn’t like the current state of things
- External is when a person’s life change due to external factors
- Pull is what shapes the change
- The pull for a better life is motivation saying people want a better life
- The pull toward a solution is what makes a person select one product as the mean for change.
- Anxiety are questions about the product
- Anxiety-in-choice is being unsure if the products can deliver change
- Anxiety-in-use is knowing that the product delivers the change. However, the product makes the person nervous about its qualities
- Habits are forces working against pulls
- Habits-in-choice are externalities that are working against the switch to your product
- Habits-in-use is learned “solutions” for the Job (person’s habits)
Why You Might Want JTBD?
JTBD is one of the possible idea/product validations frameworks you can use. With JTBD, you are actively listening to your customers’ Jobs and learning about their emotions, constraints, or motivations.
When you see customers piecing together solutions themselves, these are great clues for innovation.
Through studying your Customers you can create products that answer motivations. With JTBD, you can validate any new products before hitting the market.
Moreover, when there is no Job To Be Done, there is no room for innovation. Product that doesn’t care about Jobs most likely won’t be successful.
Problems JTBD Helps to Solve
- Demotivated team
- Bad product-Market Fit
- Meaningless work
- Long feedback Loops
- Sunk Cost
- Unsuccessful product
- Unhappy customers
How to Implement JTBD?
Good starting points can be the Job Stories exercise and Customer Interviews.
Job Stories Exercise
This exercise aims to see your JTBD. Through writing Job Stories, you understand where you could create value. Start with this template sentence.
When _____ , I Want to _____ , So I Can _____.
Here, you don’t care about roles and expectations, since they are additional layers of assumptions. Don’t use personas, talk with Customers (in this case, it can be you or a hypothetical customer).
When depicts the situation. It can be simple (When I wake up) or complex (When I am rewriting code because there is the new version of Python 4.6, and I can make it simpler).
I want to is Motivation. Again, it can be one word (use bathroom) or a full-sentence (I want to find a way to make this automatically). Consider adding Forces to this part. These are things that providing additional context (I am angry when I need to go through a monolith of code and check each function manually). Forces can help you with designing your solution (product for hire).
So, I can is the Expected Outcome. For example, So, I can focus more on creating value.
When you have your sentence filled, start thinking about why do you want X. Start rewriting or re-editing. Look at the motivations you have. Understand the Forces and use them to your advantage to achieve your Expected Outcome. Ask what is next? What are the pulls and pushes in your sentences? Write anxieties working against your sentence. Identify the habits hidden in it.
Use the situation for targeting, the motivation for your product and the Expected Outcome for your final message. Kill all the birds nothing but one sentence.
Source: Job story
Then, you can start designing your solution around the job.
The best way to use this exercise is to do it after the Customer Interview with your customer’s stories.
Customer Interview - Existing Customer
A Customer Interview is a method to understand WHY. You are analyzing the “customer journey” of people who bought your product. This is not about WHY your product is good, it's about WHY they bought it.
Remember that, your customers generally don’t analyze why did they buy something. You are learning with them about them. The point is to build the Story and its essence.
The interview starts with understanding the point of purchase, then continue towards first thoughts about the product, and start unrevealing the story between these two points. Consider the following questions.
- Point of Purchase
- When did you purchase the product?
- Where did you purchase X?
- What time was it?
- How did you purchase it?
- How was the weather?
- Did you buy something with it?
Usually, it’s not a good idea to ask why did you make the purchase. Don’t make them question their purchase, make them remember the feelings alongside it instead.
- When did you first time realize that you “need” X?
- Where were you?
- Were you with someone?
- What were you doing? What were you trying to do?
- How frequently did you try to do the thing?
- Where were you looking?
- How did you start with your search?
- What were your searching habits?
- Do you have a history with X?
- Did you look at X?
- What was important for you during that time?
- What were the factors for you?
- What solutions did you try? Or did not try? Why?
- How did your close ones feel about it?
- Did you talk about the purchase with your close ones?
- Did you imagine before the purchase what using X would be like?
- What were you hoping for?
Engage in their memories, explore their emotions, and build rapport with them to identify Pulls, Pushes, Anxieties, and Habits.
Customer Interview - Hypothetical Customer Workshop
Hypothetical Customer is a more difficult scenario since you are adding layers of assumptions. Thus, you should always validate with real customers as soon as you can.
In our Hypothetical Customer Workshops, you start by asking for possible jobs. Then, you select the best ones (top three). On these selected jobs, you look into Dreams (pulls). What is the perfect world for these jobs? With Dreams in mind, you should explore anxieties and habits working against the pulls.
What Are Jobs To Be Done for X?
Brainstorm as many as you can. Go into what jobs you think your hypothetical customer has. Examples:
- Start-ups are struggling with product validation
- Devs don’t have time to stay updated on all practices
- I would like to show how cool my product is
What Are Pulls (Dream Worlds) for X?
Go into the perfect realities. What is the dream world of your customer? Examples:
- Devs can create the best products with the best know-how
- I have the most profitable start-up, my product is in business schools as a model for success
With Jobs and Pulls, validate on which you want to focus. You can look at which Jobs have the highest hypothetical Return Of Investment or at any other metric relevant for you.
What Is Your Product for Your Customer?
Try to name the essence of your product in your customer’s eyes. What are you for your customer? Examples:
- Product validation framework
- A senior friend that shares best practices with us
- Dev Improvement Tool
What Is Working Against the Demand for X?
With a clear picture of your product and job, look at which things are working against the demand. Examples:
- Another product validation frameworks like ODI
- The old workplace habits
- Waterfalls on waterfalls
What Will They Fire?
If the customer hires your product, what will they fire? What will they stop using? Try to name as many things as you can. Even partial firing (like that tech lead is fired from searching for new practices) is important.
- Other validation frameworks
- Business consultants
- Business validation tools
With a hypothesis for the Job (with pulls, habits, and anxieties), go to the customer. Talk with them and look if your hypothesis work. As soon as they buy your product, start using the existing customer interview.
Your goal is to understand their why better than anyone else. Time spend on JTBD practices is saving you development costs of unnecessary features, helping you to turn unhappy clients into happy ones, and finally, stops you from Bad market fit.
Common Pitfalls of JTBD
- People keep focusing on Actions rather than on Jobs
- Misunderstanding who is your competitor
- Not working around Anxieties and Habits of your customers
- Not enough practical information online about JTBD
- Rushed Interviews without understanding the story
- Talking about your product instead of customer experience
Resources for JTBD
- When Coffee And Kale Compete
- NHS Case Study
- Tips for Job Story
- Know your customers JTBD
- Intercom JTBD
- Jobs To Be Done Book
- 8 things to use in “Jobs-To-Be-Done” framework for product development
- 8 tips for JTBD Interviews
- Uncovering JTBD (Interview part)
- Questions for JTBD interview
- Reading Further list
Want to write for DXKB?
Feel free to contribute. People from DXKB community will be more than happy.
Documentation testing is a process of improving your existing documentation through feedback. Understanding how to get feedback is crucial for building good documentation and positive developer experience.Read more
Practicing Continuous Delivery means that you adopt practices to be ready to release product changes any time you want. Your product is always ready to deploy to production.Read more
Code Coverage measures the percentage of source code lines that are covered by automated tests. If you have 90% CC, it means that 10% of the source code is not being tested at the moment.Read more
Code Review is an important practice for checking each other's code. The reviewers are other developers from the team. The goal is to uncover potential mistakes that could slip through testing.Read more
Agile Events are necessary meetings for keeping up the good work. They are usually time-boxed and the most common Agile framework that uses these periodic rituals is Scrum.Read more