Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Framing the Problem  ›  Capstone Project

Problem Statements and How Might We

Problem Statements 14 minA problem statement names who is affected, what they need, why, and the evidence, without naming a solution, and a well-sized How Might We question turns it into an open invitation for ideas.

Problem Statements and How Might We

LunchLoop's team is ready to design, and a brief arrives: "Design a morning Skip button for the home screen." It sounds helpful. It is also a trap, because it has already chosen the answer before anyone has explored the question. A good problem statement keeps the problem sharp and the solutions open. A How Might We question then turns it into an invitation to ideas.

The rule

State the problem without the solution, then open it with "How might we".

A problem statement has four parts:

  • Who: hybrid office workers on a LunchLoop plan.
  • Need: to change a lunch on the day itself.
  • Why (the insight): their plans change after the 9 p.m. cutoff.
  • Evidence and impact: 12% of tiffins come back untouched; 70% of those changes surface in the morning; waste is a leading reason people cancel.

Together: "Hybrid office workers need to change a lunch on the day itself, because their plans shift after the 9 p.m. cutoff. Today 12% of tiffins come back untouched, and waste is a leading reason people cancel."

Nothing in it says button, screen or notification. "Users need a morning Skip button" would be a solution dressed as a problem.

A How Might We (HMW) question reopens the problem for ideas. "How" assumes it can be solved, "might" allows many answers, "we" makes it shared. Size matters:

  • Too narrow: "HMW add a Skip button to the home screen?" It has one answer, already built in.
  • Too broad: "HMW fix office lunch?" Nobody knows where to start.
  • About right: "HMW let subscribers change today's lunch without leaving cooks with extra food?"

Write several HMWs from different angles, such as "HMW turn an unwanted tiffin into something useful?", and pick the most promising.

The shortcut

Scan for feature nouns: button, screen, toggle, notification, dashboard. If one appears in the problem statement, a solution has sneaked in. Then size the HMW: can you name three very different answers quickly? None means too broad or too vague; only one means too narrow.

From brief to How Might WeStep 1 of 4

  1. The brief as written

    "Design a morning Skip button for the home screen." The noun "button" gives it away: this is a solution.

Drills

Answer fast — trust the rule.

quick drill

Which of these is a problem statement rather than a solution?

quick drill

"How might we fix lunch for every office in India?" is…

quick drill

"How might we add a Skip button to the home screen?" is…

quick drill

What does evidence add to a problem statement?

Remember

  • State the problem without the solution, then open it with "How might we".
  • Shortcut: hunt for feature nouns, then check you can name three different answers to the HMW.
  • Trap: a brief that names a button has already skipped the design work.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainFrame the cooks' problem

LunchLoop's cooks are left with extra food when subscribers cancel late. Write a problem statement for this, then write one too-narrow, one too-broad and one well-sized How Might We question, and say why each is sized the way it is.