How I turn a request into a plan a team can build.

Start with what the customer is trying to get done

A feature request is one guess at how to help a customer with something they are trying to do. If you build the guess without checking the need behind it, you can ship exactly what was asked for and still miss.

So I first separate the request from the outcome. What is the customer trying to get done, and what would count as progress for them? That is Jobs to be Done: people use a product to get a job done. The classic example is that people don't want a quarter inch drill, they want a quarter inch hole. Often they really want a picture on the wall, and the hole is also just a guess.

Interviewing people about the last time they switched

What people say they want is less useful than what they actually did the last time they switched to something new. A switch interview walks through that moment step by step, from the first sign of trouble to the decision.

I listen for what pushed them away from the old way and what pulled them to the new one. I listen just as closely for the worries and habits that nearly stopped them. Opinions about features are easy to give. The story of a real switch shows what the job is.

• First thought. When did the old way first stop working for them? This is often weeks before they did anything.
• Trigger. What happened that made them start looking?
• Comparing. What options did they compare, and what almost stopped them?
• Deciding. What made them decide, and what felt better once they had switched?

The four forces that decide whether someone switches

Jobs to be Done names four forces at work when someone considers a change. Two move them toward it: the push of a bad situation today and the pull of something better. Two hold them back: worry about the new thing and the habit of the old one.

Teams usually spend their effort making the new thing more attractive. Reducing the worry and making the habit easier to break often matter as much. Mapping all four shows me where the design work is.

The Double Diamond: when to explore and when to decide

Jobs to be Done tells me what to look for. The Double Diamond tells me when to explore widely and when to narrow down. The hard part is not jumping to a solution before the problem is understood.

It runs twice. The first diamond is about the problem: explore it in Discover, then boil it down to one statement in Define. The second is about the solution: try many options in Develop, then pick one and ship it in Deliver. Each phase has an output, and I don't move on without it.

Writing the problem statement

Define is where most projects succeed or fail. If the problem statement is too broad, scope keeps growing. If it is too narrow, it already assumes a solution.

I write it as one sentence: who has the problem, the job they are trying to do, and the gap between where they are and where they want to be. Every later decision is checked against it. If a feature doesn't help with that problem, I can cut it.

What goes into the scope document

Research only helps if the team can see it. The scope document writes down the problem, the bet, and how we'll know it worked, in words the whole team has agreed to.

It doesn't freeze the plan. It makes changes visible, so a change means a conversation instead of a surprise. These are the sections I always include.

A note on unshipped work: if a project hasn't launched, success is a measurement plan, not a table of results. I say how the bet would be measured instead of making up numbers.

Ranking requirements and deciding what ships first

A list of requirements is only useful once it is in order. I rank features against the problem statement and group them by priority, so the team builds first whatever tests the bet fastest.

What matters most is the line through the list: what goes in the first release and what waits. Keeping that line is part of my job, because scope tends to grow while the schedule gets tighter.

Where this process shows up on this site

The case studies on this site follow this process. KeySign is the clearest example. The request was a real estate app. The job behind it turned out to be the twenty minutes after a buyer says yes at the curb.

Naming that job narrowed everything. Working offline stopped being a feature request and became the bet, because phone signal often drops in a driveway. The process is also what lets me show my thinking, not just the result.