Skip to content
← Back to Glossary

Jobs to Be Done

Jobs to Be Done (JTBD) is a framework for understanding why customers buy or use a product. Instead of focusing on demographics or features, JTBD asks what "job" the customer is trying to accomplish. A job is the progress a person seeks in a specific circumstance. Products succeed when they help customers complete their jobs better than alternatives.

What is Jobs to Be Done?

Jobs to Be Done is a theory of innovation developed by Clayton Christensen and others. It reframes product decisions around customer motivation rather than product features. The central question is: what job did the customer hire this product to do?

A "job" is not a task. It is the underlying progress someone wants to make. A person does not want a quarter-inch drill. They want a quarter-inch hole. And they probably want the hole because they want to hang a shelf, because they want an organized room. JTBD pushes you to understand the deeper motivation.

Jobs have functional, emotional, and social dimensions. A project management tool might help someone track tasks (functional), feel in control (emotional), and demonstrate competence to their team (social).

Why It Matters for Product Teams

JTBD helps you avoid building features nobody uses. When you understand the job, you can evaluate whether a requested feature actually serves that job or is a distraction.

It also helps you identify competitors you might not expect. If the job is "stay informed about project progress," your competitors include not just other tools but also email threads, Slack channels, and weekly standup meetings.

Customer feedback becomes more useful through the JTBD lens. Instead of taking feature requests at face value, you dig into the underlying job. A request for "export to PDF" might really be about sharing progress with a stakeholder who does not have login access.

How to Apply Jobs to Be Done

Interview your users. Ask about the last time they used your product and what they were trying to accomplish. Focus on the context and motivation, not the features they used.

Analyze your feedback data for patterns. Group feature requests by the job they serve, not by the feature category. You may find that ten different requests all point to the same unmet job.

Write job stories instead of user stories. The format is: "When [situation], I want to [motivation], so I can [expected outcome]." This keeps the focus on the customer's world rather than the product's interface.

Use tools like Quackback to tag and categorize feedback by job. When you can see which jobs generate the most demand, you can prioritize with confidence.

Collect feedback that drives these decisions

Quackback gives your team a single place to collect feature requests, prioritize with real data, and share your roadmap.