Write 'When… I want to… so I can…'.
What it really is
On the surface, Writing a Job-To-Be-Done statement can look like a single technique you either know or you don't. The real skill underneath is starting from the user's real problem and turning it into something worth building — and that's the part that actually transfers from one situation to the next. Here it shows up as a concrete, repeatable habit: write 'when… i want to… so i can…'.
Why it matters
Building the right thing beats building the thing right. A Delta finds the problem worth solving before writing the code.
What good looks like
- You separate the literal request from the underlying job.
- You can name who the user is and what they're really trying to do.
- You prioritize by impact, not by what's easy.
Common trap
Taking the feature request at face value and skipping the "why."
How to practice
The rep: Write 'When… I want to… so I can…'.
Do it on a real problem, not a hypothetical — under the kind of pressure where it's tempting to skip. Land it and you earn the Jobs to Be Done badge. Repeat it until it stops feeling like a technique and starts feeling like instinct.