How I turn a stakeholder request into a problem worth solving.

Finding the job underneath the requested feature

When a team asks for a feature, the feature is the visible tip of something they've already decided. Underneath sits a job the customer is trying to get done, and the feature is one guess at how to help. Build the guess without testing the job and you can ship something that works exactly as specified and still misses. So the first move is to separate the ask from the outcome. What is the person hiring this product to do, and what would count as progress for them? Jobs to be Done is the lens. People don't want a quarter inch drill, they want a quarter inch hole. Sometimes they want a picture on the wall, and the hole is itself a guess.

The switch interview, and the timeline it reconstructs

The richest discovery input isn't what people say they want. It's the story of the last time they switched to something new. A switch interview reconstructs that timeline: the first thought that something had to change, the trigger that made it urgent, the alternatives they weighed, and the moment they committed. I'm listening for the forces that pushed them off the old way and pulled them toward the new one, and just as carefully for the anxieties and habits that nearly kept them put. Opinions about features are cheap. A real timeline of a real switch is where the job reveals itself.

• First thought. When did the old way first feel inadequate? Often weeks before any action.
• Trigger. What event turned a vague dissatisfaction into an active search?
• Consideration. What did they compare, and what almost stopped them?
• Commit. What finally tipped them, and what did progress feel like once they had it?

The four forces that decide whether someone switches

Every switch is a tug of war. Two forces drive progress: the push of the current situation and the pull of the new approach. Two resist it: the anxiety of the unknown and the habit of the present. A product wins not only by increasing the pull, which is where teams instinctively spend, but by reducing the anxiety and loosening the habit, which is where the quiet wins live. Mapping the four forces tells me where the real design work is.

The Double Diamond, and when to open up or close down

JTBD tells me what to look for. The Double Diamond tells me when to open up and when to close down. The hard part isn't diverging or converging on their own. It's resisting the urge to collapse to a solution before the problem is understood. The first diamond is about the problem: explore it widely in Discover, then sharpen it to one statement in Define. The second is about the solution: generate options widely in Develop, then commit and ship in Deliver. Each phase has an output, and I don't leave a phase without it.

Writing the problem statement the rest of the work answers to

The waist of the first diamond is where most projects are quietly won or lost. A problem statement that's too broad lets scope creep in unchallenged. One that's too narrow bakes in a solution before it was earned. I write it as one sentence naming who has the problem, the job they're trying to do, and the gap between where they are and the progress they want. Once it exists, every later decision is measured against it. A feature that doesn't move the problem statement is a feature I can cut without guilt.

What goes into the scope document

Discovery is worthless if it stays in my head. The scope document is where the converging lands. It states the problem, the bet, and how we'll know it worked, in language the whole team has agreed to. It doesn't lock people into a final plan, but it makes any change visible, because a change to the document means a conversation, not a surprise. These are the rows I won't ship without.

A note on unshipped work: if a project hasn't launched, success is a measurement plan, not a results table. I state how the bet would be evaluated rather than inventing numbers it hasn't earned.

Ranking requirements and drawing the cut line

A requirement set is only useful once it's ordered. I stack rank features against the problem statement and group them by priority, so the team builds in the sequence that proves or disproves the bet fastest. The point isn't the list. It's the line drawn through it: what makes the first release and what waits. Holding that line is the facilitation work, managing the tension as scope wants to expand and the calendar wants it to narrow.

How this process shows up in the work on this site

This is the spine behind the case studies on this site, not a theory I admire from a distance. KeySign is the clearest example: the request was a real estate app, and the job underneath it turned out to be the twenty minutes after a buyer says yes at the curb. Naming that narrowed everything. Offline first stopped being a feature request and became the bet, because a driveway is where the signal dies. The process is what lets me show the thinking, not only the outcome. Widen with intent, converge with discipline, and write the scope down before anyone builds.