In the world of product management, understanding what drives customers to choose and use a product is crucial. The Jobs to Be Done (JTBD) framework provides a powerful way to uncover customer motivations and build products that truly solve their problems. But what exactly is JTBD, and how can product teams leverage it effectively?
Jobs to Be Done is a theory that helps explain why customers "hire" products or services to accomplish a specific task or goal. Instead of focusing solely on demographics or traditional market segments, JTBD shifts the focus to the progress that a customer is trying to make in a given situation.
For example, a customer doesn’t buy a drill because they want a drill —they buy it because they need to make a hole in their wall. The job to be done is "create a hole" , and the drill is just one possible solution.
JTBDs are also a tool the dive into the definition of your product's value proposition. For instance, Strategizer's Value Proposition Canvas asks for customer jobs, which are part of the "Why" side of the canvas, besides pains and gains.
It's important to remember that, when designing a product, you target a certain audience in a certain context. For B2B product this might mean to think of the process a certain position bring. For instance in sales, the process would be prospecting, lead qualification, contacting, discovery calls, product demos, closing and so on. In B2C you target other aspects of live, e.g., on a video streaming platform users of such jobs as "deciding what to watch this evening" or "continuing to watch on airplane". No matter what's your audience, jobs to be done follow some core principles that you should have in mind:
People hire products to make progress – Every purchase decision is based on a desire for progress in a specific context (at work, in front of the TV).
Jobs exist independent of solutions – Customers don’t care about your product; they care about what it helps them achieve. So you need to ignore all technology and features for the moment and reflect more on what the user cares about.
Context matters – The same person might "hire" different products for the same job depending on the situation.
As a product manager, integrating JTBD into your discovery process can unlock deeper insights into user needs. Here’s how you can apply the framework:
Instead of asking customers what features they want, focus on why they made past decisions . Key questions include:
What problem were you trying to solve?
How does your daily work routing look like?
What is the expected output of the single steps in your process?
What triggered you to start looking for a solution?
Customize these interview questions for the user's context but avoid to be too suggestive---otherwise you might miss unknown unknows that are extremely valuable. The user the domain expert in his/her field.
A job isn’t just functional—it has emotional and social dimensions:
Functional Job: The core task the user wants to accomplish. This maps to the single steps of the user process and the way/the outcome to be achieved.
Emotional Job: How they want to feel during and after the process. Something like productive, creative or collaborative.
Social Job: How they want to be perceived by others. Everyone has a certain picture to be conveyed to peers such as making others see that they are effective, that they perform above average or that they praise the work of others.
For instance, someone buying a premium fitness app isn’t just trying to lose weight (functional). They also want to feel confident (emotional) and appear disciplined to their peers (social).
Instead of traditional user stories ("As a user, I want to..."), JTBD uses Job Stories. Use the following template:
When I [encounter a situation], I want to [perform an action] so that I can [achieve a desired outcome].
Example:
When I feel overwhelmed by my tasks, I want to quickly prioritize them so that I can stay productive without feeling stressed.
This approach focuses on the motivation behind actions, not just the action itself. Collect a number of such jobs and interview your user panel about the details.
When you hypothized JTBDs and had multiple interviews, it's time to process your insights to something valuable:
Prioritize features based on actual user jobs, not just requests. Instead of just voting about what features devs "feel" to be done next, better see features as opportunities to support users in der JTBDs and priotize on how valueable the job is to them.
Improve onboarding by guiding users toward completing their job efficiently. There can be multiple onboarding streaks, depending which intent a user had when signing up.
Optimize messaging by positioning your product around the job it solves. User the insights from your insights to formulate copies and to differentiate within your market.
Instead of vanity metrics, focus on in user experience, structured by jobs you have on your list:
Time to job completion – How fast does your product help users achieve their goal?
Switching triggers – What events cause users to look for a new solution?
Customer retention by job success – Do users keep using your product because it continuously helps them achieve their job?
🚀 Slack : People don’t "hire" Slack because they want a chat tool—they hire it to reduce email overload and streamline team collaboration.
🍔 McDonald’s Milkshake Case : Customers weren’t buying milkshakes for the taste alone. Morning commuters were "hiring" them to provide a filling, convenient, and mess-free breakfast alternative while driving.
📈 Spotify : Users don’t just listen to music—they "hire" Spotify to set moods, discover new artists, or focus while working.
The JTBD framework is very relevant for product and should be users to optimize your argumentation what features to deliver first and which not:
Avoids feature creep – Focuses development on meaningful improvements.
Increases product-market fit – Aligns product value with real customer needs.
Enhances user experience – Helps streamline workflows and reduce friction.
By thinking in terms of Jobs to Be Done , product managers can move beyond surface-level insights and build solutions that truly resonate with users.