Job stories

Agile user stories often look like: As a [role], I want [feature] so that [benefit]. They can help delivery, but they smuggle solutions ("I want a dropdown") and flatten circumstance.

Job stories emphasize situation and motivation so scope cuts do not gut the progress. Use them in discovery and in the problem section of a PRD. Use classical user stories later if your delivery process needs them — but keep the job visible.

Walking through the templates

Job story:

When [circumstance],
I want to [motivation / progress],
so I can [outcome].

When a client has not paid 14 days after the due date
and I am about to start new work for them,
I want to see payment status without opening my email,
so I can decide whether to start or pause without looking unprofessional.

That story does not demand a particular UI. It invites solutions: dashboard badge, Slack bot, automatic pause rule, deposit requirement. Compare to "As a freelancer, I want invoice reminders so that I get paid" — vaguer circumstance, easier to build the wrong reminder.

Full job statement for PRDs, interview guides and roadmap debates:

When [circumstance / trigger],
I am trying to [progress / verb phrase],
so I can [higher-order outcome].
I currently hire [workaround / product / person].
Success looks like [observable result].

When a client is 14+ days late and I am deciding whether to start new work,
I am trying to know payment status without digging through email,
so I can protect cash flow without looking desperate or unprofessional.
I currently hire a color-coded Google Sheet plus memory.
Success looks like a confident start/pause decision in under 30 seconds.

If a proposed feature does not clearly advance this progress, it is a different job (or noise).

Roadmaps that list features without job columns drift into competitor cloning. Job columns also reveal when two features fight (morning vs afternoon milkshake): you may need two modes, two segments or a hard choice.

Engineers can apply this without a workshop. Before a spike, write the job statement in the ticket. In product sense interviews, clarify circumstance and progress before listing features; name non-obvious competitors (including "do nothing").

Common mistakes

• User stories that name the widget. "I want a dropdown" is a spec.
• Job statements too broad to cut scope. "Be productive" cannot lose a feature.
• Features with no job column. You will clone the competitor.

Check yourself

Rewrite "As a freelancer I want invoice reminders so I get paid" as a job story.

When a client is 14 days late and I am about to start new work, I want payment status without opening email, so I can start or pause without looking unprofessional.

A pretty PDF theme lands on the backlog. What do you ask?

Does it advance this job, a social side-job, or a different job we should park?

Key takeaways

• Job stories keep circumstance and progress visible so delivery cannot gut them.
• Write who they hire today and what success looks like.
• Sort the backlog by whether a feature serves the job — or a different one.

Further learning

Know Your Customers' Jobs to Be Done (HBR)Firms have never known more about their customers, but their innovation processes remain hit-or-miss. Why? According to Christensen and his coauthors, product developers focus too much on building customer profiles an…Harvard Business Review

Back to the map in jobs to be done.