Jobs to Be Done (JTBD): The Framework and How to Research It
A practical guide to the Jobs to Be Done framework — what JTBD means, how to write job statements, and how to uncover the real jobs customers hire products for.
Key Takeaways
- Jobs to Be Done reframes products as things customers "hire" to make progress in a specific situation.
- The job is stable; the solutions change — anchoring on the job prevents building features nobody hired you for.
- A job statement captures the situation, the motivation, and the desired outcome, not a demographic.
- You uncover jobs by studying real moments of struggle and switching, not by asking what features people want.
- Community discussions reveal jobs in the wild — the moment someone sought a solution and why.
Jobs to Be Done is one of the most useful lenses in product and marketing — and one of the most misapplied. Used well, it stops you from building features nobody asked for and helps you position against the real alternative (which is often "do nothing"). Used as jargon, it becomes a persona template with different labels.
This guide covers what JTBD actually means, how to write a real job statement, and — the part most articles skip — how to research jobs rather than invent them.
The Core Idea: Customers Hire Products for Jobs
The premise: people don't want products, they want progress. They "hire" a product to move from a frustrating situation to a better one. The oft-cited example: nobody wants a drill; they want a hole; and really they want the shelf on the wall. The drill is just what they hired for the job.
Two consequences make this powerful:
- The job is stable; solutions change. People have always needed to "get from A to B" — they've hired horses, cars, and ride-shares for the same job. Anchoring on the job future-proofs your thinking.
- Your real competitor is anything else hired for the same job — including a spreadsheet, a manual process, or doing nothing. That reframes your competition and your positioning.
Writing a Real Job Statement
A job statement captures a situation, a motivation, and an outcome — with no demographics:
When [situation], I want to [motivation], so I can [expected outcome].
Example for a market-research tool:
When I'm about to build a product, I want to know whether people actually have this problem, so I can avoid wasting months building the wrong thing.
Notice what's absent: no age, no job title, no company size. A first-time founder and a corporate PM can share that exact job. That's the point — the job unifies people the persona would split apart.
Bad "job statements" smuggle in a solution: "I want a dashboard that shows Reddit mentions." That's a feature, not a job. The job underneath is "I want to know what my audience is struggling with so I can decide what to build."
Jobs Have Three Dimensions
Real jobs aren't purely functional. Strong JTBD research captures all three:
- Functional — the practical task (validate a problem exists).
- Emotional — how the person wants to feel (confident, not anxious about wasting effort).
- Social — how they want to be perceived (a founder who does their homework, not one who guesses).
Products that serve the emotional and social dimensions, not just the functional one, win loyalty. "Validate your idea" is functional; "build with confidence instead of fear" is emotional — and it converts better.
How to Research Jobs (Not Invent Them)
This is where JTBD lives or dies. You can't armchair your way to real jobs — you have to observe them. Two rules:
Study switching moments. The richest signal is when someone switched — abandoned one solution for another. What pushed them off the old one? What pulled them to the new one? What anxieties held them back? Reconstructing a real switch reveals the job with unusual clarity.
Never ask "what features do you want." That produces solution guesses. Ask about the last real time they faced the situation: what happened, what they tried, what they hired, why.
Two practical sources:
- Interviews — reconstruct the timeline of a real purchase or switch, moment by moment.
- Community discussions — jobs appear in the wild on Reddit and forums: "I've been trying to do X, tried these three things, none worked, is there anything that..." is a job statement written by the customer. PainPointMap surfaces these at scale — scan your audience's subreddits and it returns the recurring struggles and "I need something that..." moments that map directly to jobs, in the customer's own words.
Turning Jobs Into Decisions
Once you have the real jobs, ranked by how often and intensely they appear:
- Product — build for the top jobs; cut features that serve no job.
- Positioning — describe your product as the best way to get the job done, against the real alternatives (including "do nothing").
- Marketing — lead with the situation and desired outcome, in the customer's language, so they recognize their own job instantly.
Related Reading
- Customer Discovery Guide — the interview method for uncovering jobs
- How to Find Problems Worth Solving — spotting high-value jobs
- Voice of Customer Research — capturing jobs in the customer's words
- Pain Point to Product — turning a validated job into a product
Frequently Asked Questions
What is the Jobs to Be Done framework?
Jobs to Be Done (JTBD) is a lens that says people don't buy products for their own sake — they "hire" them to make progress in a specific situation. The classic example: someone doesn't want a quarter-inch drill, they want a quarter-inch hole (and really, the shelf it lets them hang). JTBD focuses product and marketing on the underlying job the customer is trying to get done, which stays stable even as the solutions that serve it change.
How do you write a Jobs to Be Done statement?
A common format is: "When [situation], I want to [motivation], so I can [expected outcome]." For example: "When I'm about to build a product, I want to know if people actually have the problem, so I can avoid wasting months building the wrong thing." Note it contains no demographics — just a situation, a motivation, and an outcome. That structure keeps the focus on progress the customer is trying to make.
How is JTBD different from personas?
Personas describe who a customer is — demographics, role, traits. JTBD describes what a customer is trying to accomplish in a situation, regardless of who they are. People with very different personas can share the same job, and one person hires different products for different jobs. Personas answer "who"; JTBD answers "why they act." Many teams use both: personas for targeting, JTBD for what to build and how to position it.
How do you research Jobs to Be Done?
Study real moments, not hypotheticals. The richest JTBD research looks at switching moments — when someone abandoned one solution for another — and asks what pushed and pulled them. Interviews reconstruct the timeline of a real purchase. Community discussions capture the job in the wild: the moment someone sought a solution and why. Avoid asking "what features do you want," which produces solution guesses, not jobs.
What tools help with Jobs to Be Done research?
Customer interviews are the classic JTBD method for reconstructing switching moments. For finding jobs at scale, community research surfaces the situations where people seek solutions — PainPointMap scans subreddits and returns the recurring problems and "I need something that..." moments that map directly to jobs. Review mining (why people switched tools) is another strong source of switching-moment data.
Find what your customers are actually complaining about.
Scan your target audience's subreddit and see real pain points ranked by severity — no surveys, no guesswork.
Scan My Target MarketCovers competitor analysis, SaaS go-to-market strategy, and how founders use community research to find product-market fit.