Lean Startup

Intent

lean startup is the disciplined method for testing demand-side assumptions before committing capital to build-out. use it when your team faces high uncertainty about whether a specific segment will pay for a specific value prop, before locking into months of engineering. the core loop: name the riskiest assumption, design the smallest test (MVP), measure real customer behavior, then pivot or persevere. apply this when you're about to greenlight a significant build, when a pivot decision is on the table after early signals, or when someone asks "should we just build it?" without evidence anyone wants it.

do NOT use this for optimizing known business models in known conditions (that's execution, not search); for sub-business-model decisions like UI tweaks; or when you cannot ethically run a test with real customers.

Inputs

• concrete hypothesis or riskiest assumption: segment, value, willingness-to-pay, timeframe. "users want X" is too vague; "30-40 year old solopreneurs in the US with $5k/year software budget will pay $99/month for our scheduling feature by Q2 2026" is actionable.
• customer access: ability to run tests with real customers (not focus groups or stated intent). this can be minimal (landing page signup, video, concierge outreach) but must touch real people.
• time and budget for MVP: early-stage tests should time-box at 4-6 weeks max. you need enough runway to run the loop, not polish.
• pre-commitment discipline: a notebook, Slack channel, or shared doc where the threshold is written down before running the experiment. honor this; don't rationalize after.
• optional external connections:
  • analytics platform (Google Analytics, Mixpanel, Amplitude) if measuring web conversion or retention at scale. no API key needed for basic GA; connect via email.
  • payment processor (Stripe, PayPal) if testing willingness-to-pay. webhook access recommended but not required for MVP.
  • customer communication tools (email, Slack, Typeform) for outreach and feedback collection. these are low-touch and require no special setup.

Procedure

1. Identify the load-bearing assumption

input: your product idea, market, or feature pivot under consideration.

step: force the team to name ONE assumption that, if false, invalidates the business model. do not list ten; pick one. frame it specifically: " will at for by ". examples:

• "UK-based freelance designers will pay £29/month for a template library by end of Q1 2026" (specific segment, action, price, date).
• "enterprise SaaS buyers with $1M+ ARR will switch billing systems if onboarding takes <2 hours, 80%+ of the time" (segment, action, rate, condition).

output: one-sentence assumption statement, written down.

---

2. Pre-commit the pivot-or-persevere threshold

input: the assumption from step 1, plus your best guess at what success looks like (e.g., "conversion rate ≥ 5%", "day-7 retention ≥ 40%", "10 pilots signed at $50k ARR").

step: write the decision rule before running the experiment. example format:

Persevere if: [metric ≥ X]
Pivot if: [metric < X]

do not leave this ambiguous. "we'll know success when we see it" guarantees you'll rationalize a marginal result. the pre-commitment IS the discipline.

output: written threshold (e.g., "persevere if ≥ 3 paid pilots at $50k+; pivot if <2").

---

3. Design the smallest MVP that tests the assumption

input: the assumption and threshold from steps 1-2.

step: the MVP is a test instrument, not v0 of your product. it must be small enough to build in 4-6 weeks early-stage. do not confuse "MVP" with "v1 of the product shipped with full polish." common MVPs:

• landing page + email capture: for testing if a segment will volunteer contact info (crude but fast).
• video demo (3-5 minutes): for testing if a value prop resonates before building. Dropbox (2007) used this to acquire 75k signups in a week.
• concierge or "Wizard of Oz" version: you manually provide the service (or simulate it). tests if customers will actually use it and pay. common in B2B SaaS.
• pre-order or mock purchase page: directs to a thank-you page or waitlist; tests willingness-to-pay without requiring a product.
• single-feature build in a known platform: if testing a specific value prop, build it in Zapier, Airtable, or a no-code tool instead of from scratch.
• 3-5 paid pilots with a buyer: in B2B, the smallest MVP is often a handshake deal with 3-5 companies, not a general release.

time-box the MVP build. if it creeps past 6 weeks and you're still coding, you've broken the loop. cut scope or simplify.

output: one-paragraph MVP spec including what it is, why it's the smallest test, and the time-box (e.g., "2-week landing page + outreach to 50 freelancers via cold email to measure signup rate").

---

4. Define the actionable metric

input: the assumption and threshold from steps 1-2.

step: pick ONE metric that directly tests the assumption. avoid vanity metrics (signups, traffic, likes, email opens). these move with marketing spend, not product-market fit. actionable metrics:

• conversion rate: percentage of visitors who take a key action (signup, pre-order, book a call).
• willingness-to-pay: number of customers who handed over money, or committed to a paid pilot.
• retention: percentage of new users who return to the product X days later (e.g., day-7 retention ≥ 40%).
• engagement: time spent, features used, or specific actions completed (only if these directly test the assumption).

in B2B, willingness-to-pay and retention dominate. in consumer, retention is load-bearing; acquisition is optional.

example: if your assumption is "solo founders will use our scheduling feature daily," your metric is day-7 retention, NOT signups. if your assumption is "enterprise SaaS execs will pay $50k/year for our audit tool," your metric is pilots signed at $50k+, NOT demo requests.

output: metric name, definition, and the pre-committed threshold (e.g., "metric: day-7 retention; persevere if ≥ 40%; pivot if <30%").

---

5. Build and ship the MVP

input: MVP spec from step 3, time-box, and a small team.

step: keep scope ruthless. if you're tempted to add "one more feature," kill it or defer to v2. the MVP is disposable. build, ship, and move to measurement within the time-box.

output: live MVP (landing page, video, concierge service, or pre-order page) accessible to customers.

edge cases:

• if the MVP is taking longer than 4-6 weeks: pause, audit scope, cut features, or pivot to a lower-fidelity test (e.g., go from a full build to a video or concierge version).
• if you hit a technical blocker: work around it or simplify. the test is about customer demand, not engineering elegance.
• if you're building on a third-party API (e.g., OpenAI, Anthropic): test that the API cost and latency support your business model. if model pricing shifts, that's an invalidated assumption. document this as a separate load-bearing assumption if your margin depends on it.

---

6. Run the experiment and measure real behavior

input: live MVP and a way to track the metric (analytics tool, payment processor webhook, spreadsheet if manual).

step: recruit customers, run the test for the pre-agreed time window (typically 2-4 weeks early-stage). measure behavior, not intent. a customer saying "I'd definitely buy" is not evidence; a credit card charge or a day-7 return is.

collect the actual metric: conversion rate, retention, willingness-to-pay, engagement. ignore noise from a single day or a single customer. stick to the time window.

output: raw metric value (e.g., "24 signups out of 120 visitors = 20% conversion rate").

edge cases:

• low sample size (< 30 customers): the result is noisier. be more conservative in your pivot decision. if you get exactly 1 paid customer, that's a signal, but not a strong one. run longer or recruit more before pivoting.
• API rate limits or service outages: document downtime. it may invalidate parts of the test. re-run if material.
• customer acquisition cost too high to sustain: this is a signal worth documenting but doesn't invalidate the willingness-to-pay assumption. separate the two.
• empty result set (0 customers, 0 signups, 0 conversions): this is a valid signal. it's data. move to step 7.

---

7. Compare result to pre-committed threshold

input: actual metric value from step 6, pre-committed threshold from step 2.

step: do not move the goalposts. if you pre-committed "persevere if ≥ 5% conversion" and you got 4.8%, you don't persevere. the discipline is the point.

compare the two numbers. did the metric hit the threshold? yes or no.

output: result statement (e.g., "metric result: 20% conversion rate. threshold: persevere if ≥ 15%. result: PASS").

---

8. Decide pivot or persevere

input: comparison from step 7.

step: make the decision explicit. do not hedge.

persevere: the assumption held. the load-bearing metric passed. move forward on this value prop, segment, or business model. build the next iteration or scale.

pivot: the assumption failed. identify what failed (the segment was wrong, the value prop didn't resonate, the price was too high, the onboarding was broken). choose a specific pivot (change the segment, drop a feature, raise the price, simplify onboarding, etc.). re-test with a new MVP.

re-test: your result was too noisy, sample too small, or time window too short. run the experiment again with more signal.

do not pivot "because we got bored" or "because the founder had a new idea." pivot in response to invalidated assumptions and validated learnings.

output: explicit decision with rationale (e.g., "decision: PIVOT. reason: 4% conversion vs. 15% threshold. signal: concierge demo feedback showed <5 min setup time is non-negotiable; our onboarding took 45 min. new pivot: rebuild onboarding with 5-min path, re-test in 3 weeks").

edge cases:

• noisy or contradictory signals: if retention is high but conversion is low, that's two different hypotheses (people like the product once they're in, but you're not acquiring the right cohort). pivot one variable at a time or run a follow-up experiment to isolate the problem.
• external change invalidates the test (e.g., a competitor launches, a regulatory change, the API pricing changes): document it. re-run if the assumption is still live; if not, move to a new assumption.

---

9. Document and iterate

input: assumption, MVP, threshold, result, decision, and carry-forward learning from steps 1-8.

step: fill out the experiment card (see output contract, below). write down:

• the assumption you tested.
• the MVP you built (one sentence).
• the metric you tracked.
• the result (actual vs. threshold).
• the decision (persevere, pivot, or re-test) and the type of pivot if applicable.
• one sentence of validated learning (the insight that carries forward to the next loop).

this is not a 10-page doc; one-page experiment cards are fine. the point is durability: can the next person on the team or a future version of the team pick up the learning and run the next experiment?

repeat the loop with the next load-bearing assumption. each loop should close the loop (a decision made) and open the next one (a new assumption). do not run random experiments; each must flow from validated learning.

output: filled experiment card (see below).

---

Decision Points

if the team has a concrete hypothesis and signals familiarity with lean startup, run the procedure directly (step 1 onward).

if the team lacks a concrete hypothesis or signals unfamiliarity with lean startup, enter "coach mode" before running the procedure. walk them through steps 1-5 one at a time, pausing after each for their input. do not advance until they respond. this prevents cargo-cult lean startup ("we're lean because we shipped fast") and ensures the load-bearing assumption is real, not invented.

if the user says the decision is below business-model level (button color, CRM choice, which payment processor), redirect them to an execution or systems-design framework, not lean startup. lean startup is for demand-side assumptions under uncertainty, not operational tweaks.

if the user cannot access real customers (operating in a regulated market with zero customer contact, or only has access to focus groups or surveys), acknowledge the constraint and pivot to surveying a proxy or running a thought-experiment variant. flag this limitation in the experiment card.

if the MVP time-box creeps past 6 weeks without shipping, halt and audit scope. cut features, simplify, or move to a lower-fidelity test (concierge instead of build, video instead of concierge). do not chase "one more feature" at the cost of the loop.

if the result is below the pre-committed threshold and the team wants to rationalize it anyway, hold the line: the pre-commitment is the discipline. if you want to change the threshold, that's a new experiment with a new threshold, not a retroactive adjustment.

if the metric is a vanity metric (signups without conversion, likes, email opens), flag it and ask: "does this directly test whether the segment will pay for the value prop?" if no, switch to an actionable metric or re-run the test.

if the team is pivoting because the founder got bored or "has a better idea," pause and ask: "is this a response to an invalidated assumption and validated learning, or is this restlessness?" if restlessness, defer the pivot or run it as a parallel experiment.

---

Output Contract

Experiment Card

Assumption: "<segment> will <action> at <rate> for <value> by <date>"
Threshold: Persevere if <metric ≥ X> | Pivot if <metric < X>
MVP: <what / why smallest / time-box ≤ 4, 6 wk>
Metric: <actionable> | Vanity to ignore: <list>
Result: <actual value> vs. <threshold>
Decision: [ ] Persevere  [ ] Pivot (type: ___)  [ ] Re-test
Validated learning: <one sentence carry-forward to next experiment>

format: text, markdown, or a shared doc. one card per experiment loop. keep it visible (Slack thread, GitHub issue, notion database) so the team refers to it, not past intuition.

location: checked into version control (GitHub, Notion, or a shared folder) so future team members can see the full sequence of assumptions tested and learnings collected. if you're a solo founder or very early, a simple spreadsheet or Markdown file suffices.

data detail: include raw numbers (e.g., "24 signups / 120 visitors = 20% conversion") so others can audit the decision. if the threshold was "≥ 15%" and you got "20%", the card should show both.

---

Outcome Signal

you know the skill worked when:

• the load-bearing assumption is written down in specific form (segment, action, rate, value, date), not vague ("users want X").
• the pivot-or-persevere threshold is pre-committed in writing before the experiment runs. this prevents rationalization.
• the MVP shipped within 4-6 weeks without scope creep. it's small, disposable, and a test instrument, not v0 of the product.
• you collected an actionable metric (conversion, retention, willingness-to-pay), not vanity metrics (signups, likes).
• the result is compared to the pre-committed threshold without moving the goalposts. if the metric didn't hit the threshold, you acknowledged it.
• the decision (persevere, pivot, or re-test) is explicit and made in writing. no hedging, no "let's wait and see." if pivoting, the type of pivot is named (change segment, drop feature, simplify onboarding, etc.).
• one sentence of validated learning is documented, carrying forward to the next experiment. this ensures each loop closes and opens the next one.
• the experiment card is stored durably (version control, shared doc) so future team members or future versions of the team can see the full sequence and avoid repeating failed assumptions.
• the team ran the loop faster than expected. lean startup compresses the time from "should we build it?" to "we have evidence we should (or shouldn't)" from months to weeks. if you ran three experiments in three months and made a confident pivot decision, the skill worked.
• the team stopped asking "how do we know if anyone wants this?" and started asking "which assumption do we test next?" the skill is working when it shifts the team's language from doubt to disciplined iteration.

---

Red Flags

• the team is building for months with no MVP yet shipped.
• "MVP" is a six-month build with full polish.
• vanity metrics dominate the dashboard; conversion, retention, willingness-to-pay are absent or untracked.
• customer interviews reported as "they love it" with no behavioral data (no re-engagement, no payment, no pre-order).
• pivot decisions made on a single week's noise, or after founders simply got bored, with no documented