Research often underperforms not due to lack of data, but because insights don’t consistently translate into ideation and this is exactly the gap that How Might We (HMW) is designed to address.
The Common Problem: When Research Insights Go Nowhere
After weeks of UX research, teams often face one of two problems:
- Insights stay abstract “Users feel anxious.” “Onboarding is confusing.” These sound meaningful, but they don’t guide action.
- Teams jump straight to solutions Designers and PMs rush to propose features:
- “Let’s add a tooltip”
- “Let’s redesign the dashboard”
The result? Solutions that treat symptoms, not root problems.
Tips for PM with Mustache
If your roadmap discussions start with features, not questions, you’re probably skipping ideation.
But when it’s time to design or build, teams jump straight into solutions that feel… obvious. This is where How Might We (HMW) comes in.
HMW is not just a UX exercise. It’s a bridge from insight to potential concepts—and one of the most practical tools in the design ideation process.
What Is “How Might We (HMW)”, Really?
The concept of How Might We is widely used in design thinking, including by organizations like IDEO and Nielsen Norman Group.
At its core, How Might We is a structured way to turn insights into productive, creative questions.
Each word matters:
- How → Assumes a solution exists
- Might → Encourages exploration, not perfection
- We → Reinforces collaboration over individual ownership
HMW reframes insights into questions that invite divergent thinking without losing focus. That’s why HMW sits perfectly between UX research and ideation.
Why “How Might We (HMW)” Is So Powerful for Product Teams
HMW helps teams:
- Expand or narrow problem space intentionally
- Align cross-functional stakeholders
- Avoid solution bias
- Maintain a shared understanding of the problem
It turns abstract research into actionable creativity.
“How Might We (HMW)” Reframing
A raw insight often sounds like this:
“New users abandon the product because the first setup feels overwhelming.”
But HMW forces a pause. Instead, we ask:
“How might we help new users feel confident during their first setup?”
Notice what changed:
- The problem is still there
- The solution space is now open
- The team can explore multiple directions
How to Craft Effective “How Might We (HMW)” Statements (Step-by-Step)
1. Start with Synthesized Research (Not Raw Data)
HMW works after exploratory research—not before.
Good inputs include:
- Problem statements
- Key insights
- Design briefs
- Patterns from qualitative and quantitative data
If the insight isn’t clear, the HMW won’t be either.
2. Reframe Insights Into Multiple HMW Variations
Don’t stop at one.
Take a single insight and write multiple HMW statements:
- Broad versions (to expand thinking)
- Narrow versions (to focus later)
Example:
- How might we reduce anxiety for first-time users?
- How might we make the first setup feel lightweight?
- How might we help users succeed within the first 5 minutes?
Refinement is iterative. The “right” HMW usually emerges after discussion, not instantly.
3. Use HMW as the Starting Point for Brainstorming
Once the HMW is set, it becomes the anchor for ideation.
Rules for brainstorming with HMW:
- Quantity over quality at first
- No judgment early on
- Encourage unconventional ideas
Because everyone is responding to the same question, ideas stay aligned—even when they’re wildly different.
This is where HMW shines in the design ideation process.
4. Converge: Prioritize and Refine Ideas
After divergence comes convergence.
Teams can:
- Cluster similar ideas
- Rank by impact vs. effort
- Test ideas against constraints (tech, business, timeline)
As new information emerges, update the HMW. Good HMWs evolve alongside learning.
Good vs Bad HMW Statements (With Real Examples)
Not all HMW statements are created equal. A poorly written HMW can be just as limiting as jumping straight to a solution.
Let’s look at the difference.
❌ Bad HMW Examples (And Why They Fail)
1. Too solution-focused
How might we add a tutorial popup for new users?
Why it’s weak:
- Assumes the solution
- Kills creative exploration
- Narrows ideation too early
2. Too vague or abstract
How might we improve the user experience?
Why it’s weak:
- No specific user or context
- Hard to brainstorm meaningfully
- Leads to generic ideas
3. Too broad to act on
How might we make our product better for everyone?
Why it’s weak:
- No constraints
- Impossible to prioritize
- Signals unclear thinking
✅ Good HMW Examples (And Why They Work)
1. Outcome-focused, not solution-focused
How might we help first-time users feel confident completing setup?
Why it works:
- Centers on user emotion
- Leaves room for multiple solutions
- Easy to ideate against
2. Clear scope, clear user
How might we reduce uncertainty during the first 5 minutes of onboarding?
Why it works:
- Time-bounded
- Context-specific
- Encourages focused creativity
3. Balanced openness
How might we guide users without overwhelming them during onboarding?
Why it works:
- Tension is explicit
- Trade-offs are visible
- Leads to richer discussions
A Practical HMW Template You Can Use Immediately
When teams struggle to write HMWs, structure helps.
Here’s a simple template that works well in real workshops:
How might we help [specific user] achieve [desired outcome] in [specific context] without [key constraint]?
Examaple:
How might we help [new users] achieve [a successful first setup in their first session] without [feeling overwhelmed]?
This template:
- Forces clarity
- Makes trade-offs explicit
- Prevents solution bias
Alternative Lightweight Template (Fast Teams)
For quick sessions:
How might we enable [behavior or outcome] for [user] when [situation]?
Example:
How might we enable [confidence] for [new users] when [they first open the product]?
Common How Might We (HMW) Mistakes Product Managers Make
Even experienced PMs misuse HMW. Here are the most common traps.
1. Locking the HMW Too Early
Early HMWs should be exploratory, not final.
A static HMW ignores:
- New research
- Emerging constraints
- Unexpected insights
Fix:
Revisit and evolve HMWs as learning progresses.
2. Using HMW to Justify a Pre-Decided Solution
This is subtle, but dangerous. If the team already knows “the answer,” HMW becomes theater.
Fix:
If ideation feels forced, pause and re-check:
- Are we truly open to alternatives?
- Or are we validating a decision?
3. Skipping Convergence After Ideation
HMW enables divergence, but PMs must lead convergence.
Without synthesis:
- Brainstorms feel fun but useless
- Teams lose confidence in the process
Fix:
Always plan:
- How ideas will be clustered
- How decisions will be made
- How insights map to roadmap bets
A Concrete Example: Narrowing HMW in a Real Product Context
Let’s make this tangible with a real-world scenario.
Product Context
- Product: B2B SaaS CRM tool
- Target user: Small business owners
- Key moment: First login after sign-up
- Observed issue: Many users never create their first contact
Step 1: Raw Research Insight
From user interviews and funnel data, we got an insight:
New users abandon the product because they don’t know what to do first after logging in. Many hesitate at the empty dashboard and leave without adding a contact.
This is not abstract anymore.
We know:
- Where it happens (empty dashboard)
- What doesn’t happen (adding first contact)
- When it happens (first login)
Step 2: Setting Up a Broad HMW
How might we improve onboarding for CRM users?
This technically relates to the insight, but it’s useless in practice. The team will brainstorm everything from tutorials to emails. This is where many teams stop.
They shouldn’t.
Step 3: Slightly Better, Still Broad
How might we help new users get started with the CRM?
Better, but still vague:
- “Get started” means different things to different people
- No clear success moment
Ideas will still scatter.
Step 4: Anchor to a Specific User Action
Now we sharpen the question using observed behavior.
How might we help new users add their first contact?
This is a big improvement:
- Clear action
- Directly tied to drop-off
- Easy to measure
But it’s still missing context.
Step 5: Add the Critical Moment
Let’s specify when the problem occurs.
How might we help new users add their first contact during their first login?
Now the team knows:
- Which session matters
- What “success” looks like
- What not to worry about (later usage)
Step 6: Surface the Real Tension
Users said:
“I don’t want to set things up before I know if this tool is worth it.”
That tension belongs in the HMW.
Sharp HMW: How might we help new users add their first contact in their first login without asking them to configure the system first?
Now this is powerful.
Why?
- It rules out heavy setup
- It challenges default CRM patterns
- It invites creative alternatives
Step 7: Execution-Level HMW (Almost PRD-Ready)
For design and engineering exploration:
How might we let users add a contact in under 60 seconds from an empty dashboard, without requiring any prior configuration?
At this point:
- Engineers can react
- Designers can prototype
- PMs can define success metrics
This HMW can now flow directly into a PRD.
Why This Narrowing Matters
Notice what changed from start to finish:
- ❌ “Improve onboarding”
- ✅ “Enable first contact creation in the first login, without setup friction”
That’s the difference between:
- Talking about problems
- Being ready to solve them
From HMW to PRD to Roadmap: A Practical PM Playbook
One of the biggest misconceptions about How Might We (HMW) is that it’s a “design-only” activity. In reality, HMW becomes truly powerful only when PMs use it to drive execution—from PRD to roadmap.
Let’s walk through how that actually works.
Step 1: Use HMW as the Problem Anchor (Before PRD)
Before writing a PRD, PMs often start with:
- Feature ideas
- Stakeholder requests
- Competitive gaps
That’s risky.
Instead, treat the HMW statement as the single source of truth for the problem.
Example HMW
How might we help new users complete onboarding confidently within their first session without feeling overwhelmed?
This HMW now defines:
- Who the user is
- What success looks like
- The emotional constraint
Everything in the PRD should trace back to this question.
Step 2: Translate HMW into PRD Inputs (Not Features)
HMW should not turn directly into feature specs. It should inform PRD inputs.
Here’s how PMs can map it:
1. Problem Statement (PRD)
From HMW → concise problem framing:
New users struggle to complete onboarding due to cognitive overload, leading to early drop-off.
This preserves the intent of the HMW without locking solutions.
2. Goals & Success Metrics
Ask:
“If this HMW is successfully answered, what changes?”
Examples:
- Increase onboarding completion rate
- Reduce time-to-first-success
- Improve first-session confidence (qualitative)
These metrics become PRD success criteria.
3. Constraints & Principles
The “without…” part of HMW is gold for PMs.
Example:
- Without increasing onboarding time
- Without adding more screens
- Without relying on human support
These turn into design and engineering guardrails.
Step 3: Use Ideation Output to Shape PRD Options
After brainstorming, PMs should resist the urge to pick one idea immediately.
Instead:
- Cluster ideas into approaches
- Identify themes (e.g., guidance, simplification, progressive disclosure)
In the PRD, reflect this as:
- Explored approaches
- Trade-offs considered
- Rationale for chosen direction
This creates:
- Stronger alignment
- Better stakeholder trust
- Clear decision history
Step 4: From PRD to Roadmap
Roadmaps shouldn’t list “solutions.” They should communicate bets on user problems.
HMW helps PMs do exactly that.
Bad roadmap item
“Redesign onboarding flow”
Better roadmap item (HMW-informed)
“Improve first-session user confidence and onboarding completion”
Under the hood:
- Multiple solutions may evolve
- Scope can flex
- The problem stays stable
This makes roadmaps:
- More resilient to change
- Easier to communicate
- Aligned with outcomes
Tips for PM with Mustache
Roadmaps anchored in HMW age better than feature-based roadmaps.
Step 5: Use HMW to Say “No” (Politely)
As a PM, saying no is inevitable. HMW gives you a neutral reference point.
When new requests come in:
- “How does this help us answer our HMW?”
- “Which HMW does this support?”
If there’s no clear link, deprioritization becomes easier and less personal.
A Simple Mental Model for PMs
You can think of it this way:
- HMW → Defines the right question
- PRD → Explores possible answers
- Roadmap → Commits to which questions we’ll answer next
This keeps teams:
- User-centered
- Outcome-driven
- Aligned across functions
Final PM Reflection
Great PMs don’t just ship features. They maintain clarity as ideas move toward execution.
Before Ideation, Start with Clarity
If you’ve reached the point where you’re ready to generate ideas but the data and research findings still feel scattered, you’re not alone.
Jumping straight into ideation without first making sense of messy inputs can lead to:
- lots of ideas, but no shared understanding
- team members interpreting signals differently
- solutions that miss the real user problem
Before you dive into How Might We statements or brainstorm sessions, it often helps to structure your evidence and align your team around what’s actually happening.
If that resonates, check out this guide next:
👉 KJ Technique: A Better Alternative to Brainstorming for Turning Messy Inputs into Clear Decisions