Unserved Needs Finder

Unserved Needs Finder

What it does

Takes a fellow's list of customer "needs" — usually a mix of real needs, disguised solutions, and tech capabilities — and returns one ranked map. It strips the solution and capability words off each entry, onions what remains down to a core that would still be a need if the technology were completely different, classifies the survivors with Kano (must-have / performance / delighter), and names the single durable, under-served performance need that is the wedge. The output is a filled prioritised need map (template.md) that also kills the disguised solutions, flags the unmet must-haves as table stakes, and marks any delighter as decaying. It finds the need that survives when the model does not.

The Icarus reframe

Generic JTBD produces a tidy nine-box of jobs, pains, and gains and stops. That list is not decisive, and it does not protect you from the two ways a "need" is fake. First, a stated need is often a pre-chosen solution ("they need a dashboard") — a dashboard is a thing you would build, not a thing they need. Second, and worse for a studio building on frontier models, a stated need is often a tech capability ("they need real-time anomaly detection", "they need a bigger context window"). A capability is a property of a solution, and it evaporates on the next model release — you cannot own a need that the platform commoditises in a quarter. So this skill adds two gates JTBD has no equivalent of: an onion that peels every solution and capability word off, and a tech-invariance test that keeps only needs still true if you solved them with paper, a clerk, or a model three generations away. Then Kano sorts the survivors — because the wedge is a specific band. Unmet must-haves are table stakes; you fix them but they never win. Delighters decay to must-haves as competitors copy them, and the ones built on a novel capability decay fastest. The wedge is the under-served performance need: the one customers already pay a workaround to half-meet, that gets better the more you meet it, and that will still be a need after the tech turns over.

When to use / When NOT

