Skip to content

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.

  • 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.
  • 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.

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.

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

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).

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.

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

A full worked run (the shared Northwind scenario)

A completed run of the think-problem-restatement skill, on the shared Northwind scenario. This is the quality bar a generated frame set should meet.

Northwind is a B2B SaaS weighing a self-serve free-tier launch. (The same scenario the premortem example uses, so the library reads as one product. Restate the problem here, then a chosen option can be stress-tested with think-premortem.)


  • Stated problem (verbatim): “We need to build a self-serve free tier so we can hit our Q3 growth target.”
  • Framed by: Head of Growth.
  • Flags: Names a presupposed solution (“free tier”) for an unstated goal (“growth”). “Growth” itself may be a proxy. Sales and Finance viewpoints are absent.
#Restated problemMove usedWhy this might be the real problem
1How do we hit the Q3 growth target?altitude up (goal)A free tier is one means among several; the target is the actual objective.
2Why is our current self-serve signup-to-paid conversion too low to grow without a free tier?altitude down (concrete)The real failing may be a leaky funnel, not the absence of a free tier.
3What is the cheapest way to create qualified pipeline at the rate Q3 requires?goal vs implementation”Free tier” is an implementation; the goal is qualified pipeline and revenue.
4How do we grow without flooding Sales with unqualified free users to triage?stakeholder shift (Sales)Surfaces a cost/conflict the original framing hides.
5How would we guarantee a free tier fails to drive growth?inversionExposes the assumptions the free tier rests on: no cannibalization, ICP fit, bearable support and infra cost.
6This is a problem of insufficient qualified demand by Q3; it is NOT necessarily a problem of missing product packaging.is / is notBounds scope and challenges the leap from “we need growth” to “we need a free tier.”
  • How might we hit the Q3 target with the least irreversible commitment?
  • How might we raise qualified pipeline without degrading conversion or unit economics?
  • How might we test demand for a free tier before building it?
  • How might we grow in a way Sales and Finance both endorse?
  • Working frame: “How do we generate qualified pipeline at the rate the Q3 target requires, with the least irreversible commitment?”
  • Why: It keeps the real goal (qualified growth by Q3) central, demotes “free tier” from a given to one testable option, and pulls in the Sales and Finance constraints the original framing buried. It does not foreclose the free tier; it refuses to assume it.
  • Hands off to: option generation (e.g. SCAMPER on the growth approaches), then a decision skill to choose, then think-premortem on the chosen option.

Note: the value is in moves 3, 5, and 6. A naive reframe would reword “build a free tier” into “create a free tier”; the useful work is separating the goal from the implementation and exposing the buried assumptions and stakeholders.

What the research does and does not show, with graded sources

The single source of truth for the problem-restatement skill. The SKILL.md, the sidecar, and the eval cases all derive from this file. If a claim is not here, it does not belong in the skill.

Skillthinking-framework-skills.problem-restatement (installable name think-problem-restatement)
Familyproblem-framing
Evidence tierM/P (moderate for the general principle; practitioner for the specific technique)
ConfidenceHigh that framing affects outcomes; moderate that “restate it N ways” is the best operationalization
Statusdraft (authored 2026-05-31 from the discovery corpus)

1. The mechanism (what actually does the work)

Section titled “1. The mechanism (what actually does the work)”

The default failure is to solve the problem as first stated. The first statement is usually the user’s (or the model’s) initial framing, which often encodes a symptom, a presupposed solution, or one stakeholder’s view. Problem restatement is a deliberate cognitive interrupt before solving: generate several genuinely different formulations of the problem, then choose the most useful one to work on.

The restatements are not rewordings. Each is produced by a distinct move:

  • Change altitude (abstraction laddering): go up (“what is this in service of?”) and down (“what concretely is failing?”).
  • Separate goal from implementation: distinguish the outcome the user actually wants from the solution they proposed.
  • Shift stakeholder: state the problem as each affected party would.
  • Invert / negate: state the opposite, or “how would we cause this on purpose?”, to expose hidden assumptions.
  • Bound it (is / is not): sharpen scope by stating what the problem explicitly is and is not.

The work is done by escaping the initial frame before committing, and by selecting a working frame rather than drifting. The output is a chosen, better-justified problem to solve, not a longer list.

  • Design thinking / define mode: Stanford d.school design-thinking guidance treats “define” as producing the point of view that sets the right challenge, and notes a tightly framed problem statement yields more and better ideas downstream. (Practitioner; design-research lineage.)
  • Reframing in practice: Thomas Wedell-Wedellsborg, “Are You Solving the Right Problem?” (Harvard Business Review, 2017) - reframing as a repeatable executive practice; reports that most organizations routinely work on mis-stated problems.
  • Problem finding / problem construction: Getzels & Csikszentmihalyi (1976) and the problem-finding research that followed (Runco; Mumford et al.) link how a problem is constructed to the originality and quality of what is produced. (This is the moderate-evidence anchor.)
  • Decision failure from poor definition: Paul Nutt’s research on decision-making (“Why Decisions Fail”, 2002) attributes a large share of failures to premature, narrow problem definition and limited search.

