think-problem-restatement

name	think-problem-restatement
description	Generates several genuinely different framings of an ambiguous problem by varying altitude, stakeholder, and goal-versus-implementation, then selects the most useful one to solve and produces a reframed problem statement with How Might We angles. Use when a problem is vague, arrived as a symptom or a pre-baked solution, or before committing significant work to solving the wrong thing.
license	Apache-2.0
metadata	{"id":"thinking-framework-skills.problem-restatement","family":"problem-framing","evidence-tier":"M/P","version":"0.1.0","standard":"0.8"}

Problem Restatement

The default failure is to solve a problem exactly as first stated, even though the first statement usually encodes a symptom, a presupposed solution, or one stakeholder's view. Problem restatement is a deliberate interrupt before solving: generate several genuinely different formulations of the problem, each by a distinct move (change altitude, separate goal from implementation, shift stakeholder, invert, bound with is/is-not), then choose the most useful one to work on. The output is a problem frame set ending in a single chosen working frame, not a longer list and not prose.

When to Use

• The problem is ambiguous, ill-defined, or stated as a symptom.
• The request names a solution ("build X") but the underlying goal is unstated.
• Solving the wrong problem would be costly; this is upstream of significant work.
• At the start of most reframing, discovery, or strategy workflows.

When NOT to Use

• The problem is already well-defined and validated; reframing a correct, clear problem wastes effort and manufactures doubt.
• For trivial or fully reversible tasks where a wrong frame costs little.
• To generate solutions (use an ideation skill) or to choose among them (use a decision skill); this tool only sharpens the problem.
• As endless reframing that avoids ever committing to solve. Restatement that never selects a working frame is the main failure mode.

Instructions

When asked to restate or reframe a problem, follow these steps:

1. Capture the problem as given. Record it verbatim. Note who framed it and whether it names a symptom or a presupposed solution.
2. Generate restatements with distinct moves, not rewordings. Produce 5 to 8 genuinely different frames using: altitude up ("what is this ultimately in service of?") and down ("what concretely is failing?"); goal versus implementation (separate the outcome wanted from the solution proposed); stakeholder shift (state it as each affected party would); inversion ("how would we cause this on purpose?"); and is / is not (what the problem explicitly is and is not).
3. Justify each briefly. For every restatement, add one line: why this might be the real problem.
4. Draw How Might We angles. From the most promising restatements, write 3 to 5 open "How might we ..." questions.
5. Select one working frame. Choose the single restatement that best serves the user's actual goal, and say in one or two sentences why. Converge; do not leave it open.
6. Emit the problem frame set. Produce the artifact in references/TEMPLATE.md: the original, the tagged restatement table, the How Might We angles, and the chosen working frame with rationale.

Output Format

Use the template in references/TEMPLATE.md. The deliverable is the frame set ending in one chosen working frame, not a prose essay.

Quality Checklist

Before finalizing, verify:

• Restatements use distinct framing moves (altitude, goal-vs-implementation, stakeholder, inversion, is/is-not), not cosmetic rewordings.
• The underlying goal is separated from any proposed implementation.
• At least one restatement challenges a load-bearing assumption (an inversion or an is/is-not).
• Exactly one working frame is selected, with a rationale tied to the user's actual goal.
• The output is the frame set artifact, not prose.
• No overclaiming: the skill sharpens the problem, it does not guarantee a better solution (see evidence/dossier.md).

Evidence

Tier M/P. That how a problem is framed affects the quality and originality of solutions has moderate support (problem-finding research, Getzels & Csikszentmihalyi and successors; Nutt on decision failure from poor definition), and design practice treats a tight problem statement as upstream of better ideation (Stanford d.school; Wedell-Wedellsborg, HBR 2017). The specific "restate it several ways" technique is practitioner-grade, and evidence is transferred from human studies, not AI-validated. The popular Einstein "55 minutes" quote is apocryphal and is not used as support. Full grading and caveats: evidence/dossier.md.

Examples

See references/EXAMPLE.md for a completed problem frame set.