Every deck in the Case Studies section opens the same way: a single "How might we" statement. That is not a formality - it is the first checkpoint. Until the team, the users, the mechanism, and the outcome fit in one sentence, there is no shared problem to design against yet.
The template has four slots on purpose. "How might we" keeps the door open to more than one solution. "For" forces a specific audience instead of "users" in the abstract. "In a way that" names the mechanism - the actual lever being pulled - so the statement can’t hide behind a feature name. "So that" ties it back to a measurable business or human outcome, which is what keeps the rest of the process honest.
American Airlines - Flight Maintenance System
"How might we create a flight maintenance scheduling system for pilots and engineering teams, in a way that reduces the friction of communication when placing requests for repairs, so that the efficiency of workload and labor is optimized?"
Kraft Heinz - Predictive Maintenance
"How might we deliver a suite of predictive maintenance capabilities and inventory management for factories and distributors, in a way that optimizes downtimes in manufacturing and increases efficiency in labor, so that Kraft Heinz can drive revenue growth?"
A framing statement is ready to move forward on when it survives three checks:
- Read it out loud - if it names a feature instead of a mechanism, it is premature.
- Ask "so that, why does that matter" - if there is no confident answer, the outcome slot is still a guess.
- Show it to someone outside the team - if they cannot repeat the audience and mechanism back, it is not sharp enough yet.