Jobs To Be Done is one of those frameworks that sounds simple until you try to use it. The theory is clean: customers don't buy products, they hire them to do a job. But when a team sits down to write an actual JTBD statement, the result is usually a slightly reworded feature request. "When I need to collaborate on design files, I want to leave comments so that feedback is captured." That's not a job. That's a user story with extra words.
The difference matters. A feature-level statement tells you what to build next. A genuine JTBD statement tells you why anyone would bother building anything at all.
What a job actually is
Clayton Christensen's original framing was blunt: people hire milkshakes for the commute, not because they love milkshakes. The product is incidental. What they're hiring it for - a slow, thick breakfast that keeps their hand occupied during a boring drive - is the job.
A job is not a task. Tasks are things software does. Jobs are things people are trying to accomplish in their lives, often with significant emotional or social stakes attached. The job of "being taken seriously in a board presentation" can generate demand for slide templates, coaching services, rehearsal tools, and a dozen other categories. None of those products are the same. All of them are competing for the same job.
When you write a JTBD statement that's really just describing a task, you've narrowed your problem space before you've understood it. You've pre-decided the solution category. That's exactly the kind of premature convergence that kills discovery before it starts.
The anatomy of a strong statement
The classic JTBD format is: When [situation], I want to [motivation], so I can [expected outcome].
Each of those three parts does something specific, and each one is where teams most often go wrong.
The situation is where most statements are too vague. "When I'm working on a product" or "When I'm in a meeting" - these don't tell you anything. A strong situation captures the specific trigger: the moment of friction, the transition, the deadline looming, the relationship at stake. "When a new executive joins my company and starts asking why we built what we built" is a situation. It's specific enough that the team can picture it.
The motivation is where teams get too specific too fast. They jump to what they think the customer wants - usually a feature. But the motivation in a JTBD statement should be functional, not prescriptive. "I want to explain our product strategy clearly" is a motivation. "I want a shared document everyone can edit" is already a solution masquerading as a need.
The expected outcome is the part teams skip entirely or write in abstract terms that can't be tested. "So I can be more productive" tells you nothing. A real expected outcome names what changes: "so I can bring the new stakeholder up to speed without calling a meeting" is testable. You know when it's happened.
The rewrite test
Here's a practical test for any JTBD statement you've written: try to imagine three completely different products that could all fulfill it. If you can only think of one - or if all your ideas are variations of the same thing - the statement is too narrow. You've written a requirement, not a job.
If your statement is "When I need to prioritize features, I want to score them by impact and effort, so I can make a defensible decision," the only products that fit are prioritization matrices. That's a task, not a job.
Rewrite it: "When stakeholders disagree about what to build next, I want everyone to surface their real reasoning, so I can build consensus around a decision the whole team will commit to." Now you can imagine anonymous voting tools, facilitated workshops, decision journals, structured debate formats. That's a job. The solution space just opened up.
Why teams collapse the space too early
Part of the problem is social. JTBD workshops often happen with the wrong mix of people in the room. When engineers, designers, and PMs all sit together to write jobs, there's an invisible pressure toward the concrete. Engineers want something buildable. PMs want something measurable. The group converges toward solution language because abstract language feels unproductive.
The other problem is that nobody wants to look like they don't know what they're doing. Writing a genuinely open JTBD statement - one that doesn't gesture toward a solution - requires admitting you don't yet know what the answer is. That takes confidence. In a room where seniority is visible, it's the junior people who most often ask the naive questions that crack open the real job. Those questions get suppressed.
This is why the quality of JTBD statements correlates strongly with how psychologically safe the room is. In hierarchical rooms, you get user stories. In open rooms, you get jobs.
From statement to ideation
A well-written JTBD statement doesn't just describe the problem. It acts as a generative constraint for what comes next. When you feed a strong statement into an ideation session, you get genuinely divergent ideas. When you feed a weak one, you get the same ideas your team already had.
The goal of writing the statement is to make the next step - generating ideas, evaluating options, making a decision - faster and sharper. Teams that skip this work or do it carelessly end up validating solutions that were chosen implicitly before anyone started. The JTBD statement is how you surface that implicit choice and interrogate it before it becomes a roadmap item.
Go deeper
Once you have strong JTBD statements, the next challenge is generating ideas against them - without the loudest voice in the room dominating the direction. Bandos's product ideation tool runs AI-assisted ideation against your defined jobs, so you get a breadth of options before the team starts filtering. From there, anonymous voting lets everyone rank the options without seniority bias shaping the outcome.
Turning this into something you can use with your team
Here’s a compact checklist you can apply directly in a JTBD workshop, based on the distinctions you outlined:
1. Use this exact structure
As a [type of person in a specific situation], I want to [functional goal], so I can [concrete, testable outcome].
- If the middle clause sounds like a feature, rewrite it.
- If the last clause sounds like a vague aspiration ("be more productive"), rewrite it.
2. Tighten the persona (context + pressure)
Ask:
- What role is this person in?
- What moment are they in?
- What pressure or risk are they feeling?
Weak: "As a user on a product team…"
Strong: "As a product manager onboarding a new executive who is questioning the roadmap…"
Litmus test: can everyone in the room picture a specific real person they know who fits this?
3. De‑feature the "want" (no solution words)
The want should be functional, not prescriptive.
Weak (solution):
- "I want a shared document everyone can edit."
Strong (job-level):
- "I want to explain my team's product reasoning clearly."
Rewrite moves:
- Ban nouns that imply a specific solution category: dashboard, document, board, canvas, template, chat, API, integration, plugin.
- Replace them with verbs that describe progress: understand, explain, align, decide, reassure, anticipate, avoid, recover, prove.
If you can infer the UI from the want, it’s too narrow.
4. Make the outcome testable (what actually changes?)
Ask:
- What would be observably different in their world if this worked?
- What would they avoid, gain, or be able to skip?