asb-needs-stack

The Needs Stack: What Your Customer Actually Wants

Nobody's life ambition is to buy your product. Whatever your product does, it is a means to an end — and that end is a means to a higher end, and so on, up a ladder this method calls the Needs Stack. Mapping the stack tells you who your real alternatives are (not just your competitors), what outcome you may honestly promise, which steps you should brag about making obsolete, and where your company's higher purpose lives. This skill builds that map with the user: anchor the level the product satisfies, walk down, then walk up — one level per exchange, each level crystallized before the next.

The mental model

A worked stack

Charlie signs up for AWS to buy cloud infrastructure — servers, storage, network. But "buy infrastructure" isn't what Charlie wants; it's an obstacle in the way of the WordPress website Charlie actually wants. And a WordPress site isn't the end either: it's a means to a personal website for content and self-promotion. Which is itself a means: Charlie really wants a book deal, and the way to get one is to have built an online following first. Written as a stack, top ends above bottom means:

• ★ Get a book deal.
• → Have a personal website for content and self-promotion.
• → Set up a WordPress website.
• → Buy infrastructure.

Every level is real, every level has vendors serving it (Substack and social media at the following level; Wix, Squarespace, and Webflow at the website level; WP Engine at the WordPress level; AWS, GCP, and Azure at the infrastructure level), and every level is only a means to the one above it.

The obviation rule

A product that satisfies a need in the stack makes the products below it obsolete for that customer. Charlie never wanted infrastructure and still doesn't — so a company that delivers a working WordPress site without the customer ever touching infrastructure wins Charlie, and the infrastructure vendors never even see Charlie. Charlie disappears from that market. This is why the stack matters competitively: the vendors one level above you are not your competitors (they don't sell what you sell) but they are your alternatives — they can remove your customer from your market entirely. Ask a vendor who their competitors are and they'll name the other vendors at their own level; the stack reveals the alternatives above, which is where disruption actually comes from.

The trade-off between high and low

Higher levels offer the shortest path to the goal; lower levels offer flexibility and customization. An all-in-one product gets the customer to the outcome fastest but constrains them to its fixed menu; building from lower-level parts takes longer but bends to any requirement. This is why a level being "obviated" doesn't kill the vendors below it — customers who need the flexibility still buy low. It's also each level's standing defense against the level above: name what your customer keeps by buying at your level.

The trap: stopping at your own level

Everyone wants to stop mapping when they reach the level they operate on — "we sell websites, and customers want websites, done." There is always another level up, and the levels above yours are exactly the ones that determine what you may promise and who can obviate you. Keep climbing until the stack tops out.

Where the stack tops out: purpose levels

High enough, the needs stop being product-shaped: recognition, ego, legacy, self-actualization. No product satisfies these directly (some would argue meditation and therapy come closest). Record one or two of these purpose levels and mark them: they are not promises and not markets, but they are the raw material for the company's higher purpose — the true stories worth telling on the website and celebrating internally when a customer actually gets there.

What each level is for downstream

Positioning consumes the stack by role, relative to the user's level:

• Your level — what you do. Features live here. A customer whose current thought (and search query) is at this level wants specs and features, not lifestyle benefits — a builder searching for a 5/16" socket wrench does not want to be told the light "helps you see."
• One level up — what you promise. The outcome you claim as the consequence of what you do. This is the strongest honest benefit.
• Levels far above — aspirations. Never promise them; show the part you play in them, with testimonials and how-to content proving it's possible.
• Levels above, held by others — counter-positioning. The vendors there are obviating you; answer with what the customer keeps by buying at your level (flexibility, customization, uniqueness).
• Levels below — advancements. Brag that you make these steps obsolete: no time spent, nothing to manage, nothing to learn.

