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