asb-needs-stack

Builds a customer Needs Stack — the ladder in which every need is a means to the end one level up (buy infrastructure → set up a WordPress site → have a personal website → get a book deal). Anchors the level the user's product satisfies, phrased as the customer's own goal in the customer's own words

By asmartbear · 451 installs

npx skills add asmartbear/asb-skills --skill asb-needs-stack

Source repository · Upstream listing

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