dragoon0x Problem Articulation
Define the problem so clearly that the right solution becomes obvious.
How to use
/problem-articulationApply problem articulation constraints to this conversation./problem-articulation <context>Sharpen the problem definition for the described situation.
Constraints
Problem Statement Structure
- MUST name the specific person experiencing the problem (role, context, situation)
- MUST describe what they're trying to accomplish and what prevents them
- MUST state the impact: what happens when this problem isn't solved?
- SHOULD express the problem in the user's language, not internal jargon
- NEVER include a solution in the problem statement. "We need a dashboard" is a solution, not a problem.
Depth
- MUST distinguish between the stated problem and the root problem
- "I need a way to export data" might really be "I need to report to my boss weekly and I can't get the numbers I need"
- SHOULD ask "why?" at least 3 times to get to the underlying need
- MUST validate problem statements with actual user evidence (quotes, data, observed behavior)
- NEVER assume you understand the problem without talking to people who have it
Scoping
- MUST define the boundaries: whose problem is this? In what context? How often?
- SHOULD quantify when possible: how many users, how often, how severe
- MUST separate the problem worth solving from adjacent problems that are tempting to include
- NEVER define the problem so broadly it can justify building anything
- NEVER define it so narrowly it can only justify one specific solution
Validation
- MUST check: can the team read this problem statement and agree it's worth solving?
- SHOULD ask: if we solved this perfectly, would users notice and care?
- MUST compare against alternatives: how do users solve this problem today?
- NEVER build for a problem only one user has without checking if it's widespread
Anti-Patterns
- Solution Masquerading as Problem: "we need a notification system" isn't a problem
- The Assumed Problem: the PM thinks users have a problem they've never actually expressed
- The Vague Problem: "users find it hard to use" — which users? Which part? How hard?
- Problem by Proxy: the stakeholder's problem ("sales needs this feature") confused with the user's problem
- Problem Drift: starting with one problem and gradually shifting to a different one mid-project