--- name: startup_design description: Validate a startup idea before building it. Runs the full pre-build validation sequence: frame the bet as testable hypotheses, run customer discovery interviews, design pretotype experiments with pass/fail thresholds, project unit economics, and render a go/no-go decision. Triggers when a founder says "is this idea worth building", "validate my startup", "should I build this", or wants customer discovery, market validation, or a go/no-go call before committing code or capital. --- # Startup Design ## Purpose Most startups die because the founders built something nobody wanted, not because they built it badly. This skill runs the lean, tool-agnostic validation workflow that answers the question "should I build this?" before a single line of production code exists. It produces a validation packet: hypotheses, interview evidence, experiment results, unit-economics projection, and a go/no-go decision with named risks. Five phases, each with explicit exit criteria. A phase does not end until its criteria are met or the bet is killed. ## Workflow ### Phase 1: Frame the bet Write every load-bearing assumption down and label it a hypothesis. No business plans, no market-size theater, one page. Cover: the customer (a specific person, not a demographic), the problem (what it costs them today), the value proposition (what changes for them), the channel (how you reach them), the revenue model (who pays, how much, how often), the cost structure (what it costs to deliver). Each line is a guess until evidence replaces it. Rank the hypotheses by risk: which assumption, if wrong, kills the idea? That is where Phase 2 and 3 start. See `references/frameworks.md` for the Blank and Ries origins of this discipline. ### Phase 2: Customer discovery Talk to 20 to 30 real people in the target segment before building anything. Run every conversation on the Mom Test (Rob Fitzpatrick): 1. Talk about their life, not your idea. The moment you pitch, the data is contaminated. 2. Ask about specifics in the past, not generics about the future. "When was the last time you dealt with this, and what exactly did you do?" beats "Would you use something that did X?" every time. 3. Talk less, listen more. You are there to learn, not to convince. Script every interview around: who has this problem, how do they solve it today, what does it cost them in money or time, what have they already tried, and what would have to be true for them to switch. End each conversation by asking who else to talk to. Classify every signal into facts, compliments, fluff, or feature requests. Compliments are not validation. Opinions are not validation. The only signal that counts is commitment: time, reputation, or money. If people have not looked for a solution already, they will not look for yours. **Discovery exit criteria:** you can name the segment precisely, you know what the problem costs them today in concrete terms, and at least five prospects have shown real commitment (a deposit, an intro to their boss, a pre-order, hours of their time). If the problem is not painful or the segment cannot be reached, kill or reshape the bet here. See `references/interview-guide.md` for the full question bank and signal classifier. ### Phase 3: Validation experiments Convert each top-risk hypothesis into an XYZ hypothesis (Alberto Savoia): "At least X% of Y will do Z." Set X, Y, and Z before the test runs. The threshold is the decision rule, not a target you negotiate after. Run pretotypes, not prototypes: fake door, landing page with a waitlist that asks for a real commitment, concierge service where you do the work by hand, Wizard of Oz where the machinery is hidden. The whole point is measuring what people do, not what they say. Ask the market "if you buy it, we will build it" instead of "if I build it, will you buy it." Signal strength ladder, weakest to strongest: said they would use it < gave an email < paid a deposit or entered a card < came back and used it again. Collect Your Own Data (YODA); other people's success or failure with similar ideas predicts nothing about yours. Run experiments in order of riskiest assumption first, timeboxed, days not months. **Experiment exit criteria:** the XYZ threshold was met with skin-in-the-game data, or the hypothesis failed and was recorded. A failed test is a success of the process: pivot the idea or stop. If you cannot design a test where failure is possible, the hypothesis is unfalsifiable and the bet rests on faith. See `references/experiment-catalog.md` for methods, threshold-setting guidance, and the signal ladder. ### Phase 4: Unit economics projection Build the numbers from real drivers, not top-down market-share guesses. Use `bin/unit_economics.py` to compute: - Fully loaded CAC: all sales and marketing spend, salaries included, divided by new customers. Track paid-only CAC separately from blended, because blended hides what scaling paid channels will actually cost. - LTV on contribution margin, not gross revenue: SaaS LTV = ARPU x gross margin / monthly churn; e-commerce LTV = AOV x purchase frequency x lifespan x gross margin. - LTV:CAC ratio: healthy around 3:1; below 1:1 you lose money on every sale; above 5:1 you are probably underspending on growth. - CAC payback: CAC / monthly contribution per customer. Target under 12 months for early stage. A great ratio with a 36-month payback is a cash-flow problem wearing a nice outfit. - Break-even: fixed costs / contribution margin per unit. Run scenarios: what breaks if churn is 2 points worse, if CAC is 30% higher, if price is 20% lower? The projection earns its keep by showing which single lever matters most, not by producing a reassuring number. Assumptions must be sourced from Phase 2 and 3 evidence or marked as guesses with a plan to replace them. ### Phase 5: Go/no-go Write the decision memo. It answers five questions: 1. Problem validated? (Phase 2 evidence: who, what it costs them, commitments seen) 2. Solution demand evidenced? (Phase 3 results: XYZ outcomes, signal strength reached) 3. Unit economics plausible? (Phase 4: ratio, payback, break-even, biggest risk) 4. What is the riskiest remaining assumption, and what is the cheapest next experiment? 5. The call: GO (which build, capped by what), NO-GO (what killed it, what would change the answer), or REDESIGN (what to change and which phase to rerun). The decision is not "build it all" or "abandon." A GO names the smallest build that tests the next riskiest assumption. A NO-GO names what would have to change. File the memo so a future founder can learn from it either way. ## Output Contract - `validation-packet.md`: the full document, one section per phase, hypothesis register included. Every claim cites its evidence (interview quote, experiment result, or explicit "unverified assumption"). - `decision-memo.md`: the Phase 5 memo, self-contained, one page. - `bin/unit_economics.py` output appended to the packet: the projection table, benchmarks, and the single biggest lever. - No filler. If a phase produced no evidence, the packet says so plainly instead of inventing confidence. ## Operating Rules 1. Never skip phases out of order. Discovery before experiments before projections. Projections built on untested discovery are arithmetic on wishes. 2. Every factual claim in the packet is traceable to a primary source, an interview, an experiment result, or labeled as an unverified assumption. Unverifiable = cut or framed as opinion. 3. The threshold is set before the test. Moving the goalposts after results arrive is the fastest way to burn money. 4. Opinions and compliments are not evidence. Commitment is: money, time, reputation, or a signature. 5. A NO-GO is a legitimate, reportable outcome. The skill succeeds when it prevents a doomed build, not only when it blesses one. 6. Tool-agnostic: no specific platform, framework, or vendor is required for any step. If a step needs software, prefer whatever the founder already has. 7. This skill complements market sizing and GTM planning; it does not replace them. It covers only the pre-build question: should this exist at all?