The stack also picks your most strategic metric — measure whether customers succeed one level up from you, not just whether your product delivered (a store-builder can deliver a perfect store whose owner sells nothing and churns; the vendor that measures its customers' sales sees the truth) — and it warns against the tempting pivot: moving your product up a level is usually a different product, a different business, and a smaller market. Partial climbs (vertical sub-brands, add-on features, content that helps with the next level) are the realistic versions.

Whose stack it is

A stack belongs to one kind of customer. Different customers climbing through the same product diverge at higher levels — an agency, a hobbyist, and an e-commerce store may all "set up a website" for entirely different ends. Build the stack for the ideal customer — the one the business most wants to win. And when a sale has two heads (the buyer and the user are different people, common in business software), each may need their own stack; both can decide the sale.

Vocabulary

• Level (N1, N2, …) — one need, phrased as the customer's goal; numbered in the order settled (numbers are frozen; position in the file carries stack order).
• Your level — the need the user's product satisfies; the anchor.
• Obviation — a higher-level product making lower levels irrelevant for that customer.
• Occupants — who serves a level today: vendors, products, DIY methods, agencies. Real names.
• Purpose level — a top level no product satisfies directly; material for meaning, not marketing promises.

The elicitor's posture

Be clear, not clever

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

Restate references; never cite a bare token

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

One level per exchange, crystallized before moving

The walk is strictly paced: anchor the user's own level first, then one level per exchange — downward until the levels stop mattering, then upward until the purpose levels. A level is settled only when it passes the crystallization gate below; do not sketch the whole stack up front and refine later (if the user asks for exactly that, decline in substance: a ladder of unvetted levels is a brainstorm, not a map, and each level is built on the one before it — offer instead to propose the candidates at every level so the user mostly confirms and corrects), and do not accept "and above that, obviously, success" as a level. Propose candidate phrasings AND candidate occupants yourself freely — the user knows their customer; the outside perspective helps find the honest phrasing and remember who else sells at a level — but the user confirms every level. When you name occupants and alternatives, confirm who serves a level today using current results from your search tools; do not rely on internal (training) knowledge, which is stale and names dead products or misses new ones. A level heard out of order ("they want to win cases" volunteered during the anchor) is parked in chat and takes its number only when the walk reaches it and it settles.

The crystallization gate

Every level must pass four tests before the walk moves on:

1. Customer's words, customer's goal. Phrased as a need the customer would state — "set up a WordPress website," not the vendor's category ("managed hosting") and not a generic gesture ("grow their business" — whose growth, through what?). Generic words (success, efficiency, value, scale) get pressed into the specific picture the customer actually holds.
2. A true means-to-an-end link. The test: if this level were handed to the customer fully satisfied, would they happily never touch the level below? If they would still want the lower level for its own sake, the link is wrong — the levels aren't stacked, or a middle level is missing.
3. Named occupants. Who serves this level today — vendors, products, methods, agencies, by name. Occupants are what make a level operational: they are the alternatives and the counter-positioning targets. A mid-stack level with no nameable occupant is suspect — usually two levels blurred together or a level invented to flatter the product. (Purpose levels are the exception: mark them instead.)
4. A real step, not a reword. Distinct from its neighbors: if satisfying one level automatically satisfies the other with nothing left over, they are one level, merged.

Two scope notes. When descending, the means-to-end test points upward — it verifies the already-settled level above the new one (handed that fulfilled, would they skip this new lower step?); a brand-new bottom level's own downward link isn't testable until the next descent, and that's fine. And purpose levels are exempt from test 3 only: tests 2 and 4 still apply, and test 1 applies in personalized form — "recognition" and "legacy" are recorded as this customer's specific version of them ("be known in town for her beer," "promotion to VP, and evenings back"), never as bare abstractions.

The user owns the customer; the gate owns the wording

Whether their customer really climbs this way, what the customer actually wants, which persona is ideal — the user's knowledge, and their call stands after one honest press. But the gate is not theirs to waive: a level that fails a test is not recorded in the stack in any form, however insisted; there is always a compliant phrasing of what the user actually means, and finding it is the work. When the user defends a phrasing by appeal to market knowledge ("that IS what the customer wants — the board approved this language"), separate the two out loud: the want is theirs and stands; the words are the gate's, and vendor phrasing never enters the file. Tone stays warm; the bar does not move. One escape hatch: if, after the trap is explained once, the user still declines to climb further, don't stall the whole exercise — finalize with an explicit caveat in the preamble ("stack incomplete — stopped below the purpose levels at the user's request") so the file is honest about what it is.

The closing press

Before finalizing, attack the whole stack once. If a devil's-advocate interrogation skill is installed in the environment (for example Rude Q&A / asb-rude-qa, from the same author as this method), invoke it against the draft stack with this brief: attack this needs stack — find every level phrased in vendor language or generic words; every means-to-end link that fails the "handed to them fulfilled, would they skip the level below?" test; every level with no real occupants that isn't a purpose level; every adjacent pair that is one level reworded; and check the top — did they stop climbing at their own level or one polite step above it? If no such skill is available, run exactly that interrogation yourself, visibly, before finalizing.

How to use this skill

Phase A — Ingest and anchor

Optional inputs, worth asking for once. The stack is anchored to a specific customer, so ask (in the same breath: paths to the files, and the company/product name for the file title) whether the user has: an ideal-customer definition (a file defining the customer by behavioral and circumstantial markers — often with numbered keystones, deal-breakers, and inciting events); customer-interview findings; a keystones chart. Read whatever exists — the ideal customer named there is whose stack this is, interview quotes are gold for phrasing levels in the customer's words, and keystones sharpen the "why your level still wins" lines. If none exist, say plainly that the stack will be sharper with them (and that an ideal-customer method from this skill's author produces the definition — asb-carol-define is the final step, if installed), then proceed anyway: press for a one-or-two-line sketch of the ideal customer — who they are by circumstance and behavior, not demographics; the press repeats until the sketch is genuinely sharp, since a vague anchor bends every level above it — and record it in the preamble as the anchor, caveated as unvetted. Record absences too ("no ideal-customer definition, interviews, or keystones chart exist"), so a resumed session doesn't re-ask.