No trademark. “Problem restatement” is a generic descriptive term; named descriptively here, lineage cited.

3. What the evidence shows, and what it does NOT show

Section titled “3. What the evidence shows, and what it does NOT show”

Reasonably supported (the M part):

  • How a problem is framed/constructed measurably affects the quality and originality of solutions. This is supported by problem-finding research (Getzels & Csikszentmihalyi and successors) and is consistent with design-research observations that tighter, well-chosen problem statements improve ideation output.
  • Poor or premature problem definition is a common, costly failure mode in real decisions (Nutt).

NOT shown (the honesty):

  • There is no strong, controlled evidence that the specific ritual of “restate the problem N ways” outperforms other framing aids, or that it improves final decision quality by a measured amount. The technique is practitioner-grade (d.school, Wedell-Wedellsborg); its mechanism (framing matters) has better support than its packaging.
  • The popular Einstein quote (“if I had an hour to solve a problem I’d spend 55 minutes on the problem”) is apocryphal and is not evidence. It is motivational folklore; do not cite it as support.
  • Effect sizes are not well established; treat claims as directional, not quantified.

Net grade: M/P. Frame-quality-affects-outcomes is moderate; the restatement technique itself is practitioner. The skill should claim the former and present the technique as a disciplined way to act on it, not as a proven intervention.

4. Transferred-evidence flag (required honesty)

Section titled “4. Transferred-evidence flag (required honesty)”

All evidence is from human design, creativity, and decision contexts. There is no direct study of an AI agent running problem restatement, or of whether an agent-produced reframe improves a human’s outcome. Evidence is transferred from human studies, not AI-validated. The AI value is concrete and does not depend on the contested claims: a model defaults hard to solving the first framing (it is obligingly literal), so an explicit restatement step is a high-leverage counter to that specific failure, and it produces a durable, inspectable artifact.

5. When it works / when it fails (drives “When NOT to Use” and eval anti-cases)

Section titled “5. When it works / when it fails (drives “When NOT to Use” and eval anti-cases)”

Works best when:

  • The problem is ambiguous, ill-defined, or arrived as a symptom or a pre-baked solution.
  • The stakes of solving the wrong problem are real (it is upstream of significant work).
  • The user supplied an implementation (“build X”) but the underlying goal is unstated.

Fails or misleads when (poor-fit / anti-patterns):

  • The problem is already well-defined and validated - reframing a correct, clear problem wastes effort and can manufacture doubt.
  • Reframing becomes procrastination - endless restatement with no selection of a working frame is the central failure mode; the skill MUST converge on one chosen frame.
  • Cosmetic restatements - reworded variants that do not actually shift altitude, stakeholder, or goal-vs-implementation are noise.
  • Trivial or fully reversible tasks where the cost of a wrong frame is negligible.
  • It is a framing tool, not an ideation tool (use SCAMPER / Question Burst to generate solutions) and not a decision tool (use Decision Option Review to choose among solutions).

A problem frame set: the original statement; a table of restatements, each tagged with the move used (altitude up/down, goal-vs-implementation, stakeholder, inversion, is/is-not) and a one-line “why this might be the real problem”; 3 to 5 “How Might We” angles drawn from the most promising restatements; and a single chosen working frame with a short rationale. The deliverable is the chosen frame plus the set behind it, not prose.

  1. Stanford d.school, design-thinking process guide (define mode; framing improves ideation quantity and quality). Practitioner/design-research.
  2. Wedell-Wedellsborg, T. (2017). “Are You Solving the Right Problem?” Harvard Business Review.
  3. Getzels, J. W., & Csikszentmihalyi, M. (1976). The Creative Vision - problem finding and creative performance. Plus later problem-construction work (Runco; Mumford et al.).
  4. Nutt, P. C. (2002). Why Decisions Fail - premature/narrow problem definition as a failure driver.

Verification status: citations 1-2 are well-attested and safe to cite. Citations 3-4 are correctly attributed in substance (problem-finding research; Nutt’s decision-failure work) but the exact page-level claims should be confirmed against the primary sources before any public-facing quantified claim. The Einstein quote is explicitly excluded as apocryphal.

Thinking Framework Skills v0.3.0 · 38 frameworks