Use it once you have a segment and a handful of candidate needs (from interviews, observed workarounds, or the fellow's own list) and you need the durable one ranked out before anyone designs a solution.

This skill ranks WHAT is needed. It does not name WHO needs it (that is user-buyer-decider-map, which reads the top need from here into its buyer clarity), it does not reduce the whole job to currencies (that is job-in-primitives), and it does not judge the idea (that is so-what-stress-test). Name the sibling and stop.

Method

Fill the sheet in template.md. Work the tables; do not narrate. Tag every empirical claim [Fact] (observed behaviour or a shown artefact), [Assumption] (a stated, defensible estimate), or [Hypothesis] (a guess needing evidence).

Step 1 — Collect candidate needs (§0). List every stated need verbatim, keeping its solution and tech words. For each, record the source and its ladder weight (money 1.0 · observed behaviour 0.7 · artefact 0.5 · verbal 0.3 · opinion 0.1). The artefact rung (0.5) means a customer's own workaround artefact — the spreadsheet, checklist, or screenshot they built to cope — NOT the team's own roadmap, wishlist, or spec, which is opinion (0.1). Mis-weighting an internal doc at 0.5 is how the all-0.1 STOP gets bypassed; do not. If every candidate rests on opinion (0.1), stop — see Evidence standard.

Step 2 — Solution-strip, onion pass 1 (§1). For each candidate, flag the words that name a thing you would build or a property of that thing, and replace them with the need beneath.

A candidate that is nothing but a solution or a capability has no need beneath until you peel — do not pass it through unpeeled.

Step 3 — Onion to core (§2). Ladder each stripped need: "if that were fully met, what would they still need, and why does it matter?" Peel until you reach a need that (a) contains no solution word and (b) names a human decision, outcome, or state — not a tool behaviour. Stop before it dissolves into a platitude (see Gotchas).

Step 4 — Tech-invariance test (§3), the durability gate. For each core need, ask: would this still be a need, unchanged, if you solved it with paper, a clerk, or a model three generations from now?

A "no" is the KILL line for a tech-capability-as-need. Kano alone will not catch it — a capability can masquerade as a performance need — so this gate runs before Kano, not after.

Step 5 — Kano classify the survivors (§4). Ask two questions per durable need: functional ("if this were fully met, how do you feel?") and dysfunctional ("if it were not met at all, how do you feel?"). Map:

Step 6 — Rank and select (§5). For each durable need record its Kano class and its unserved-evidence weight (how strongly current solutions fail to meet it, on the ladder). Then apply the selection rule:

• Return the durable need that is performance-class AND has unserved evidence ≥ 0.5 (a shown workaround or stronger). That is the wedge.
• An unmet must-have → label "entry ticket: fix, do not differentiate".
• A delighter → label "decaying: do not anchor the moat here".
• Unserved evidence < 0.5 → label "hypothesis: go observe before building".
• If two needs onion to the same core, merge them and say so (do not double-count a need as two).

Step 7 — Evidence the pick (§6). The "unserved" claim on the top need is a claim about a gap, and it must sit at ≥ 0.5 to be actionable — a workaround you can point to, or money leaking to a substitute. If it sits below that, return the need as a [Hypothesis] plus the single cheapest observation that would confirm the gap is real.

Evidence standard

Icarus weights behaviour and money over opinion. "Unserved" is the load-bearing word here, and it is a claim about a gap — so it needs gap evidence, not agreement. The strongest proof a need is real AND unmet is money leaking to a workaround; the weakest is the fellow's belief that customers would like it.

A need supported only at 0.3 or below is not an unserved need — it is a hope. The skill returns it as a [Hypothesis] with the cheapest observation to move it up the ladder, and it never ranks a hope above a workaround. If the whole input sits at 0.1, the skill declares it not ready and names the fix: watch one customer do the job once, and find what they reach for when the current tool stops helping.

Gotchas

• The comfortable need is a delighter. Fellows fall for the surprising demo feature because it demos well. But delighters decay — competitors copy them and they slide to must-have — and delighters built on a novel capability decay in a quarter. If the wedge lands on a delighter, you are building on ground that erodes. Force the performance need out.
• "Unserved" is not the same as "unspoken". A need can be loudly complained about and still served — they cope, the substitute is adequate, nobody switches. Unserved means the gap is evidenced by a workaround or a money leak, not that the fellow has not heard anyone mention it.
• Over-peeling dissolves the need into a platitude. "They need to feel safe / make money / save time" is true of every human and directs nothing. Stop the onion at the last layer that still discriminates this segment's job from another's. If the core need would fit any business on earth, you peeled one layer too far.
• A capability can pass Kano and still be a fake need. "Faster processing" reads like a performance need (more is better, less is worse) and will sail through the Kano test. The tech-invariance gate is the only thing that catches it — run Step 4 before Step 5, always, or the disguised capability ranks as your wedge.
• Two stated needs often share one core. Fellows list the same need twice in different solution costumes. Merge them at Step 6 or you will inflate a single need into a phantom pattern.

Examples

• examples/sample.md — Mentix's factory-manager needs, run end to end: "an AI copilot" and "real-time anomaly alerts" both peel away (one a solution, one a capability that fails tech-invariance), and the durable, under-served performance need surfaces — deciding which of several simultaneous emerging faults to send the one available technician to before a line stops — evidenced by the managers' manual tribal-knowledge whiteboard (behaviour, 0.7).

Related skills

• Absorbs discovery/jobs-to-be-done: it keeps that framework's one durable instinct — separate the job from the solution, and look past functional needs to social and emotional ones — and drops the unranked nine-box list. Where JTBD ends in a wishlist, this ends in one ranked map with a single wedge need, the disguised solutions and capabilities killed, and the musts and delighters labelled. It beats JTBD by being decisive (it returns the one need) and durable by construction (the tech-invariance gate JTBD has no analogue of).
• Not user-buyer-decider-map: that names WHO has the need — user, buyer, decision-maker, champion, each with a budget and a why-now. This names WHAT the need is and ranks it. Run them side by side; the buyer map reads the top need from here.
• Not job-in-primitives: that reduces the whole job to information moved · decisions made · liability transferred. This ranks the needs inside that job. Compose them — reduce the job, then find the unserved need in it.
• Feeds problem-quality-scorecard (the durable unserved need is the "problem worth solving" input) and wedge-five-questions (the under-served performance need is the wedge candidate). so-what-stress-test scores the whole idea; this scores only the needs. Supersedes nothing.