Skip to main content

​
The Wingspan Method — a repeatable product-analysis formula

“Spread this bird on the table and check his wingspan. Then peel it and parse it up.”
A reusable pass for deciding what to build for any actor (seeker, practitioner, operator, buyer, admin…) in any app. It was derived from the 2026-07-05 selfprime seeker deep-dive, which turned a frustrating “menu of options” into four shipped PRs — every one reusing machinery that already existed.

​
Why it works — the value key

The framework is just scaffolding that aims a recon. The value comes from one discovery, over and over:
The machinery is usually ~80–90% already built and invisible. The analysis’s job is not to design what to build — it is to find the gap between what’s already BUILT and what’s actually WIRED (reachable by the user).
On the seeker pass: push was fully plumbed but missing an enrollment switch; the reading was already sectioned but stacked vertically; analytics was a working first-party system, just un-fired at the key joints. Every “fix” was a last inch on latent capability. The leverage lives in the delta between capability and exposure. Find that delta and you convert “we must build X” into “X is 90% there — here’s the switch.” Second unlock: pre-traffic, refuse to measure-first. You can’t measure your way out of a cold start. Build to the known best-in-class bar; let instrumentation grade the lift after — it never gates the build. Meta-law: the code is rarely the constraint. Seeing the gap between capability and exposure is.

​
The five phases

​
1. Collapse — kill the menu

Before producing any options, reason from constraints until the answer is forced:
  • WHO — the actor’s real job-to-be-done and behavior pattern (not demographics).
  • WHAT — the offer and the stack: what’s cheap/instant to deliver vs expensive/slow? (This dictates the architecture — e.g. cheap deterministic content = the daily habit; expensive LLM = the occasional wow.)
  • HOW — the delivery channel and its human constraints (mobile = glanceable, one action; voice; desktop).
  • STRUCTURE — the system’s shape and what sequence it forces (e.g. two-sided marketplace → you must bootstrap the self-sufficient side first; the other side is downstream).
Output: one forced conclusion + ordering. Kills: option-menu paralysis (“like pulling teeth”).

​
2. Spread the bird — full lifecycle, holistically

Map the actor’s entire lifecycle as discrete beats, first-touch → advocacy (not a feature list — moments in their journey). Overlay the transverse nerves that run through every beat:
  • Delivery/modality — read / listen / watch / do (match modality to moment; a wall of text is delivered but not received).
  • Loop — trigger → action → variable reward → investment (what makes each beat sticky).
  • Instrumentation — can we even see this beat fire or fail?
  • Trust — proof/safety, where relevant.
Output: the whole animal on the table before any cut. Kills: react-mode / whack-a-mole on whichever joint screams loudest.

​
3. BUILT / WIRED / MISSING — the recon (the value key)

Fan out read-only recon over each beat (parallel agents if the surface is large). For each beat, classify the existing capability with file:line evidence:
  • BUILT — exists in the codebase.
  • WIRED — actually reachable by the actor today.
  • MISSING — genuinely absent.
Flag every BUILT-but-not-WIRED item — that is the leverage. Kills: rebuilding what you already own; underestimating latent capability.

​
3.5. Best-of-breed benchmark — per beat

BUILT/WIRED/MISSING tells you what you have; it does not tell you whether what you have is good enough to win. For each beat, name the category leader(s) and rate your position:
  • AHEAD / DIFFERENTIATED — you do something the best don’t. Protect it and market it; it’s the moat.
  • AT PAR — you match the bar, often because you reused a best-of-breed primitive (Stripe Connect, WebRTC, Cal.com). Don’t touch it.
  • BELOW — the leader clearly beats you here. A real gap: decide build vs accept.
  • ABSENT — table stakes you’re missing.
Two rules: (1) a beat can be fully WIRED and still BELOW — “it works” ≠ “it wins.” (2) Separate product gaps from GTM gaps — being BELOW on discovery almost always means demand-gen (GTM), not a missing feature; don’t build features to fix a traffic problem. Output: a per-beat scorecard showing what to protect (differentiators), what’s safely at par, and the short list of genuine competitive gaps. Kills: shipping parity you call “done” because it works, while the category leader is two moves ahead.

​
4. Cube for the square hole — copy the best, don’t invent, don’t wait

For each real gap, name who does this best-in-class and copy the proven shape. Pre-traffic, build to that bar; do not wait for data. Reuse existing machinery ruthlessly. Kills: bespoke reinvention; measure-first paralysis at cold start.

​
5. Cut order

Rank the fixes by (structural constraint × reddest bleed). Ship the last-inches first. Instrumentation grades lift after; it is a scoreboard, never a gate.

​
The formula prompt (fill the , paste into Claude Code on the target repo)

​
Notes on running it well

  • Phase 3 is the payload; Phases 1–2 just aim it. Don’t skimp on the recon.
  • Use read-only agents for Phase 3 (worktree isolation only if they write). One agent per beat-cluster.
  • The output of a Wingspan Pass is a ranked cut list of last-inches, not a rebuild plan. If it reads like “build a lot of new things,” you probably missed BUILT-but-not-WIRED capability — recon again.
  • A pass can conclude the binding constraint is not product (e.g. supply/GTM). That’s a valid, valuable result — it stops you polishing a room nobody reaches.