Abstraction Laddering

Every problem arrives at some altitude, and the altitude is usually accidental: it is wherever someone happened to be standing when they noticed it. Too low and you optimize a detail that does not matter (“make the button blue”); too high and you produce a true but useless aspiration (“delight the customer”). Abstraction laddering moves the problem along one vertical axis - up by asking “why? / to what end?” and down by asking “how? / what specifically?” - to find the altitude at which it is actually workable. The output is an abstraction ladder, an ordered set of rungs with one chosen as the working level, not a discussion.

When to Use

A request names a bare solution (“add a dashboard”, “build an integration”) but the purpose it serves is unstated.
A problem is stated as a vague aspiration (“improve engagement”, “be more strategic”) with no concrete handle to act on.
People are arguing past each other and may simply be working at different levels of the same problem.
Before committing effort, to decide deliberately at what altitude to attack a problem rather than inheriting the accidental one.

When NOT to Use

Altitude is not the issue. If the problem needs a different kind of reframing - a stakeholder shift, an inversion, an is/is-not boundary, or weighing several rival framings - use think-problem-restatement, which generates those moves and converges on a chosen frame. This skill only moves up and down one axis.
The right level is already clear and agreed. Building a ladder for a well-located problem manufactures motion and wastes effort.
To generate or choose solutions. Going down lists more concrete sub-problems to consider, not a chosen solution. Use an ideation skill (Question Burst, SCAMPER) to generate and a decision skill (Decision Option Review) to choose.
To decompose a problem into all its parts. A ladder is a single vertical chain, not a branching breakdown. For that, use an issue tree.

Instructions

When asked to find the right altitude for a problem, follow these steps:

Capture the entry rung. Record the problem exactly as given, in one line. This is where the ladder starts; mark it as the entry rung. If the altitude is already clear and agreed, say so and stop.
Climb up: ask “why? / to what end?” Repeatedly replace the current rung with the broader purpose it serves (“we do this so that…”). Each step up should be a genuine purpose, not a reword. Stop climbing when the next rung is so broad it would be true of almost any project (that rung is too high to work at).
Descend: ask “how? / what specifically?” From the entry rung, repeatedly replace the current rung with a more concrete instance or sub-problem (“concretely, that means…”). Note where a rung has more than one plausible “how”; that fork is a signal there are options at that altitude. Stop descending when a rung is so specific it is a single implementation detail.
Lay out the ladder. Order all rungs from most abstract (top) to most concrete (bottom) as a single vertical chain. Keep the why-relationship reading upward and the how-relationship reading downward explicit. Do not let it sprawl sideways into a pile of loosely related ideas; that is a different artifact.
Select the working altitude. Choose exactly one rung as the level to actually work the problem at - high enough to leave room for real options, low enough to be actionable - and give a one- or two-sentence rationale tied to the user’s actual goal. Converge; a ladder with no chosen rung is incomplete.
Emit the abstraction ladder. Produce the artifact in references/TEMPLATE.md: a short summary above an ordered ladder with the entry rung marked and the working rung selected.

Output Format

Use the template in references/TEMPLATE.md. The deliverable is the filled ladder plus its summary, with one rung chosen as the working altitude, not a prose essay.

Quality Checklist

Before finalizing, verify:

The entry rung (problem as given) is captured verbatim and marked on the ladder.
Up-steps are genuine purposes (“why / to what end”), not rewordings; down-steps are genuinely more concrete (“how / what specifically”).
The ladder is a single vertical chain ordered abstract-to-concrete, not a sideways pile of related ideas or a branching decomposition.
Climbing stopped before the uselessly-universal rung, and descending stopped before bare implementation detail.
Exactly one rung is selected as the working altitude, with a rationale tied to the user’s actual goal.
The output is the ladder artifact, not prose.
No overclaiming: the skill makes the altitude choice explicit and deliberate; it does not guarantee a better solution or a correct level (see evidence/dossier.md).

Evidence

Tier P (practitioner). That how a problem is framed - including at what level of abstraction - affects the solutions found has moderate support in the problem-framing literature (problem-finding research; Nutt on decision failure from poor definition; Wedell-Wedellsborg, HBR 2017), and abstraction is a well-described dimension of language (Hayakawa, Language in Thought and Action, 1939). But there is no controlled study isolating “abstraction laddering” as a named technique against a baseline; it is a widely-taught design-facilitation method with face validity and a clear mechanism, not a measured one. The supporting evidence concerns framing in general, not this exercise specifically, and is transferred from human practice, not AI-validated. Full grading, sources, and caveats: evidence/dossier.md.

Examples

See references/EXAMPLE.md for a completed abstraction ladder on a real decision.

Deep dive: worked example

A full worked run (the shared Northwind scenario)

Abstraction Ladder - Worked Example

A completed run of the abstraction-laddering skill on a real, consequential decision. This is the quality bar a generated ladder should meet.

Uses the shared recurring scenario (Northwind, a B2B SaaS weighing a self-serve free-tier launch) so examples across skills read as one coherent product. See docs/internal/AUTHORING.md.

Problem under laddering

