How might we vs problem statement: when to use each in ideation

A problem statement names what is wrong: a short, factual description of the gap between where things are and where they should be. A How Might We question reframes that same gap as an open invitation to solve it, phrased so a team can answer with dozens of ideas. You write the problem statement first to get the diagnosis right, then convert it into How Might We questions to open the ideation.

They are two steps of one job, not competing tools, and mixing them up is why so many sessions stall. A team that jumps straight to How Might We without a problem statement solves the wrong problem beautifully. A team that stops at the problem statement stares at a diagnosis and waits for inspiration that never comes. This article covers what each one is, how they differ, exactly how to turn a problem statement into strong How Might We questions, and when to reach for which.

What is the difference between a problem statement and a How Might We question?

The difference is direction. A problem statement points backward at the cause: it fixes what the problem is, who has it, and why it matters, in language that is deliberately neutral and closed. A How Might We question points forward at the solution space: it takes the agreed problem and opens it up, in language that is deliberately optimistic and unfinished. One is a diagnosis you want to be correct. The other is a prompt you want to be generative.

Put plainly, the problem statement is where you slow down and get the facts straight, and the How Might We question is where you speed up and let the ideas run. The problem statement is judged on whether it is accurate and specific. The How Might We question is judged on whether it produces a lot of genuinely different answers. Confuse the two and you get a problem statement so hopeful it hides the real issue, or a How Might We question so narrow it only has one answer.

What is a problem statement?

A problem statement is a concise, evidence-based description of a specific problem that needs solving. A good one names the user or group affected, the need or gap they experience, and the reason it matters, without smuggling in a solution. In design thinking it often takes the point-of-view form: a specific user needs a way to achieve some goal because of some insight about their situation. The test of a problem statement is that a stranger could read it and understand the problem without you in the room.

What makes problem statements hard is the discipline to stay neutral. The moment you write "users need a dashboard," you have named a solution, not a problem, and every idea that follows is now a variation on a dashboard. The honest version is "users cannot tell at a glance whether their account is healthy," which leaves the door open to a dashboard, an alert, a weekly email, or something nobody has thought of yet. Grounding that statement in evidence rather than assumption is the real work, which is why teams anchor it in what users actually struggle with from usage data and feedback rather than a hunch from the last meeting.

What is a How Might We question?

A How Might We question is a problem reframed as a short, open question that invites solutions. The phrase itself does the work: "how" assumes a solution exists, "might" gives permission to explore without committing, and "we" makes it a shared effort. Popularized through IDEO and the Stanford d.school, and rooted in Min Basadur's earlier work on problem framing, the format is the standard on-ramp from framing to ideation because it is calibrated to produce range.

The craft is in the scope. "How might we redesign the checkout page" is too narrow: it presumes the checkout page is the problem and the answer is a redesign. "How might we make people happy" is too broad: it could mean anything, so it generates nothing usable. The useful altitude sits between them, wide enough that several very different ideas fit and tight enough that they are all about the same problem. Our guide to how to write a How Might We question works through the scoping test in detail with worked examples.

How might we vs problem statement, side by side

Read the table top to bottom and the handoff is obvious: the problem statement ends one stage and the How Might We question begins the next. That is why the strongest teams treat them as a pair. You do not choose between them any more than you choose between the diagnosis and the treatment; you do them in order.

How do you turn a problem statement into a How Might We question?

Take the problem statement, keep the user and the need, drop any implied solution, and rephrase it as a question that starts with "How might we." Then split it into two or three questions at different angles, because one problem statement almost always hides several distinct openings. The goal is not a single perfect question but a small set that attacks the problem from different sides.

Work an example. Problem statement: "New users cannot tell whether their account is set up correctly, so they abandon onboarding before reaching value." Strip the diagnosis language and open it up, and you get a family of questions: How might we show new users their setup is working? How might we get users to first value before setup is even finished? How might we make an incomplete setup feel safe rather than broken? Each is a different door into the same problem, and each will generate a different set of ideas. A useful trick from design facilitators is to run the problem statement through amplify, remove, and challenge-the-assumption lenses: how might we make the good part bigger, how might we remove the hard step entirely, how might we make the assumption wrong. That is the same forced-angle move a good SCAMPER session uses to break a group out of its first, obvious answer.

When should you use each?

Use a problem statement whenever you are about to commit time to solving something, and especially when a team is already arguing about solutions. Writing the problem down, neutrally, forces the group to agree on what they are actually solving before anyone falls in love with a fix. If a meeting is going in circles, the fastest way out is usually to stop and write the problem statement everyone has silently assumed is different.

Use How Might We questions the moment the problem is agreed and it is time to generate options. They are the standard opener for a brainstorm, a design sprint, or any structured design thinking ideation session, because they turn a settled diagnosis into fuel for divergence. The sequence almost never runs the other way. A How Might We question written before the problem is understood just locks in whatever the loudest person assumed, and no amount of clever ideation recovers from framing the wrong problem well.

How might we vs problem statement: common mistakes

The most common mistake is the hidden solution. A problem statement that reads "users need a mobile app" is a solution wearing a problem's clothes, and it quietly forecloses every non-app idea before the session starts. Strip solutions out of the statement and save them for after the How Might We questions have done their work. If you cannot describe the problem without naming a fix, you have not finished defining it.

The second mistake is scope drift in the question. Teams write How Might We questions that are really project briefs ("how might we increase quarterly retention by ten percent") or that are so tiny they contain their own answer. Aim for questions where you can already imagine three ideas that have nothing in common. The third mistake is skipping the statement entirely and opening with How Might We, which feels faster and costs more later, because a room full of energetic answers to the wrong question is harder to redirect than a blank page. Get the problem statement right, generate How Might We questions from it, and only then let the ideas run.

From framing to ideas

Framing is only worth doing if it leads somewhere. A sharp problem statement and two or three well-scoped How Might We questions are the setup; the payoff is a wall of genuinely different directions and a decision about which to pursue. That is the part where most teams stall, staring at a good question with a whiteboard full of the same three obvious ideas everyone already had.

The studio at the top of this page takes a How Might We question and runs it into two dozen directions in about thirty seconds, each tagged with the angle it came from, then clusters them into themes and scores them so you leave with a pick rather than a list. If you want the framing craft first, read how to write a How Might We question, and if you want to see how framing feeds a full session, the innovation workshop tool walks through the arc from problem to committed idea. Get the problem statement honest, open it with How Might We, and let a proper idea generator handle the range.