problem-framinglisted

# Problem Framing ## Coverage Problem framing covers the practices that move a team from a vague request, complaint, or feature brief to a sharply articulated problem statement that does not pre-commit to a solution. Core techniques include the **How Might We** reformulation (popularized by IDEO and the Stanford d.school), the **point-of-view statement** (`<user> needs <need> because <insight>`), **jobs-to-be-done** problem articulation (Clayton Christensen, Tony Ulwick), **assumption mapping** to surface what a team is taking on faith, and **5 Whys** style symptom-to-need laddering when a presenting issue masks a deeper one. The UK Design Council's Double Diamond names this entire phase **Discover → Define**, and treats the transition from divergent discovery to convergent problem definition as a distinct skill from solutioning. The practice draws a hard line between three things that beginners conflate: a **symptom** (an observed irritant), a **problem** (a structured statement of an unmet need), and a **solution** (a proposed intervention). A brief that says "add notifications" is a solution; "users miss time-sensitive updates" is a problem; "I keep forgetting to renew my license" is a symptom. Reframing techniques surface which level the team is operating at and explicitly demote solutions back to problems before ideation begins. A separate body of methods addresses **problems that are already solutions in disguise**. Tim Brown's HBR essay (2008) and the Stanford d.sch