Skip to main content

The "Jobs to be Done" (JTBD) Framework

In product management, the concept of "Jobs to be Done" (JTBD) refers to a framework that helps teams understand the underlying needs and motivations of customers when they seek a product or service. It shifts the focus from demographic information or product features to the specific "job" the customer is trying to accomplish.

https://jobs-to-be-done.com/jobs-to-be-done-a-framework-for-customer-needs-c883cbf61c90

Tony Ulwick on How to Use Jobs to Be Done for Product Innovation at Lean Product Meetup - https://www.youtube.com/watch?v=pUjkFL0kzBA

https://www.youtube.com/watch?v=qQFUHapOJsQ

How JTBD Applies to Product Management:​

1. Understanding Customer Needs​

Instead of focusing on the product's features or market segments, JTBD emphasizes understanding why customers "hire" a product or service. The idea is that customers don’t buy products because of their features but because they have a specific problem or goal they want to solve. The product is "hired" to do a specific job.

  • Example: A customer doesn’t buy a drill because they want a drill—they buy it because they need a hole in the wall.

2. Identifying Functional, Emotional, and Social Jobs​

JTBD highlights three types of customer "jobs":

  • Functional Jobs: The practical task the customer wants to accomplish.

    • Example: "I need a way to communicate with my team remotely" (job for a messaging app).

  • Emotional Jobs: The emotional drivers behind the job (how the customer wants to feel).

    • Example: "I want to feel confident when giving a presentation" (job for a presentation software).

  • Social Jobs: How customers want to be perceived by others.

    • Example: "I want to appear innovative and tech-savvy to my colleagues" (job for a collaboration tool).

3. Customer-Centric Innovation​

Using JTBD, product managers can innovate more effectively by identifying gaps in current solutions. By focusing on what job customers are hiring a product to do, teams can create solutions that solve problems more efficiently, rather than just iterating on existing features.

  • Example: Instead of improving the camera specs of a phone, JTBD might reveal that customers primarily need a phone that can take good photos in low light conditions. This insight leads to targeted innovation.

4. Prioritizing Features​

JTBD helps prioritize product features by ensuring that new developments align with the core job the product is hired to do. If a feature doesn’t help the customer achieve their desired outcome, it may not be a priority.

  • Example: If customers hire a project management tool to "keep their team on the same page," features that improve collaboration (e.g., better notifications, shared dashboards) should take priority over less relevant features.

5. Improved Customer Communication​

Product managers can use the JTBD framework to communicate more clearly with customers. By understanding the job customers are trying to do, messaging, marketing, and customer support can be tailored around how the product solves specific jobs rather than just describing its technical specs.

6. Reducing Feature Overload​

Focusing on JTBD prevents adding unnecessary features that don’t contribute to the job customers are hiring the product to do. This leads to a more streamlined and purposeful product.

In summary, in product management, JTBD is a customer-centric approach to understanding and solving problems, ensuring that products are designed, built, and marketed around what the customer actually needs to accomplish, rather

The World's Simplest Product Development Process

  1. Define top level features for MVP. Evaluate + rank using the RICE framework. What are the main things a user wants to do, and try to organise these into distinct "jobs to be done".

  2. Be vicious on Work out

  3. Create a series of user stories that describe the intended functionality of these features and what they achieve for the users. Ensure the underlying code is in place to faciliate these - for example, in a car, aircon is not just a button.

  4. TO BE COMPLETED

  5. Get story assigned in [the current sprint] (link to jira)

  6. Check in with product manager/owner and engineering lead to ensure that you have a clear understanding of requirements. My main job is to make sure everyone has the best possible picture of what each story they work on is hoping to achieve, so don't feel awkward asking for our time.

  7. Create branch off master for the work based on the Jira story number (i.e. COMPANYNAME-123). If working on multiple repos, please try to ensure a consistent branch name across repos.

  8. When ready (this is ready), open a PR and get the engineering lead to review.

  9. After review, PR is merged to master branch, and the latest version of that branch will be deployed to dev.*.com for manual QA by product

  10. Multiple, small PRs are better than one large one.

Be a better product person