Most requests arrive as a solution. My job is to find the real problem first.

A request is a clue, not a brief

When a team asks for a feature, the feature is the visible tip of something they have already decided. Underneath sits a job the customer is trying to get done, and the feature is one guess at how to help. If I build the guess without testing the job, I might ship something that works exactly as specified and still misses. So the first move is always 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 gives me the lens. People do not want a quarter inch drill, they want a quarter inch hole, and sometimes they want a picture on the wall and the hole is itself a guess.

Interview the moment of switching, not the opinion

The richest discovery input is not what people say they want, it is 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 am 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?

Map the four forces, then design against the ones holding people back

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 forces 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.

Widen with intent, then narrow with discipline. Twice.

JTBD tells me what to look for. The Double Diamond tells me when to open up and when to close down. The hard part is not the diverging or the converging on their own, it is resisting the urge to collapse to a solution before the problem is actually understood. The first diamond is about the problem: explore it widely in Discover, then sharpen it to a single 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 do not leave a phase without it.

The problem statement is the contract everything else answers to

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

Scope is alignment written down before anyone builds

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 will know it worked, in language the whole team has agreed to. It does not 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 will not ship without.

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

Rank against the problem, then defend the cut line

A requirement set is only useful once it is 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 of the exercise is not the list, it is the line drawn through it: what makes the first release and what waits. Holding that line is the facilitation work, managing the natural tension as scope wants to expand and the calendar wants it to narrow.

A process, run in the open

This is the spine behind the case studies on this site, not a theory I admire from a distance. Range is the clearest example: an iOS rehab form coach where the discovery work, the job analysis, and the four Double Diamond phases are documented as their own artifacts, so the reasoning is visible and not just the finished screens. 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.