THE SHORT ANSWER
Jobs to Be Done helps explain the progress an organisation seeks in a particular situation. For B2B SaaS, that requires more than a list of requested features. Investigate the work context, reason for considering change and conditions under which different participants would accept a new approach. The output should guide a specific decision rather than decorate a persona document.
To connect this decision with positioning, market entry and growth, read the pillar guide Go-to-market for B2B SaaS: turn market insight into an executable growth strategy.
Investigate a situation rather than a persona
Begin with a recent decision that someone actually experienced. A title such as head of IT does not explain why a change became important at that moment. Ask about the last difficult workflow and its consequences. The Christensen Institute describes jobs through desired progress within circumstances, including functional, social and emotional dimensions. Apply this perspective carefully to business buying: a technical task may also involve a person being accountable to management. Investigate these dimensions in the interview rather than assuming motivations from seniority, industry or a personality label. Explore this further in the guide Treat the status quo as a real competitor.
Reconstruct the decision over time
Ask for the sequence from initial discomfort to the eventual decision. Which workaround was attempted? When did another department become involved? What made the previous approach seem attractive again? Record turning points and separate participants’ statements from your interpretation. Chronological reconstruction discourages imposing an elegant retrospective explanation on a contradictory process. Where several people participated, interview different roles if possible. Conflicting recollections are a reason to investigate further. They should not automatically be smoothed into a single story simply because the team needs a concise presentation for an upcoming planning meeting.
Separate the job, outcome and solution
Describe the task independently of your product first. Then explain how participants would recognise improvement and which constraints matter. “Use a dashboard” already names a solution. “Resolve conflicting capacity information before allocating resources” describes a more useful task. Relevant outcomes might include traceable data and an agreed decision. Check whether your statement is too broad or narrow. If virtually every company fits, circumstances are probably missing. If only your current feature could satisfy the description, you may have disguised a product requirement as a job. Revise the wording against actual accounts of work. Explore this further in the guide Recognise and interpret B2B buying triggers.
Hypothetical example: dependable handovers
A fictional IT services firm apparently wants a replacement ticketing system. Interviews reveal that commitments to customers disappear during shift handovers. Procurement wants to preserve existing contracts, while staff want to avoid duplicate documentation. The relevant progress is therefore not simply centralising tickets; it is maintaining dependable handovers despite changing responsibility. The SaaS team checks integration constraints and demonstrates one real type of handover. Whether a purchase follows remains unknown. The investigation has clarified the meaningful work context, the conflicting conditions for acceptance and the limits of an appropriate offer before the supplier invests in a broad presentation.
Translate learning into testable decisions
Group findings by recurring circumstances, tasks and barriers, while preserving contradictory cases. Use the patterns to make a specific choice: narrow a segment, change a demonstration or test an integration assumption. A job statement does not replace market sizing or commercial viability analysis. It helps connect offers and messaging to recognisable situations. Attach evidence and an unresolved question to each implication. Colleagues can then distinguish patterns found across cases from a plausible hypothesis awaiting investigation. This also prevents a single compelling interview from silently becoming the foundation of the entire product marketing strategy.
Avoid common misapplications
Do not turn interviews into a vote on your roadmap. Customers can describe valuable situations without prescribing the best technical solution. Avoid assuming that an organisation has only one job or that every participant wants the same outcome. Revisit whether new customer groups operate under different conditions. If a pattern appears only among satisfied reference customers, include lost and deferred decisions. A useful result is an explanation with explicit boundaries and consequences for the next test. It is not a universal sentence intended to remain on every sales presentation indefinitely, regardless of changes in the market.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
Separate the job, outcome and solution
Describe the task independently of your product first.
Explore in the article ↗CHECKPOINT 02
Hypothetical example: dependable handovers
A fictional IT services firm apparently wants a replacement ticketing system.
Explore in the article ↗CHECKPOINT 03
Translate learning into testable decisions
Group findings by recurring circumstances, tasks and barriers, while preserving contradictory cases.
Explore in the article ↗Frequently asked questions
Does each persona have one job?
Not necessarily. The same role can seek different progress in different circumstances.
Are feature requests useless?
No. Use them as an opening to investigate the task, context and desired improvement.
Are successful customers enough?
They explain successful cases. Add other decision paths before generalising a pattern.
How can I put “Investigate a situation rather than a persona” into practice?
Begin with a recent decision that someone actually experienced. A title such as head of IT does not explain why a change became important at that moment. Ask about the last difficult workflow and its consequences.
What matters when working on “Reconstruct the decision over time”?
Ask for the sequence from initial discomfort to the eventual decision. Which workaround was attempted? When did another department become involved?