Problem as given (entry rung): “We need to launch a self-serve free tier.”
Who framed it / how it arrived: Brought to the team by leadership as a pre-baked solution, attached to a Q3 board target for top-of-funnel growth. The altitude is accidental: it names one mechanism, not the goal, and not the only mechanism.
The user’s actual goal: Grow qualified pipeline efficiently enough to hit the Q3 number without breaking the existing sales-led motion.

Summary (top of the artifact)

The problem arrived two rungs too low: “launch a self-serve free tier” is a specific implementation, not the problem. Climbing reveals the real goal is “grow qualified pipeline efficiently,” for which a free tier is only one of several “hows” (free trial, usage-based entry, partner-led, better paid funnel). Climbing one rung higher (“hit the Q3 growth number”) is too broad to act on, and climbing to “grow the company” is uselessly universal. We choose to work at “reduce the cost and friction of a prospect reaching first value” as the working altitude: it is high enough that a free tier competes against cheaper alternatives instead of being assumed, and low enough to act on this quarter. A free tier may still win - but now it has to earn it.

The ladder (most abstract at top, most concrete at bottom)

Rung	Altitude	Statement of the problem at this level	Note
^ why?	Highest	Grow the company / increase enterprise value	too high: true of almost any project, not workable
	Higher	Hit the Q3 top-of-funnel growth target	a target, not a problem to solve; still too broad to act on
	High	Grow qualified pipeline efficiently without breaking the sales-led motion	the user’s actual goal - several “hows” live below it
	Working	Reduce the cost and friction of a prospect reaching first value	chosen working altitude - leaves real options open, still actionable
	Lower	Let prospects experience the product before talking to sales	more than one “how” here -> free tier, free trial, interactive demo, usage-based entry
	(entry)	Launch a self-serve free tier	<- problem as given; one mechanism among several
v how?	Lowest	Ship a free plan with feature gates, usage caps, and a self-serve signup form	too low: a single implementation detail of one mechanism

Working altitude (chosen rung): “Reduce the cost and friction of a prospect reaching first value.”

Rationale: This rung serves the actual goal (efficient qualified pipeline) while refusing to assume the answer is a free tier. At this altitude the free tier must compete against a free trial, an interactive demo, and a better-instrumented paid funnel on cost, conversion, and load on the sales motion - which is exactly the comparison leadership skipped by handing down a solution. It is concrete enough to scope work this quarter.

Note how the value is in relocating the work: the problem arrived as “launch a free tier” (an answer), and the ladder moved it up to a level where the free tier is one competing option rather than a foregone conclusion - the move a naive prompt, which would have started designing the free tier, would miss.

Grounding: the full evidence dossier

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

Evidence Dossier: Abstraction Laddering

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


Skill	`thinking-framework-skills.abstraction-laddering` (installable name `think-abstraction-laddering`)
Family	problem-framing
Evidence tier	P (practitioner; useful, limited controlled evidence - see “What the evidence shows”)
Confidence	Moderate that the move helps locate the working altitude; low that any specific effect size is established
Status	draft (first authored 2026-05-31, against discovery corpus)

1. The mechanism (what actually does the work)

A problem is always stated at some altitude, and the altitude is usually accidental: it is wherever the person happened to be standing when they noticed the problem. Solve at too low an altitude and you optimize a detail that does not matter (“make the button blue”); reason at too high an altitude and you produce a true but useless aspiration (“delight the customer”). Abstraction laddering is a deliberate act of moving the problem up and down a single vertical axis of abstraction to find the altitude at which it is actually workable.

Two complementary moves do the work:

Up the ladder - “why? / to what end?” Each “why” replaces the current statement with the broader purpose it serves. Climbing reveals the goal the current framing is only one means to, and exposes whether the stated problem is really a presupposed solution.
Down the ladder - “how? / what specifically?” Each “how” replaces the current statement with a more concrete instance or sub-problem. Descending turns an abstraction into something observable and actionable, and multiplies the options at a given level (there is usually more than one “how”).

The output is not a discussion; it is an abstraction ladder: an ordered set of rungs from most abstract (top) to most concrete (bottom), with the entry rung marked and one rung explicitly chosen as the working altitude, plus a one-line rationale. The mechanism is locating altitude, nothing more. It does not pick a solution and it does not generate the other framing moves (stakeholder, inversion); those belong to broader reframing.

2. Lineage

Abstraction as a vertical dimension of meaning: Hayakawa, S. I. (1939, and later editions). Language in Thought and Action - the “ladder of abstraction,” from concrete referents up to abstract terms. This is the conceptual root and is descriptive, not trademarked.
As a design / problem-framing practice: the “abstraction laddering” exercise popularized in UX and facilitation practice (for example, the Interaction Design Foundation and various design-sprint and facilitation toolkits), framed as asking “why” to go up and “how” to go down to find the right level for a “How Might We” question.
Adjacent engineering lineage: value engineering’s function analysis and TRIZ “why-stop” / S-field abstraction use the same up-the-ladder move to separate the function wanted from the current implementation.

No trademark. “Ladder of abstraction” (Hayakawa) and “abstraction laddering” (design practice) are generic descriptive terms; no attribution is required and none is claimed. The skill is named descriptively after the mechanism.

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