Resume check. If a NEEDS-STACK.md already exists at the target location, read it first: an in-progress header means resume — pick up exactly where the pointer says, don't re-litigate settled levels. A finalized file means ask whether to revise or to build a second persona's stack. When the user says "continue" but no file is found where expected, ask where it lives before starting fresh.

Anchor your level. Ask what the product does, then convert it: the anchor level is the customer's need, not the product's category. "We sell managed Postgres hosting" anchors as "have a production database that runs itself." Run the crystallization gate on it — including occupants: the user plus their direct competitors. This is N1. Create NEEDS-STACK.md as soon as N1 settles — in the same directory as any input file; with no input file, ask where the method's files should live before creating it (default: the current directory) — with the in-progress header.

Phase B — Walk down

One level per exchange: what would the customer have to do or buy below this level if your product didn't handle it? Each level down gets the full gate, plus its role line: an advancement — a step you make obsolete, and should say so. Stop descending when the next level down no longer matters to the purchase — the test: would any buyer weigh it when choosing among the occupants at your level, and would your positioning ever mention it? Both no = stop (below "buy infrastructure" lies "have electricity" — real, but nobody's positioning mentions it). One or two levels down is typical. Note the stop and its reasoning in the header pointer while in progress, so a resumed session knows the descent is complete.

Phase C — Walk up

One level per exchange, starting from the anchor: is that the customer's life ambition? Means to what end? Each level up gets the full gate, plus its role lines: the first level up is the promise; levels above that are aspirations; every occupied level above notes why your level still wins for your ideal customer (the flexibility, customization, or uniqueness they keep). Keep climbing past the comfortable stopping point — the trap is stopping at or just above your own level. The walk ends when the levels stop being product-shaped: record one or two purpose levels, marked as such.

Where the market genuinely diverges at some height — different ideal customers climbing to different ends — don't average them into one vague level; note the divergence and offer a second stack for the other persona (Phase D).

Record to the file as you go. Write each level into the file at its stack position the moment it settles — settle order and stack order differ, so this is placement, not appending to the bottom — and keep the header pointer current: anchored, walked down through (and whether the descent is complete), walked up through, currently crystallizing. When a level is in flight — candidates proposed, nothing settled — put the candidate phrasings in the pointer too: the not-recorded-in-any-form rule protects the stack body, not the resume pointer, and a resumed session shouldn't lose work the user already reacted to. The file is the memory, not the chat. If files aren't accessible, re-emit the full draft in a fenced block every level or two.

Phase D — Sweep and close

• The closing press (delegated or self-run, per the posture). It covers every stack in the file, and it audits — it does not reopen settled pacing: fixes it surfaces are patched inline with the user's confirmation, under the frozen numbers.
• Role check. Every level carries its role annotation; each stack's anchor and promise level are unambiguous.
• Second stack? If the sale has two heads (buyer vs. user) or a second ideal persona surfaced, offer to walk that stack now — numbering continues (no reuse), in its own section, with the full protocol (its own anchor marked YOU ARE HERE, its own down-check, its own promise level, the same gates). If the user defers it, record the divergence in Next steps ("the economic buyer may climb a different stack; numbering would continue from N") so it isn't lost.
• Finalize: remove the in-progress header, write the "Uses beyond positioning" and "Next steps" sections (they are finalization content, not built during the walk), and close with the handoff: the stack's levels are the skeleton of positioning — what you say at each level and what you promise one level up. If a positioning skill from this method's author is installed (for example Positioning / asb-positioning), name it: "when you're ready, run asb-positioning on your marketing copy with this file."

The file structure

N-numbers are stable once written — downstream positioning statements cite them. Never renumber; a level inserted later takes the next fresh number and its place in the list. Stability binds the number and the level's meaning, not its letter-for-letter wording: while the file is in progress, wording may be refined under a frozen number with the user's confirmation (the closing press often does this); after finalization, changes append rather than rewrite.

Refusal conditions

• No idea who the customer is. A stack without a customer is a guess. Press for at least a sharp sketch (circumstance and behavior); recommend the ideal-customer work; caveat the file if proceeding on a sketch.
• Vendor-language or generic levels, however insisted. "Leverage our platform" and "achieve success" never enter the file; the customer's actual goal, in words the customer would say, always exists and is the only recordable form.
• Stopping at the user's own level. The levels above are the point — the walk continues past comfort until purpose levels.
• A stack averaged across divergent customers. When personas genuinely split, one blurred stack describes nobody; build per persona.
• Skipping crystallization to sketch the whole ladder at once. A stack of uncrystallized levels is a brainstorm, not a map; the gate runs per level, in order.
• Writing the positioning itself. Converting copy, statements, and pitches against this stack is the next step of the method, not this one; this file ends at roles and the handoff.