The worry nobody can act on
Most operational problems arrive as a worry, not a problem. "Our reporting is a mess." "Onboarding takes too long." "The team keeps making the same mistake." These are real, and they're felt sharply by the people who say them. They're also unbuildable. There's nothing in the sentence a team can pick up and act on.
So the room does the natural thing. Someone proposes a fix. A dashboard. A new form. A rule. And the moment the first solution is on the table, the conversation quietly changes shape — from what is actually wrong here to how do we build the thing someone just suggested. The framing gets skipped, and the first idea becomes the brief.
The cost of that shortcut isn't obvious until later. A team can build the wrong thing efficiently. The demo works. The system ships. And six months on, the original worry is still there, because the thing that got built answered a question nobody had actually asked.
"How might we…" is the small move that sits in the gap. It takes the worry and turns it into a question a group can move on — without deciding the answer in the same breath.
What "how might we" actually does
The framework is three words, and each one is doing work.
How assumes a solution exists. It's not asking whether the problem can be solved; it's taking for granted that it can, and pointing the room at finding it. Might is permission. It says the answers on the table are candidates, not commitments — you can explore without anyone feeling they've been overruled. We makes it shared. The problem belongs to the group, not to the person who raised it or the person expected to fix it.
Put together, "how might we…" reframes a closed worry as an open, answerable question. Not "how will we fix reporting" — which demands a plan before anyone understands the problem — but "how might we…", which invites a range of ideas before committing to one.
The phrase isn't new. It traces back to Procter & Gamble in the 1970s, was popularised by the creativity researcher Min Basadur, and was carried into the mainstream by IDEO and later Google Ventures' design sprints. It has lasted because it does one thing reliably: it sits between defining a problem and generating ideas, and stops teams collapsing the two into one.
How to write a good "how might we" question
The mechanics are simple. Writing one that actually helps is not. A few things separate the useful from the decorative.
Start from an insight, not an assumption. The best "how might we" questions come out of something you've observed — a moment where the work broke down, a pattern in what people actually do. "Our reporting is a mess" is an assumption. "The site team re-enters the same numbers into three systems because none of them talk" is an insight. The second one gives you something to reframe.
Frame it from the user's need, not the feature. The question should describe the outcome someone needs, not the mechanism you have in mind.
Strip the solution out. If the answer is already hiding inside the question, you've written a task, not a problem.
Here's the move in practice:
- Worry: "We need a dashboard for the ops team." → How might we give the ops team a clear view of what needs attention today, without them chasing it across three systems?
- Worry: "Onboarding takes too long." → How might we get a new starter to their first useful contribution in their first week?
- Worry: "People keep skipping the safety check." → How might we make the safety check the easiest path through the work, not an extra step on top of it?
Notice what each rewrite does. It keeps the outcome and drops the assumed answer. A dashboard might be the right response to the first one — but so might an alert, a daily digest, or fixing the three systems that don't talk. The question left room for that.
Add the "so that…"
There's one extension worth making a habit: finish the question with a "so that…" clause that names the outcome you're actually after.
- How might we give the ops team a clear view of what needs attention today, so that they stop reconciling three systems by hand every morning?
- How might we get a new starter to their first useful contribution in their first week, so that they feel useful sooner and we see value sooner?
- How might we make the safety check the easiest path through the work, so that it stops being the step people skip under pressure?
The "so that…" does more than tidy up the sentence. It forces you to say why the problem matters, and that single clause quietly fixes the most common ways a "how might we" goes wrong. You can't smuggle a solution in — "how might we add a dropdown so that…" exposes itself, because the real goal turns out to be visibility, not a dropdown. And you can't drift too wide, because a vague question can't name a specific payoff. The outcome you write after "so that" becomes the thing you check the answer against later.
The Goldilocks trap
The most common way a "how might we" fails is scope, and it fails in both directions.
Too broad, and there's nothing to grab. "How might we improve operations?" is technically a how-might-we, but it could lead anywhere, which means it leads nowhere. A room faced with it either freezes or defaults to whatever idea is loudest. Broad questions feel ambitious and generate nothing.
Too narrow, and you've smuggled the solution back in. "How might we add a status dropdown to the intake form?" isn't a problem statement — it's a ticket wearing the costume of one. The answer is in the question, so the only ideas it produces are variations on a decision already made.
The fix is to move deliberately along that scale. When a question is too narrow, ask why until you hit the actual need: the dropdown was meant to help someone see what stage a job is at, so the real question is about visibility, not dropdowns. When it's too broad, ask what specifically until you hit something concrete: improving operations means, today, the three hours a week lost to reconciling two systems by hand.
A good "how might we" lives in the middle — wide enough that more than one answer fits, narrow enough that a team knows where to start.
Where it earns its place for us
We spend real time on this before we build anything, and it's deliberate.
The failure mode we write about most often is operational software that gets shipped and can't be owned — systems built fast, built to spec, and abandoned to decay the moment the people who understood them move on. A badly framed problem is the first cause of that. If the question was "build the thing someone suggested in the kickoff", the thing gets built, and whether it was ever the right thing is a question nobody asked in time to matter.
Getting the "how might we" right is cheap insurance against that. It's the difference between building the dashboard someone requested and building the visibility the team actually lacked. The first is easy to specify and easy to get wrong. The second is harder to pin down and far more likely to still be useful in a year.
It's also, honestly, one of the plainer things we brought back from a week on Westpac's Disruptive Leaders program in Singapore — a framing simple enough to use in any room, and surprisingly good at turning a vague worry into something a group can move on.
The question we ask
The real test of a "how might we" isn't whether it sounds good on the whiteboard. Plenty of them do. It's whether, a week later, the team can point at it and know what to build next.
If the question is too broad, they can't — it points everywhere. If it's too narrow, they don't need to — the answer was decided for them, and usually decided wrong. The one worth keeping is the one that still holds after the workshop energy has worn off: a problem clear enough to act on, and open enough that the best answer still has room to appear.
Get that question right, and most of the hard part of building the right thing is already done.