This is the honest core of the dossier. The skill must not overclaim.

What is reasonably supported:

That how a problem is framed - including at what level of abstraction - affects the solutions found has moderate support in the problem-finding and problem-framing literature (Getzels & Csikszentmihalyi on problem finding; Nutt on decisions that fail from poor problem definition; reframing practice such as Wedell-Wedellsborg, HBR 2017). Altitude is one well-attested lever inside that larger, supported claim.
That abstraction is a real, navigable dimension of language and concepts (the Hayakawa ladder) is uncontroversial as a descriptive model.

What is NOT shown (the caveats that keep the skill honest):

There is no controlled study isolating “abstraction laddering” as a named technique and measuring its effect on decision or solution quality against a baseline. It is a practitioner method: widely taught and used in design facilitation, with face validity and a clear mechanism, but thin direct empirical support of its own.
The supportive framing evidence in the bullet above is about framing in general, not about this specific “why-up / how-down” exercise. It is suggestive, not confirmatory, for this skill. Do not present general framing research as if it validated the ladder technique itself.
The method does not guarantee a better solution or a correct altitude. It makes the altitude choice explicit and deliberate rather than accidental; the judgment about which rung to work at remains a human call.

Net grade: P (practitioner). Clear mechanism and strong adoption in practice, supported indirectly by framing research, but lacking technique-specific controlled evidence. Claim “makes altitude explicit and helps locate a workable level”; do not claim measured improvement in outcomes.

4. Transferred-evidence flag (required honesty for this library)

All of the supporting evidence is from human practice and human-subject framing research, in design, facilitation, and decision settings. There is no study of abstraction laddering run by or with an AI agent, and none of whether an agent-built ladder improves a human’s framing. The evidence is therefore transferred from human practice, not validated for AI-augmented use. The skill must say so. Treat the AI value as: the agent makes the up/down interrogation cheap and fast, resists stopping at the accidental entry rung, enforces a clean vertical ladder (not a sideways pile of related ideas), and produces a durable artifact that names the chosen working altitude - benefits that do not depend on any unproven outcome claim.

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

Works best when:

A problem or request is stated at a suspicious altitude: a bare solution (“add a dashboard”) whose purpose is unstated, or a vague aspiration (“improve engagement”) with no concrete handle.
The team is arguing past each other and may simply be working at different levels.
You need to decide, explicitly, at what level to attack a problem before committing effort.

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

Altitude is not the issue. If the problem needs a different kind of reframing - a stakeholder shift, an inversion, an is/is-not boundary, or weighing several rival framings - use problem-restatement, which generates those moves and converges on a chosen frame. Abstraction laddering only moves up and down one axis. (Near-miss anti-trigger against the neighboring skill.)
The right level is already clear and agreed. Building a ladder for a well-located problem manufactures motion and wastes effort.
Used to generate solutions. Going “down” lists more concrete sub-problems and options to consider, not a chosen solution; it is not ideation (use Question Burst / SCAMPER) and not a decision tool (use Decision Option Review).
Laddering to infinity. Endlessly climbing to ever-grander purpose (“…to make the world better”) or descending into ever-finer detail without ever marking a working rung produces a tall ladder and no decision. The skill must force selection of one rung.
Confused with a decomposition tree. A ladder is a single vertical line (one why/how chain), not a branching breakdown of all parts; if the task is to decompose a problem into its components, use an issue tree.

6. Output artifact

The skill must emit an abstraction ladder, not prose: an ordered, top-to-bottom set of rungs (most abstract to most concrete), each rung a one-line restatement of the problem at that altitude, with the original entry rung marked, the “why?” relationship going up and the “how?” relationship going down made explicit, and exactly one rung selected as the working altitude with a one- or two-sentence rationale. A short summary sits above the ladder. The artifact is the deliverable; the conversation is not.

7. Sources

Hayakawa, S. I. (1939). Language in Thought and Action - the ladder of abstraction (conceptual root).
Getzels, J. W., & Csikszentmihalyi, M. (1976). The Creative Vision: A Longitudinal Study of Problem Finding in Art - problem finding and how problem formulation shapes outcomes.
Nutt, P. C. (work on decision-making failures, e.g. Why Decisions Fail, 2002) - decisions that fail from poor problem definition / premature framing.
Wedell-Wedellsborg, T. (2017). “Are You Solving the Right Problems?” Harvard Business Review - reframing practice; framing precedes good solutions.
Interaction Design Foundation and design-facilitation toolkits - “abstraction laddering” as the why-up / how-down exercise to find the right altitude for a problem statement.

Verification status: Hayakawa (1) and Wedell-Wedellsborg (4) are well-attested. The problem-finding and decision-failure citations (2, 3) support framing in general and are drawn from secondary synthesis; they should be confirmed against the primary works before any public-facing claim, and they must not be presented as validating the ladder technique specifically. Citation 5 is practitioner literature, not peer-reviewed evidence. These are safe to use inside this dossier because the dossier’s job is to be honest about exactly this gap.

Thinking Framework Skills v0.3.0 · 38 frameworks