Problem Articulation

Define the problem so clearly that the right solution becomes obvious.

How to use

• /problem-articulation Apply 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