JTBD Story: job stories from the most recent actual case

What is JTBD Story?

JTBD Story is the Jobs-to-be-Done variant for when the actual sequence of events is still unknown. Instead of asking people to rate, it asks them to tell: in which situation a need arose, what they wanted to achieve and what they then actually did.

Many such accounts add up to job stories. They describe the need independently of today's solution — which lets you check whether a tool fits the need or whether it was the wrong need.

When does JTBD Story fit — and when doesn't it?

Story fits when your numbers claim something different from what you observe day to day. Typical questions:

• “Why do employees prefer asking colleagues over using the intranet?”
• “In which situation do tradespeople reach for the device?”
• “When does the customer actually open the app?”
• “Would the planned feature fit into a workflow at all?”

Story does not fit when you need a ranking — that is what JTBD ODI is built for. Nor when a specific switch or drop-off needs to be explained; JTBD Switch does that more precisely.

What does a job story look like?

Three parts: situation, motivation, desired outcome.

When I realize in the middle of a task that I'm missing an internal rule, I want to see an answer I can rely on in under a minute, so I can keep working without interrupting anyone.

The difference from a user story is how it begins. A user story starts with a role and often ends with a feature. A job story starts with a situation and ends with an outcome. The same situation can hit a purchaser, a service technician or a managing director — the job is the same.

How do you ask questions in a Story study?

About the most recent actual case, following the sequence of events. Three blocks have proven effective:

Block	Question	What it delivers
Trigger	“Think of the last time you …”	the situation in which the need arises
Path	“What did you actually do in that situation?”	workarounds, tools, people
Outcome	“How did you know you were done?”	the desired outcome and its obstacles

Two mistakes cost the most insight: asking about the general impression (“How satisfied are you …?”) and presupposing the answer (“Why do you use the intranet so rarely?”).

How is JTBD Story analyzed?

The accounts are grouped by recurring trigger situations and workarounds; job statements are formulated from the most frequent patterns. Done by hand, that means reading every account, coding it, counting patterns and reconciling wording.

The real value lies in the workarounds. People describe on their own what they do instead — ask a colleague, keep the old spreadsheet, send a screenshot to the chat. Each of these workarounds is an unmet job, and none of them shows up in any usage statistic.

Example: the need is there, only trust is missing

In the Intranet case study (in German), a company rebuilt its intranet for a six-figure sum. Four in ten employees never log in; management is considering shutting it down. 341 employees tell the story of their most recent case.

The most frequent pattern, derived from 118 matching accounts, is the job story above. The reasons for asking someone instead:

Reason	Share
Search doesn't find my word	31%
I don't know whether the page is still valid	28%
The answer is buried in a 40-page PDF	18%
A colleague answers in two minutes	14%

The need is frequent and urgent. What's missing is reliability: nobody trusts a page without a date. Shutting it down is rejected. Instead, every page gets a validity date and an owner, and the search learns the words the workforce uses.

What are the limits of JTBD Story?

• No ranking. Story shows what exists, not what comes first.
• Labor-intensive analysis. Accounts are free text. Without thorough grouping, you are left with a collection of quotes.
• Shares are orders of magnitude. With small case numbers, percentages show a tendency, not a representative distribution.
• Only what is remembered. What someone doesn't notice, they don't tell you about either.

How does JTBD Story work in usabiq?

JTBD Story is included from Research Core.

• AI theme detection on the accounts. Recurring trigger situations and workarounds are grouped, and job statements are formulated from them — with verbatim quotes as evidence.
• Traceable. Every statement leads back to the raw response. Themes can be expanded, renamed, merged and split; every assignment can be overridden individually.
• Large volumes. With a very large amount of free text, the model reads a sample balanced across sources; the shares are calculated against the full number of responses.
• Bias check while you build: leading and double-barreled questions are flagged before the survey starts.
• Participation via link, no account needed — including for employees without a desk computer, for example via a QR code on the notice board.
• Control over the AI. European providers can be selected, and a workspace switch disables all AI processing.