Why requests arrive as solutions

People are good at noticing pain and bad at designing fixes for it. That isn't a criticism. They know their own work deeply but don't know what the software could do, what it costs to build or what other users need. So a request usually packs three things together:

• A goal: what they are ultimately trying to achieve.
• A pain: what gets in the way today.
• A proposed fix: their guess at a solution, often copied from another tool.

The goal and the pain are usually accurate. The proposed fix is the weakest part, because it is the part furthest from the requester's expertise. Programmers have a name for this pattern, the XY problem: someone asks how to do X, their attempted fix, when what they need is Y.

Building the fix without the other two parts has three costs. The pain may stay. You now maintain a feature forever. And the requester learns that the way to get help is to specify screens, so the next request is even more of a solution. On internal tools, where department heads can push requests through, this is how products fill up with buttons nobody uses.

The tool for unpacking a request is a ladder. Asking "why?" moves you up from the proposed fix toward the goal. Asking "how else could we get there?" moves you across to other solutions. You stop climbing when you reach a goal that is clear and worth solving, and that the requester agrees with.

Writing a problem statement

A problem statement is a few sentences that a whole team can agree on before discussing solutions. A useful one has five parts:

[Specific user] needs to [do something] but [obstacle],
which causes [measurable cost].
We know because [evidence].

Each part has a job. The specific user stops you designing for everyone. The need is written as something the user does, not something the software does. The obstacle is what gets in the way today. The cost needs a number, even a rough one, so you can compare this problem with others. The evidence says whether this is something you saw, measured or only heard.

Two rules keep problem statements honest. First, no solution words: if your statement contains "button", "dashboard", "app" or "AI", rewrite it. Second, mark the evidence level. "Measured from 6 weeks of data" and "one manager told us" are both useful, but they deserve different amounts of investment.

Five whys, done properly

The five whys comes from Toyota. Sakichi Toyoda developed it, and Taiichi Ohno, the architect of the Toyota Production System, described repeating "why" five times as the basis of Toyota's scientific approach. The idea is simple: when something goes wrong, ask why it happened, then why that happened, until you reach a cause you can fix so the problem doesn't come back.

Done badly, it is a guessing game. Done well, it follows five rules:

1. Start from a fact with a number. "1 in 12 goods received notes needs a correction" is a starting point. "Receiving is a mess" is not.
2. Answer each why with evidence. Data, an observation or the people who do the work. If you don't know, the next step is to find out, not to guess.
3. Branch when there is more than one cause. Real problems usually have several. A single neat chain often means someone ignored the others.
4. Never stop at "human error". Ask why the system made the mistake easy to make. Tired people at a busy dock will always make some mistakes. The question is why the design lets them through.
5. Stop at a cause you can act on. Five is a guide, not a rule. Stop when fixing this cause would prevent the problem and someone can own the fix.

The method has known weaknesses. Different people reach different causes from the same problem, and you can't find a cause you don't know exists. Both are reasons to run it with the people who do the work, at the place where the work happens, and to check each answer against data.

Jobs to be done

Five whys looks backwards at causes. Jobs to be done looks at what people are trying to achieve. The idea, made popular by Clayton Christensen, is that people "hire" a product to make progress in a particular situation, and "fire" it when something does the job better.

Christensen's best-known story is about milkshakes. A fast-food chain wanted to sell more of them. It asked customers who matched its milkshake-buyer profile how to improve the shake, made the changes, and sales didn't move. A researcher then spent a day in a restaurant watching who bought milkshakes and when. About 40 percent were bought first thing in the morning, by commuters taking them to go. Interviews showed the job: make a long, boring commute more interesting, with one free hand, and stay full until noon. The milkshake's real competitors were bagels and doughnuts, not other milkshakes. Once you know the job, the improvements are obvious: a thicker morning shake that lasts the whole drive.

Marketers have repeated a similar line since at least the 1940s, made famous by Theodore Levitt: people don't want a quarter-inch drill, they want a quarter-inch hole. A job has three sides. The functional side is the task itself. The emotional side is how people want to feel, such as not worried about a festival order. The social side is how they want to be seen, such as a store manager who doesn't look careless to head office.

A practical way to write a job is the job story format that Paul Adams described at Intercom:

When [situation], I want to [motivation], so I can [expected outcome].

The situation is the important part, because it explains why the need arises now. Three examples from different kinds of product:

• Consumer (Mangrove app): "When I'm halfway through cooking and find I'm out of one ingredient, I want it at my door in under 30 minutes, so I can still serve dinner on time." This job competes with walking to a corner shop and with asking a neighbour, not only with other grocery apps.
• B2B (Partner app): "When I've placed a big order before a festival weekend, I want to know it will arrive by Friday, so I can promise my regular customers and avoid buying from another wholesaler." This is what was behind Ravi's request for a call button.
• Internal (Store app): "When the truck driver is waiting to leave, I want to confirm the delivery matches the order in a few minutes, so I can sign without creating a wrong stock count."

Notice that none of them mentions a feature. Many solutions could do each job, and that is the point: a job story keeps the door open until you know which solution works best.

Finding the problem behind a feature request

Here is the method that ties the pieces together. It works for a one-line message from a department head and for a long list of asks from a vendor workshop.

1. Get the last real story. Opinions about the future are unreliable; stories about the past are not. Ask five questions, in this order:

1. "Tell me about the last time you needed this."
2. "What did you do instead?"
3. "What did that cost you: time, money, a complaint?"
4. "How often does it happen, and to whom else?"
5. "If this were solved perfectly, what would be different next month?"

Question 2 matters most. What people already do instead, their workaround, shows you the real job and how much they care. Someone who keeps a careful spreadsheet every week has a real problem. Someone who does nothing probably has a small one.

2. Size it. Rough size = how often × how many people × cost each time. "About 100 corrections a day × 25 minutes each" is about 40 staff-hours a day. That number lets you compare this request with everything else on your list.

3. Find the cause. Run five whys with data and the people who do the work.

4. Write it down. A problem statement and a job story. Share them with the requester and ask, "Did I get this right?" People who see their problem described accurately become your allies, even when you don't build what they asked for.

5. Decide. Four outcomes are possible: solve now (often what they asked, when the fix is cheap and obvious), solve differently (a better fix for the same problem), park with a reason and a date to revisit, or decline because it doesn't serve the outcome. Always reply to the requester with what you heard and what happens next.

Keep every request in a log, even the ones you decline. Five different requests often point at one underlying problem, and the log is how you notice. From research to opportunities turns logs like this into an opportunity map, and Product management for internal tools covers running request intake for a whole company.