Jobs to Be Done

Jobs to be done describes demand by what somebody is trying to accomplish and the circumstances driving them, rather than by who they are. The formulation that made it famous: people do not buy a product, they hire it to do a job.

That shift changes what counts as competition. A B2B reporting tool competes with other reporting tools, and also with the spreadsheet, the analyst who builds the deck by hand, and the decision to keep guessing. Anything hired for the same job is a competitor, regardless of category.

Where it came from

The framework has several parents and no single author. Clayton Christensen made it widely known, most visibly through Harvard Business Review in 2016. Tony Ulwick developed the outcome-driven version at Strategyn, which is far more quantitative. Bob Moesta built the switch-interview practice that most product teams actually use.

The versions differ enough in method that "we do JTBD" tells you little on its own. They agree on the core: describe the situation and the progress, not the person.

Writing a job statement

The usable shape is situation, motivation, outcome:

When I finish a month-end close, I want to know nothing was missed, so I can sign off without rechecking.

Each part does work. The situation names when the need arises, which is the part teams omit and the part that makes the statement testable. The motivation is the progress being sought. The outcome is how the person knows they got it.

Two failure modes are common. A statement with no situation ("users want confidence in their data") is a preference, not a job, and it cannot be argued with. A statement naming your product ("when I use our dashboard") has assumed the solution and can no longer question it.

Jobs against personas

They are not rivals. A persona says who is in the room; a job says what they came for. The reason JTBD gets adopted as a replacement is that personas so often degrade into demographics that change no decision, and a job cannot degrade that way because it has no demographic slot to fill.

In B2B the two have to be combined. The economic buyer, the admin and the daily user occupy one account and hold different jobs, and a product serving only the buyer's job gets bought and not used.

Researching it: the switch interview

The method that produces the most is interviewing people who recently switched, in either direction, and reconstructing the timeline.

Start at first thought. When did you first realise the old way was not working? What happened that day?

Find the trigger. Something turned a background irritation into an active search. It is usually an event rather than a realisation: an audit, a new hire, a failure, a deadline.

Ask what they tried. Including the things that were not products. Spreadsheets, a colleague, doing nothing.

Find the anxieties. What almost stopped them from switching. In B2B this is usually migration effort, a fear of looking foolish internally, or a contract.

Ask about the first week after. What made them keep going, or what nearly sent them back.

Recent switchers are worth several satisfied long-term customers, because the job is visible in the switch and invisible in the habit. Somebody who has used a product for three years can no longer tell you why they chose it.

Where it earns its keep in B2B SaaS

It names the real competition. Most B2B products lose to a spreadsheet and an existing process, not to a named competitor, and a competitive analysis that only lists vendors misses where the deals actually go.

It explains churn better than exit surveys. Somebody leaves because the job changed, or because something else started doing it better. Both are more actionable than "price".

It cuts feature debates. A request that cannot be traced to a job is usually somebody's preference. This is the least comfortable use of the framework and often the most valuable.

It travels between teams. Sales, product and design arguing about a job statement are arguing about the same thing, which is not true of a persona.

Using it without turning it into a religion

The framework attracts unusually devoted practitioners, and some of the argument between them is not useful to a product team.

Pick one method and be explicit about it. Switch interviews, outcome-driven statements and job maps are different practices under one name. Saying which you are running prevents a room from nodding at three different things.

Do not force everything into job form. Some work is maintenance, compliance or paying down design debt, and it does not need a job statement to be justified.

Keep the statements few. A product has a handful of jobs worth organising around. A list of forty is a feature list with different formatting.

Revisit them. A job is stable while the situation lasts, and situations change. A statement written before a market shifted describes a demand that may no longer exist.

In practice

A team believes customers want more reporting features, because that is what the requests say.

Switch interviews with recent customers reconstruct a different picture. The trigger is nearly always the same event: a board meeting where somebody could not answer a question about last month. What they want is not more reports; it is the ability to walk in knowing nothing is missing.

That job reframes the roadmap. More report types serve it weakly. A completeness check, an anomaly flag and a summary that says explicitly what changed serve it directly, and none of them appeared on the feature-request list, because customers request solutions they can imagine rather than describing the progress they want.

Where teams get it wrong

• Job statements with no situation. A preference dressed as a finding.
• Naming your product in the job. The solution assumed before the question.
• Interviewing happy long-term users. The job is invisible once it is habit.
• Treating it as a replacement for personas. One says what, the other says who, and B2B needs both.
• Adopting the vocabulary and not the method. "We do JTBD" describes three different practices, and often none of them.