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