How to write How Might We questions from vague customer problems
Find the one step or moment where the problem happens, write the question around what the customer wants, and leave the fix out. 'How might we help people past the step where most stop' beats 'How might we improve onboarding'.
This is for anyone who has stood in front of a workshop wall covered in sticky notes that say things like "customers drop off during onboarding". The problem is real. As written, nobody in the room can start work on it.
How Might We questions are the usual fix. You take the vague problem and rewrite it as a question that starts "How might we...", sized so a mixed group of developers, marketers, branch staff and managers can work on it together. A well-written How Might We question tells the room where to look. A badly written one sends people off in every direction at once.
Below are three vague problems of the kind we see on workshop walls at banks and insurers. Each one has a weaker and a stronger How Might We, and the reason the stronger one works better.
Customers drop off during onboarding: name the step where people stop
On a normal day this starts with a dashboard. Onboarding completion is down, someone writes "How might we improve onboarding?" on a sticky note, and everyone nods. Then the session goes nowhere. One person wants to redesign the app, someone else wants shorter forms, and someone from compliance explains why the ID check has to stay. "Improve onboarding" is so wide that the room ends up debating everything.
A better version is "How might we help people past the step where most stop?" Better still, find that step first and name it in the question. A single step is something a team can pull up on a screen. They can watch a customer try it, see where the customer hesitates, and start fixing that one screen.
Narrow work like this is where results come from. In a series of five-day design sprints with a large insurer, customer-facing web journeys that used to take six months or more were designed and tested with customers in two weeks and live in four. Completion rates on the new journeys rose 80 percent, and the previous drop-off points disappeared.
Customers keep calling about their claim: start from what the customer wants
The hotline keeps getting the same call. Where is my claim? The obvious How Might We is "How might we cut hotline calls?"
Fewer calls is a company target. It is a fair one, but a team can hit it without helping a single customer. Make the hotline number harder to find, add two more menu options, and the call count drops while customers get more annoyed.
Write the question around the customer instead: "How might we let customers check a claim without calling?" That points the room at what the customer is trying to do, and it opens up ideas like a text when the claim moves on or a status page they can check themselves.
Keep the call count, though. It becomes your before and after number. Count claim status calls over a normal few weeks before anything changes, then count again after the fix goes live. Plenty of teams skip the before number, and when the boss asks whether it worked, all they have is a shrug. Written down first, the call count answers that question.
Branch staff type the same details into several systems: fix the process before adding AI
Watch someone open an account at a branch and you may see the same customer details typed into one system, then keyed in again in the next. With every team under pressure to show something from AI, the tempting How Might We is "How might we use AI to fill in the forms?"
The trouble is that this question has already picked the fix. The room spends the session on how to build an AI tool and whether IT will allow it. Nobody asks why the same details have to go in more than once.
The stronger version is "How might we make sure details are entered only once?" It leaves the answer open. The fix might be connecting two systems, or dropping a form nobody reads, or an AI step somewhere. The team finds out by looking at the process before choosing a tool.
We hold this view firmly: AI on a broken process automates the failure. An AI tool that copies details into several systems faster still leaves several systems to keep in step. Fix the process first. If AI still has a job to do after that, you will know exactly what the job is.
What to do this week
- Pick one vague customer problem from your own work, from a workshop wall, a complaint log or a dashboard, and write it as a How Might We question.
- Check the question against the three tests above: it names one step or moment, it starts from what the customer wants, and it does not already contain the fix.
- Write down the before number now, while nothing has changed. That might be drop-off at that step, claim status calls per week, or how often the same details get typed in.
- Watch one customer or one member of branch staff go through the step in your question, and note where they slow down.
- Put the question in front of a mixed group, including at least one person who is not a designer, and see whether they can start work on it straight away.
Questions people ask
What is a How Might We question?
It is a vague problem rewritten as a question that starts 'How might we...'. A good one is narrow enough that a mixed group can start work on it in the same session.
Should a How Might We question mention AI?
Usually not. Once AI is in the question, the room spends the session on how to build the tool and never asks why the problem exists. Fix the process first, then see whether AI still has a job to do.
Where does the before and after number come in?
Keep the company target, such as the number of hotline calls, and use it as your measure. Count it before anything changes and again after the fix goes live, so you can show whether the fix worked.
On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. Who we are.
