Customers don't buy products — they hire them to do a job. This template maps the functional, social, and emotional jobs your product gets hired for. Snap it and turn the insight into action.
Run a JTBD session when building a new product or feature, when customers are churning and you can't explain why, or when your positioning isn't resonating with the market. It's also a powerful pre-cursor to any customer interview — it tells you what questions to ask.
JTBD is most useful when the team disagrees about why customers use the product. Mapping the jobs explicitly surfaces those disagreements and forces a resolution grounded in customer language, not internal assumption.
The specific situation that triggers the customer to look for a solution. 'When I finish a sprint retro and the whiteboard needs to turn into next-week's tasks...' Context grounds the job — the same person has different jobs in different situations.
The practical task the customer is trying to accomplish. 'I want to capture every action item from the whiteboard and assign it to a team member before anyone leaves the room.' Functional jobs are the core job — the primary reason the customer hires a product.
How the customer wants to be perceived by others when doing the job. 'I want to be seen as the organized PM who actually follows through.' Social jobs are often more powerful purchase drivers than functional jobs — they're why people pay for premium when a free option exists.
How the customer wants to feel while doing the job. 'I want to feel confident that nothing fell through the cracks.' Emotional jobs explain why customers are loyal to a product even when a cheaper alternative technically does the same functional job.
The metrics by which customers measure success at the job. 'All action items are assigned within 10 minutes of the retro ending.' These are the customer's success criteria — and they're different from your product's success metrics. Map both and find the overlap.
What the customer uses today to get this job done — and what they've tried and abandoned. The 'hired' solution tells you your real competition. The 'fired' solution tells you what failure looks like and what switching cost you're asking them to accept.
Use the JTBD format: 'When [situation], I want to [motivation], so I can [expected outcome].' Write one statement per sticky. These come from customer interviews — use actual words the customer used.
Sort job statements into the three job types. Some statements will cover all three — break them apart. The sorting forces precision about what kind of job each statement is.
For each functional job, write the metrics by which the customer measures success. Speed, accuracy, confidence, perception — quantify where possible.
What are customers currently hiring for this job? List the actual products and workarounds. These are your real competitors — including the ones that aren't in your category.
Rate each job on two dimensions: importance to the customer (1–10) and current satisfaction with existing solutions (1–10). High importance + low satisfaction = highest-opportunity job. That's what to build.
Snap the board with BoardSnap. The AI reads the job statements, desired outcomes, and opportunity scores — outputting a prioritized job map that feeds directly into your product backlog.
JTBD sessions produce some of the richest customer language a product team ever captures — verbatim job statements that should live in PRDs, positioning docs, and onboarding copy. On a whiteboard, that language is collaborative: the team debates which words are right, and the argument is as valuable as the output.
BoardSnap preserves the exact language. Snap the board after the session and the AI reads every job statement, desired outcome, and current solution — outputting a structured job map that feeds directly into the next design sprint or positioning workshop.
A user story describes a feature from the user's perspective: 'As a PM, I want to export action items so that I can paste them into Jira.' A job-to-be-done describes why the customer seeks any solution at all: 'When a retro ends, I want to ensure every commitment is tracked before the team scatters.' JTBD is more durable than user stories — it doesn't change when the feature set changes, because it's about the customer's goal, not your implementation.
JTBD was developed by Clayton Christensen and popularized by Tony Ulwick (Outcome-Driven Innovation) and Bob Moesta. Each practitioner has a slightly different model, but the core insight is the same: customers hire products to make progress in a specific situation. The framework described here draws on elements from both the Christensen and Ulwick schools.
Ask about the timeline of the purchase decision: 'Walk me through the moment you decided to try this.' Ask about the first time they noticed the problem. Ask what they were using before and why they stopped. Jobs emerge from the story of the switch — not from feature preference questions.
Yes, but it should have one primary job it's definitively best at. Products that try to serve too many jobs equally well tend to be mediocre at all of them. Use the opportunity-scoring step (importance vs. satisfaction) to identify the one job where you have the most potential to be the clear leader.
No exporting, no transcription. Snap the board, get the action plan.