User research often produces strong insights that never turn into anything. Teams finish weeks of interviews, fill a wall with sticky notes, and still walk into the next planning meeting with a list of features instead of a list of problems. The gap is rarely a shortage of data. The gap is the absence of a good question.
“How Might We” (HMW) questions are a structured way to close that gap. An HMW question takes a research insight and reframes it into a creative, team-oriented prompt — one that opens up the solution space instead of jumping into it. The framework comes out of the design thinking tradition associated with IDEO and is widely used at organizations like the Nielsen Norman Group, IDEO’s Design Kit, and most modern product teams.
The sections below cover what HMW questions are, why they work for product teams, how to write them step by step, ready-to-use templates, common pitfalls, a worked B2B CRM case study, and how to connect HMW questions to your PRD and roadmap. By the end, you should be able to take a messy insight and turn it into a question your team can actually build against.
Why Research Insights Often Disappear
After a few weeks of UX research, most teams hit one of two failure modes.
The first is that insights stay too abstract. Statements like “users feel anxious during onboarding” or “the setup flow is confusing” sound useful, but they do not tell anyone what to build, change, or test. They describe a feeling without a footprint.
The second is the opposite problem: the team skips reflection and jumps straight to solutions. Designers and PMs start proposing features within minutes — “let’s add a tooltip,” “let’s redesign the dashboard,” “let’s send a welcome email.” The output is a list of fixes for symptoms rather than a response to the underlying cause.
When a roadmap meeting opens with a list of features instead of a list of questions, the team has skipped ideation. A roadmap without good questions is a map without a direction.
The HMW question lives in the space between these two failure modes. It bridges insight and potential concept, and it remains one of the most practical tools available during design ideation. It forces the team to pause long enough to ask the right question before answering it.
What Are “How Might We” Questions?
A How Might We question is a structured way of turning an insight into a generative, open-ended prompt. Each word in the phrase does specific work:
| Word | What it does |
|---|---|
| How | Assumes a solution exists and is reachable |
| Might | Invites exploration rather than commitment |
| We | Frames the work as collaborative, not individual |
Together, the three words push a team toward divergent thinking without losing focus. That is why HMW questions sit so naturally between UX research and ideation: they preserve the constraint that the research surfaced while opening up the range of possible responses.
The format is also deceptively simple. “How might we help new users feel confident during setup?” looks like a basic question, but it does three things at once. It commits to the user (new users), commits to the outcome (confidence during setup), and refuses to commit to a method. That refusal is the point.
A good question sets direction without dictating the answer. HMW questions are designed to do exactly that — every team member can look at the same prompt and explore a different path toward it.
Why HMW Questions Are Powerful for Product Teams
HMW questions are useful beyond design workshops. For product teams in particular, they offer four concrete benefits.
- They let you widen or narrow scope on purpose. If a problem feels too large, you can sharpen the question. If the team is stuck in a narrow corner, you can broaden it. The framing itself is a scope control.
- They align cross-functional stakeholders. When engineers, designers, marketers, and PMs gather around the same HMW question, they are working from the same context — even when their proposed answers differ wildly.
- They prevent solution bias. Starting from a question rather than an answer keeps the exploration honest. The team is less likely to defend a pre-baked solution if no one has named one yet.
- They preserve shared understanding over time. Projects drift. Six weeks in, the team can return to the HMW and check whether the work still serves it.
In short, HMW questions turn abstract research findings into ideas a team can act on. That is what they do for a product team.
Reframing Insights with HMW Questions
The clearest way to see how HMW works is to watch an insight get reframed in real time.
A typical research insight looks like this:
“New users churn because the initial setup feels overwhelming.”
Without HMW, the team’s next move is often a solution: “add a setup wizard,” “shorten the form,” “default the values.” With HMW, the team pauses and reframes the same insight as a question:
“How might we help new users feel confident during the initial setup?”
Three things change in the reframe:
- The underlying problem stays intact. The friction at setup is still the target. The reframe does not erase the insight; it carries it forward.
- The solution space opens up. “Confidence during setup” can be solved through copy, defaults, animation, social proof, progressive disclosure, or something nobody has named yet. The question does not foreclose any of these.
- Multiple directions become explorable at once. The team can run several ideation branches in parallel, each anchored to the same prompt.
A team’s exploration path depends almost entirely on how the question is phrased. Stop at “problem statement” and your team narrows. Move forward to “explorable question” and your team opens up.
How to Write Effective HMW Questions (Step-by-Step)
Writing good HMW questions is a craft. The steps below cover the workflow most product teams follow once they get comfortable with the format.
Step 1. Start from organized research
HMW is a tool that runs after exploratory research, not during it. You need synthesized insights, not raw data, before you can write a useful HMW question.
Useful inputs include:
- A clear problem statement
- Synthesized key insights
- A design brief (if you have one)
- Patterns surfaced from qualitative and quantitative data
If the insight underneath is fuzzy, the HMW question on top of it will be fuzzy too. Ingredient quality determines recipe quality.
Step 2. Write several versions of the same question
A single HMW question is rarely the right one. Write three to five versions from the same insight at different levels of scope.
| Scope | HMW question |
|---|---|
| Wide | How might we reduce first-time user anxiety? |
| Medium | How might we make initial setup feel lightweight? |
| Narrow | How might we help users experience a small success in the first five minutes? |
The “right” HMW usually emerges through discussion, not before it. Do not try to find the perfect phrasing on the first attempt. Treat the variants as a way to surface what the team actually cares about.
Step 3. Use the HMW as the anchor for brainstorming
Once a working HMW is chosen, it becomes the anchor for ideation. Brainstorming rules at this stage are simple:
- Prioritize quantity early
- Defer judgment in the first pass
- Encourage unreasonable ideas
Because every participant is responding to the same question, the ideas can diverge wildly while still pointing in the same direction. This is the moment in design ideation where HMW earns its keep.
Step 4. Converge — prioritize and refine
Divergence must be followed by convergence. After the brainstorm, the team’s job is to:
- Cluster similar ideas
- Rank them by impact vs. effort
- Test the surviving ideas against real constraints (technical, business, timeline)
If new information arrives during convergence, update the HMW. A good HMW evolves with what the team learns.
Good vs. Bad HMW Questions: Examples and Patterns
Not every HMW question is equally useful. A badly written HMW can constrain a team just as much as jumping to a solution would. Two patterns make HMW questions go wrong, and three patterns make them go right.
What a bad HMW question looks like
(1) The question already names a solution.
“How might we add a tutorial popup for new users?”
The popup is already chosen. There is no room to explore other approaches — visual cues, defaults, onboarding tasks, social context — because the team has committed to a delivery mechanism before discussing the problem.
(2) The question is too vague or abstract.
“How might we improve the user experience?”
There is no user, no context, no constraint. The question is technically open, but the openness is useless — there is no starting point for ideation, and the ideas that emerge will be equally generic.
(3) The question is so broad it cannot be acted on.
“How might we make the product better for everyone?”
No scope, no prioritization, no acceptable trade-off. Questions at this altitude tend to signal that the team has not yet done the thinking required to write a usable HMW.
What a good HMW question looks like
(1) Focused on an outcome, not a solution.
“How might we help first-time users feel confident completing setup?”
The outcome is named (“feel confident”), but the method is left open. The question invites copy changes, UI changes, defaults, animations, or onboarding tasks — any of which might be the answer.
(2) Scoped to a specific user and context.
“How might we reduce uncertainty in the first five minutes of onboarding?”
The time window, the user, and the situation are all named. The constraint is what makes the ideation productive — narrow problems generate more inventive answers than wide ones.
(3) Open in the right way — with explicit tension.
“How might we guide new users through onboarding without overwhelming them?”
The “without overwhelming them” clause makes the trade-off explicit. The team has to hold two goals in mind at once, which leads to richer discussion than a single-goal question would.
Good HMW questions share a property: they refuse to name the answer while keeping the team pointed at the same problem. Finding the space between “too wide” and “too narrow” takes practice.
Ready-to-Use HMW Question Templates
When the team gets stuck on phrasing, a structured template helps. Two templates cover most situations.
Template 1: The full HMW template
How might we help [specific user] achieve [desired outcome] in [specific context] without [key constraint]?
Example:
How might we help new users achieve a successful first setup in their first session without feeling overwhelmed?
This template forces three useful things into the question:
- Clarity — the user and the outcome are named
- Explicit trade-offs — the “without” clause surfaces the constraint
- Solution-bias prevention — the focus stays on outcome, not method
Template 2: The lightweight workshop template
For fast-moving workshop sessions:
How might we help [user] be able to [action or outcome] when [situation]?
Example:
How might we help new users be able to feel confident when they open the product for the first time?
Templates act like training wheels. Filling them in is enough to produce a structured question on the first try; over time, the team develops its own variations and the templates fade into the background.
Common Pitfalls to Avoid When Using HMW
Even teams that know the HMW format well fall into a few recurring traps. Three are worth naming explicitly.
Pitfall 1: Locking in the HMW too early
Early HMW questions are exploratory drafts, not final commitments. Locking them in too early causes the team to miss:
- New findings that surface during research
- Constraints discovered mid-project
- Unexpected insights from stakeholders or users
The fix: revisit and revise the HMW as the team learns. The first draft is a starting point, not a contract.
Pitfall 2: Using HMW to justify a pre-baked solution
This pitfall is subtler. When a team already has an answer in mind, HMW becomes theater — a process performed to validate a decision that has already been made.
The symptom is that ideation feels forced. Every “new idea” sounds suspiciously close to the pre-baked answer.
The fix: stop and ask the team two questions. Are we genuinely open to a different approach? Or are we confirming a decision we have already made? If the second is true, name it. Either commit to the decision openly or restart the exploration.
Pitfall 3: Skipping convergence after ideation
HMW supports divergent thinking, but PMs have to lead the convergence. Without it, you end up with:
- A fun brainstorm that produces no outcome
- A team that loses trust in the process
The fix: plan convergence before the session starts. Decide in advance how ideas will be clustered, how decisions will be made, and how the surviving ideas will land in the roadmap.
Case Study: Sharpening an HMW Question in a B2B CRM Product
Theory only goes so far. The clearest way to see how an HMW question evolves is to walk through one in a real product context.
Product: a B2B SaaS CRM tool
Target user: small business owners
Critical moment: the first login after sign-up
Observed problem: a meaningful share of users churn without ever creating their first contact
Step 1. Synthesize the initial research insight
User interviews and funnel data converged on a single insight:
“New users log in, do not know what to do next, and leave. They sit in front of an empty dashboard, hesitate, and abandon the product without adding a single contact.”
This is already a useful insight. It names where the problem happens (the empty dashboard), what does not happen (the first contact is never added), and when it happens (right after first login).
Step 2. Start with a broad HMW
“How might we improve CRM user onboarding?”
This is related to the insight, but practically useless. The team would brainstorm everything from tutorials to email campaigns to entirely new product flows. Many teams stop here — and produce diffuse outputs as a result.
Step 3. Slightly better, but still wide
“How might we help new users get started with the CRM?”
Better, but still vague. “Getting started” means different things to different people. There is no success criterion, and the ideas will scatter.
Step 4. Anchor the question to a specific user action
Using the observed behavior data, we can sharpen the question:
“How might we help new users add their first contact?”
This is a meaningful jump.
- The action (“add a contact”) is concrete
- It connects directly to the churn point in the funnel
- Success can be measured cleanly
What is still missing is context — when, exactly, does this need to happen?
Step 5. Add the critical moment
“How might we help new users add their first contact during their first login?”
Now the team knows which session matters (the first one), what success looks like (the first contact is added), and what they do not need to solve right now (later sessions).
Step 6. Surface the real tension
User interviews surfaced a quote that changed the framing:
“I do not even know if this tool is worth using — and you want me to set things up first?”
The tension is now visible: users are being asked to configure before they have any reason to trust the product. That tension belongs in the HMW.
Sharpened HMW: “How might we help new users add their first contact during their first login without requiring system setup?”
This version is powerful for three reasons. It explicitly rules out the complex initial setup that most CRMs default to. It challenges the basic pattern of the category. And it invites creative alternatives — defaults, sample data, paste-from-clipboard, contact-from-email — that the earlier versions would not have surfaced.
Step 7. Make the question actionable
A final pass turns the HMW into something the design and engineering teams can directly work against:
“How might we let users add a contact from an empty dashboard within 60 seconds, with no prior setup?”
At this point, engineers can react to feasibility, designers can prototype, and the PM can define success metrics. This HMW now flows naturally into a PRD.
Why this sharpening process matters
Comparing the first and last versions makes the value of the process obvious.
| Step | HMW question | Verdict |
|---|---|---|
| Step 2 | “Improve CRM onboarding” | Too wide |
| Step 7 | “Add a contact in 60 seconds, from empty dashboard, no setup” | Actionable |
The difference is the difference between talking about a problem and being ready to solve one. Sharpening a question is like focusing a lens: the blurry shape becomes a specific scene, and the team can see what needs to happen.
From HMW Question to PRD and Roadmap
One of the most common misconceptions about HMW is that it is a design-only activity. In practice, HMW does its strongest work when a PM connects it to execution.
1. Make the HMW the single source of truth before writing the PRD
PMs usually start a PRD from one of three places: a feature idea, a stakeholder request, or a competitive gap. All three are dangerous starting points because they begin from a solution, which makes it easy to skip the problem.
Instead, treat the HMW question as the single source of truth for the problem the PRD is solving.
Example HMW:
“How might we help new users complete onboarding in their first session without feeling overwhelmed?”
This one question pins down:
- The user — new users
- The definition of success — onboarding completion
- The emotional constraint — without overwhelm
Everything in the PRD that follows should be traceable back to this question. If a section of the PRD cannot be tied to the HMW, that section probably does not belong.
2. Translate the HMW into PRD inputs
The HMW should not turn directly into a feature spec. It should populate the inputs of the PRD.
(1) Problem statement. Distill the HMW into a tight problem statement:
“New users do not complete onboarding because of cognitive overload, which causes early churn.”
Keep the intent of the HMW, but do not lock in a solution.
(2) Goals and success metrics. Ask: “If this HMW were answered well, what would change?” The answers become your metrics:
| Metric type | Example |
|---|---|
| Quantitative | Onboarding completion rate |
| Time-based | Time to first success |
| Qualitative | First-session confidence (from user feedback) |
(3) Constraints and principles. The “without…” clause in the HMW is gold for a PM. It tells design and engineering what not to do:
- Without lengthening the onboarding flow
- Without adding more screens
- Without relying on human support
Constraints are direction, not restriction. The clearer the “without…” clause, the more creative the team can be inside the boundary it draws.
3. Use ideation outputs as PRD options
After the brainstorm, resist the urge to immediately pick one idea. Instead:
- Cluster ideas by approach — guidance, simplification, progressive disclosure, and so on
- Identify the themes
- Analyze the trade-offs of each approach
Then bring this work into the PRD:
- List the approaches explored
- Summarize the trade-offs of each
- Document the chosen direction and the rationale
| Effect | Why it matters |
|---|---|
| Stronger alignment | Every team member sees why this direction was chosen |
| Stakeholder trust | The PRD shows that alternatives were considered |
| Decision history | Future readers can answer “why did we go this way?” |
4. Connect the PRD to the roadmap
Roadmaps that list “solutions” age badly. Roadmaps that communicate bets on user problems age well. HMW makes the second style possible.
Weak roadmap item:
“Onboarding flow redesign”
Stronger roadmap item (HMW-based):
“First-session user confidence and onboarding completion”
The internal flexibility of an HMW-based roadmap item is the whole point:
- Specific solutions can change
- Scope can be adjusted
- But the problem stays stable
That is why HMW-based roadmaps tend to outlive feature-based ones. Features change. Problems do not.
5. Use the HMW as a basis for saying “no”
PMs cannot avoid saying no. The HMW gives that “no” a neutral basis.
When a new request comes in, ask:
- How does this request help us answer our HMW?
- Which HMW does this request actually support?
If there is no clean answer, the request gets a lower priority — and the decision is no longer a personal judgment call. It is an alignment call.
A Simple Mental Model for Product Managers
The whole flow collapses into a short loop:
+---------------------------+
| How Might We? | → Define the right question
+---------------------------+
↓
+---------------------------+
| PRD | → Explore possible answers
+---------------------------+
↓
+---------------------------+
| Roadmap | → Decide which question to answer next
+---------------------------+Teams that work this way tend to stay:
- User-centered — they start from problems, not features
- Outcome-oriented — they measure progress in outcomes, not outputs
- Cross-functionally aligned — design, engineering, and business gather under the same question
Conclusion
Great product teams do not just ship features. They maintain clarity as ideas move from research into execution. HMW questions are one of the most reliable tools for that — not because the format is magical, but because three words (“How might we”) force a small but powerful shift in how a team thinks.
The shift is from solutions to problems, from individuals to collaboration, from perfection to exploration. Those are simple-sounding changes, but they change what a team builds.
If your team has rich research but messy notes, the work happens before HMW: structure the evidence first, then write the question. For the upstream step — turning unstructured qualitative input into usable insights — the KJ Technique is a natural companion to HMW.
Once the inputs are clean and the question is sharp, HMW gives a team a way to walk from an insight all the way to a roadmap item without losing the user at any step along the way.
Leave a Reply