10 "how might we" questions: five good, five bad, and why
Ten real-world style how might we examples, five that open up good ideas and five that kill them, with the reason and a better version for each.

10 "how might we" questions: five good, five bad, and why
A good "how might we" question turns a well-understood problem into an invitation for many different ideas: it names who it is for, keeps the real tension in view, and leaves the solution open. A bad one either hides a solution inside it, is so broad that nothing useful follows, or is so narrow that only one answer fits. Below are five of each, with what makes them work or fail and how to fix the bad ones.
The phrase is usually traced to Min Basadur, who used it in creative problem-solving work at Procter & Gamble; it later spread through IDEO and the Google Ventures Design Sprint. The three words do a specific job. "How" assumes an answer exists. "Might" says any answer is allowed for now. "We" makes it a shared problem.
Every example below comes from a short, invented situation so you can see the question in context.
Five good questions
1. "How might we help first-time applicants know their documents are complete before they leave home?" Situation: a licensing office where many visitors are sent away for missing papers. It works because it names a specific group, a specific moment ("before they leave home") and a result the applicant would recognise. It does not say how: a checklist, a phone call, a partner office or a redesigned form all fit. When a question carries a moment in time, ideas become concrete quickly.
2. "How might we make waiting for test results feel less uncertain for patients?" Situation: an outpatient clinic where results take several days. It accepts a constraint the team cannot change (the lab time) and targets what they can change: the experience of waiting. This is often where the best ideas sit. If you are stuck, ask which part of the problem is fixed and write the question about the part that is not.
3. "How might we let new graduates find the right person to ask in their first week?" Situation: a large employer where new hires say they feel lost. It is small enough to try something next month and broad enough for very different ideas: a buddy system, a "who knows what" map, a weekly open hour. Good questions are often deliberately modest. A big ambition is best broken into several questions like this.
4. "How might we turn the queue at the service counter into time customers find useful?" Situation: a utility company's customer centre. This one deliberately flips a negative into a positive. Reframing a pain point as an opportunity is a classic move and it can unlock ideas the team would never reach by "reducing" things. Use it carefully: it should sit alongside a question about shortening the queue, not replace it.
5. "How might we get two departments to share one version of the client file without changing either system this year?" Situation: a bank where sales and service keep separate records. It states the constraint openly. Constraints are not the enemy of creativity; hidden constraints are. When a question admits what cannot change, the ideas that come back are ones the organisation can actually use.
Five bad questions, and how to fix them
6. "How might we build an app for booking appointments?" The solution is already in the question, so every idea will be a type of app. Ask what the app was meant to achieve. Fixed: "How might we let patients choose a time that suits them without having to call during working hours?" Now an app is one idea among several, alongside a text reply system or evening phone lines.
7. "How might we improve the customer experience?" Too broad to generate anything specific. Ideas will be generic ("better service", "friendlier staff") because the question gives nothing to hold on to. Fix it by going back to your problem statement and picking one group and one moment. Fixed: "How might we help customers who move house transfer their account in a single contact?"
8. "How might we reduce complaints by 20% by the end of the year?" This is a target, not a question. It belongs in a plan or an objectives and key results set. Put a number in a HMW and people optimise for the count, often by making complaints harder to file. Fixed: "How might we resolve a billing query the first time a customer raises it?" Measure the result afterwards.
9. "How might we get staff to accept the new system?" It assumes the decision is made and the only problem is the people. Ideas will be persuasion tactics, and staff will feel it. If the decision really is made, ask about their experience of the change instead. Fixed: "How might we make the first two weeks on the new system feel manageable for counter staff?"
10. "How might we use AI to transform our operations?" It starts from a technology, not a need, and "transform" is too vague to test. This question usually comes from enthusiasm at the top, which is worth respecting but not worth copying into the workshop. Find the operational pain first. Fixed: "How might we cut the time assessors spend retyping information from scanned forms?" Then AI is a candidate, judged against other options.
Do's and don'ts
Do
- Write HMW questions only after you have a problem statement based on evidence. The point-of-view format is a useful bridge.
- Write several questions from one problem, each from a different angle: a smaller part, the opposite, a constraint, a different user.
- Test each question by asking: could five very different ideas answer this? If not, widen it. Could almost anything answer it? Then narrow it.
- Pick two or three questions for the idea session, not ten.
- Read the question aloud to someone who was not in the room. If they cannot picture who it is for, rewrite it.
Don't
- Don't put a product, a channel or a technology in the question.
- Don't put a number in it.
- Don't write questions that blame a group ("How might we make citizens read the instructions?").
- Don't write a HMW for a problem you have not checked with the people who have it.
- Don't treat "how might we" as a magic phrase. A vague question in the right words is still vague.
Illustrative example
Illustrative. A public library service in Canada wanted more teenagers to use its branches. The team's first question was "How might we build a teen app?", the bad pattern in item 6. They stepped back and spent two afternoons talking to teenagers in two branches.
They learned that teens did come in after school, but mostly to find a quiet, safe place to do homework, and many left when tables filled up. The team wrote three new questions: "How might we make sure there is somewhere to sit after school?", "How might we help teens get homework help without asking at the front desk?", and "How might we let teens shape one corner of the branch?"
Each question produced a different set of ideas in a short brainwriting round. The app did not disappear, but it ended up as a small booking feature for study tables, not the starting point.
Questions people ask
How do you write a good "how might we" question? Start from an evidence-based problem statement. Name who it is for and the moment or situation, keep the real tension in view, and leave the solution out. Then check that it could be answered by several very different ideas.
How many "how might we" questions should we write? Write many, often ten to twenty from one problem, then choose two or three to take into idea generation. Writing more helps you find the angle that opens up the most useful ideas; choosing a few keeps the session focused.
When in the process should I use "how might we"? Between defining the problem and generating ideas. It works best once the team understands the problem from research and has agreed a problem statement. Used too early, it turns guesses into questions.
Where to go next
The how might we guide walks through writing and choosing questions on a canvas. Before it, use the point-of-view and problem tree guides; after it, generate ideas with brainwriting or lotus blossom. Read how to write a problem statement for the step before, and see the hub guide which innovation tool should I use.