Jobs to be done for product managers
Jobs to be done for product managers
Jobs to be done (JTBD) is a way I understand why customers “hire” a product or workaround to make progress in a specific situation. I use it when feature requests are noisy and personas alone are not explaining switching behavior. A job statement focuses on the progress people want, the context that triggers action, and the outcomes that count as success.
JTBD does not replace roadmaps, metrics, or delivery discipline. It sharpens the problem framing so those tools point at valuable work. When I skip the job and jump to solutions, I usually optimize the wrong surface.
What a job actually is
A job is the progress a person is trying to make in a circumstance. It is not a demographic label and not a feature. “Millennial marketers who like clean UI” is not a job. “When I am preparing a weekly performance review, I want to assemble channel results in one place so I can explain what changed without hunting through five tools” is closer.
I listen for situational triggers, struggles with current alternatives, emotional and social dimensions, and the criteria people use to judge a better solution. Functional progress matters, but so do anxiety, status, trust, and identity. People often stick with imperfect tools because switching feels risky even when the current job is painful.
This is why JTBD pairs well with product discovery interviews and with psychographic segmentation when motivations differ inside the same firmographic bucket.
How I research jobs
I interview recent switchers, almost-switchers, and people who evaluated us and chose an alternative. I ask what was going on in their world when they started looking, what they tried first, what almost made them give up, and what finally counted as “good enough.” Timeline questions beat hypothetical preference questions.
I also mine support tickets, sales call notes, cancellation reasons, community posts, and onboarding session recordings for repeated struggle language. Quantitative funnels tell me where people stall. JTBD research explains what progress they were attempting when they stalled.
I avoid forcing every insight into a rigid Mad Libs template on day one. I draft candidate job statements, pressure-test them with more interviews, and revise until a cross-functional team can recognize the same struggle in the wild.
Writing useful JTBD statements
A practical format I use is: When [situation], I want to [motivation/progress], so I can [desired outcome]. Then I add notes on constraints, success criteria, and competing solutions. The statement should be specific enough to guide design and prioritization, but not so solution-shaped that it secretly smuggles a UI idea.
Good statements help me reject attractive features that do not serve the job. If the job is assembling a trustworthy weekly narrative for leadership, a prettier chart library may matter less than reliable data joins, annotations, and export into the review ritual the customer already has.
I keep a small set of primary jobs for a product area rather than an encyclopedia. Too many jobs recreate the persona problem: everything looks important and nothing focuses the roadmap.
Turning jobs into product decisions
Once a job is clear, I map the current journey and friction. Where do people cobble spreadsheets? Where do they ask a teammate? Where do they abandon the attempt? That map often reveals higher-leverage opportunities than copying a competitor’s feature list.
I connect jobs to outcomes and experiments. If we believe a redesign helps the weekly review job, I define leading evidence such as successful report completion, time-to-insight, or repeat weekly usage among the target role. I also define counter metrics so we do not “win” the job for one persona while harming another critical workflow.
JTBD also improves messaging and packaging. Landing pages and sales narratives should promise progress on the job, not a tour of modules. When messaging attracts people with a different job than the product can serve, activation and retention suffer even if traffic rises.
Common JTBD mistakes
I watch for job statements that are really feature requests, jobs written only from internal opinions, and research that stops at happy-path users. I also watch for treating JTBD as a workshop poster that never changes backlog order. If prioritization does not move after the research, the work was theater.
Another mistake is ignoring the hiring and firing moments. People hire a product when the struggle becomes acute and fire it when a better path appears or trust breaks. Understanding those moments often matters more than average satisfaction scores.
Practical starting point
Pick one high-stakes workflow in your product. Interview five recent adopters and five people who evaluated and left. Draft one primary job statement, list the top three competing solutions, and identify the biggest friction before first success. Bring that package into prioritization before adding another feature bet. Pair it with market research when you need sizing and segment reality alongside the qualitative job story.
I also keep a living “job evidence” note next to the roadmap theme: interview date, quote, competing alternative, and the product gap it implies. That small habit stops JTBD from becoming a one-off workshop artifact and keeps discovery connected to delivery tradeoffs week after week.
Next step
Build stronger discovery, customer interviewing, and prioritization skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready lessons.
