Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Ambiguous problem scoping framework

Transforms a loosely defined business problem into a structured problem statement, explicit scope boundaries, a stakeholder and assumption map, and a prioritized list of open questions to resolve before work begins. Use…

download .md

Purpose

Convert a vague, contested, or sprawling business problem into a single sharp problem statement, defined in-scope and out-of-scope boundaries, and a ranked set of open questions that must be answered before solutioning. Eliminates the false starts and rework that come from teams solving the wrong problem or quietly disagreeing on what the problem even is.

When to Use

Invoke this skill when the user asks to:

  • Scope or frame a poorly defined problem before a project kicks off
  • Turn a vague complaint or symptom ("our retention is bad") into a workable problem statement
  • Resolve disagreement among stakeholders about what the actual problem is
  • Decide what's in scope and out of scope for an initiative
  • Surface the assumptions and open questions hiding inside a fuzzy request
  • Build a scoping doc or problem brief for an executive or sponsor

Inputs Required

Before starting, collect:

  • Problem as currently stated: The raw description, complaint, or request in the user's own words
  • Trigger: What made this surface now — an incident, a metric, a stakeholder, a deadline
  • Stakeholders: Who cares about this and what they each believe the problem is
  • Known constraints: Time, budget, team, technical, or political limits
  • Desired outcome: What "solved" would look like, even if fuzzy
  • What's already been tried: Prior attempts, decisions, or context worth knowing
  • Decision timeline: When a scope decision or solution direction is needed

If stakeholders or prior attempts are unknown, proceed and flag those as the highest-priority open questions.

Instructions

Step 1: Separate Symptom from Problem

Start by distinguishing what the user is observing from what's actually wrong.

  • Restate the problem as currently framed, verbatim or near-verbatim
  • Identify whether it's phrased as a symptom ("sales are down"), a solution in disguise ("we need a new CRM"), or a goal gap ("we're missing target")
  • Apply a 3-level "why" probe: ask why the stated problem matters, why that matters, and why that matters — to find the layer worth solving
  • Name the observable evidence vs. the assumed cause. Flag any place where a cause is being assumed without evidence.

Step 2: Draft the Structured Problem Statement

Produce one tight problem statement using this structure:

  • Who is experiencing the problem (specific role, segment, or system)
  • What is happening that shouldn't be, or not happening that should
  • Where/when it occurs (boundaries of the phenomenon)
  • So what — the cost or consequence of leaving it unsolved, quantified if possible
  • Why now — the trigger that makes this worth solving in this window

Write it as a single paragraph of 3–5 sentences. Then write a one-sentence "north star" version (under 25 words) that anyone could repeat.

Step 3: Define Scope Boundaries

Create three explicit lists so the team knows exactly what they are and aren't taking on:

  • In scope: 4–7 specific elements this effort will address
  • Out of scope: 4–7 specific elements deliberately excluded (and a one-line reason for each — adjacent problem, future phase, owned elsewhere, or constraint-blocked)
  • Boundary cases: 2–4 gray-area items that could go either way, with a recommendation and the question that would settle each

Be opinionated. Vague scoping is the most common cause of scope creep.

Step 4: Map Stakeholders and Competing Framings

For each stakeholder, capture:

  • Their framing: How they would describe the problem in one sentence
  • Their stake: What they win or lose depending on how it's framed
  • Tension: Where their framing conflicts with another stakeholder's

Then write a 2–3 sentence synthesis identifying the framing conflicts that must be reconciled before work proceeds.

Step 5: Surface and Classify Assumptions

List the assumptions the current framing depends on. Classify each as:

  • Load-bearing: If false, the whole problem definition changes — validate first
  • Material: Affects approach but not the core problem
  • Minor: Worth noting, low risk

Flag any load-bearing assumption that has no supporting evidence as a critical open question.

Step 6: Build the Prioritized Open Questions List

Generate 6–10 open questions that must be answered to move from scoping to solving. For each:

  • State the question precisely
  • Mark priority: P0 (blocks everything) / P1 (shapes the approach) / P2 (refines)
  • Note how to answer it: data pull, stakeholder interview, experiment, or document
  • Note who owns getting the answer

Order the list P0 → P2. The P0 questions are the user's immediate next actions.

Output Format

  • Structure: Six labeled sections in sequence, ending with the prioritized open-questions list
  • Length: 700–1,000 words
  • Format: Structured document — short prose for statements, bulleted lists for scope and assumptions, a table for stakeholder framings and the open-questions list
  • Sections: Symptom vs. Problem → Structured Problem Statement (+ north star line) → Scope Boundaries → Stakeholder & Framing Map → Assumptions → Prioritized Open Questions
  • Tone: A sharp internal strategy lead — direct, structured, comfortable naming disagreement and flagging what nobody has actually validated

Quality Checklist

Before delivering output, verify:

  • [ ] The problem statement names a who, what, so-what, and why-now — not just a restated symptom
  • [ ] The north star statement is one sentence under 25 words
  • [ ] In-scope and out-of-scope each contain 4–7 specific items, with reasons on the out-of-scope list
  • [ ] Every load-bearing assumption lacking evidence appears as a P0 open question
  • [ ] The open-questions list is ordered by priority and each item has an owner and a method to answer it
  • [ ] Stakeholder framing conflicts are explicitly named, not glossed over

Notes

  • The most common failure mode is accepting a solution-in-disguise ("we need X") as the problem — Step 1 exists specifically to catch this
  • If stakeholders fundamentally disagree on the problem, the deliverable's most valuable output is the framing-conflict synthesis, not the problem statement
  • Resist over-scoping: a well-bounded problem solved is worth more than a vast problem left fuzzy
  • Use this as a kickoff artifact — circulate it to the sponsor before any solution work begins, and treat the P0 questions as a gate

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills