> ## Documentation Index > Fetch the complete documentation index at: https://docs.latwoodtech.com/llms.txt > Use this file to discover all available pages before exploring further. # Wingspan method # 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 {slots}, paste into Claude Code on the target repo) ``` Run a WINGSPAN PASS on {ACTOR} in {PRODUCT} (repo: {REPO}). Goal: {GOAL, e.g. "get and retain {ACTOR}"}. PHASE 1 — COLLAPSE. Before any options, reason from constraints until the answer is FORCED: • WHO: {ACTOR}'s real job-to-be-done + behavior pattern (not demographics). • WHAT: the offer + the STACK — what's cheap/instant to deliver vs expensive/slow (this dictates architecture). • HOW: the delivery channel and its human constraints. • STRUCTURE: the system's shape (e.g. two-sided marketplace) and what SEQUENCE it forces. Output ONE forced conclusion + ordering. No menu. PHASE 2 — SPREAD THE BIRD. Map {ACTOR}'s full lifecycle as discrete beats, first-touch → advocacy. Overlay the nerves that run through every beat: Delivery (read/listen/watch/do), Loop (trigger→action→variable reward→investment), Instrumentation (can we see it?), Trust (proof/safety). Put the whole animal on the table before cutting anything. PHASE 3 — BUILT / WIRED / MISSING. Do this with READ-ONLY recon; fan out parallel agents if large. For each beat, classify existing capability WITH file:line evidence: • BUILT — exists in the codebase • WIRED — actually reachable by {ACTOR} today • MISSING — genuinely absent Flag every BUILT-but-not-WIRED item. That delta is the leverage. PHASE 3.5 — BEST-OF-BREED BENCHMARK. For each beat, name the category leader(s) and rate our position: AHEAD/DIFFERENTIATED, AT PAR, BELOW, or ABSENT. Flag differentiators to protect and the genuine competitive gaps. Separate product gaps from GTM gaps (BELOW on discovery usually = demand-gen). A beat can be fully WIRED and still BELOW — "it works" ≠ "it wins." PHASE 4 — CUBE FOR THE SQUARE HOLE. For each real gap, name who does it best-in-class and copy the proven shape. Pre-traffic, build to that bar — do NOT wait for data. Reuse existing machinery; don't reinvent. PHASE 5 — CUT ORDER. Rank fixes by (structural constraint × reddest bleed). Ship last-inches first. Instrumentation grades lift after; it never gates the build. RULE: the code is rarely the constraint — the gap between capability and exposure is. Find it. ``` ## 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.