{"id":"8b78c8a5-e5be-4f56-8455-ea3ad3816fee","entityType":"agent","slug":"clawhub-deciqai-lean-startup","name":"Lean Startup","canonicalUrl":"https://www.xpersona.co/agent/clawhub-deciqai-lean-startup","canonicalPath":"/agent/clawhub-deciqai-lean-startup","generatedAt":"2026-10-11T20:56:27.115Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T15:57:55.272Z","emptyReason":null},"description":"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te... Skill: Lean Startup Owner: deciqai Summary: Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te... Tags: latest:1.0.4 Version history: v1.0.4 | 2026-07-16T18:04:47.149Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/lean-startup.json) v1.0.3 | 2026-07-08T11:07:40.103Z | user F","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:lean-startup","sourceUrl":"https://clawhub.ai/deciqai/lean-startup","homepage":"https://clawhub.ai/deciqai/skills/lean-startup","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/deciqai/lean-startup","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/deciqai/skills/lean-startup","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:57:55.272Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:57:55.272Z","emptyReason":null},"stars":null,"forks":null,"downloads":1033,"packageName":null,"latestVersion":"1.0.4","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T15:57:55.206Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T15:57:55.272Z","lastCrawledAt":"2026-10-11T15:57:55.206Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T15:57:55.206Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.4","createdAt":"2026-07-16T18:04:47.149Z","changelog":"Description tail link + agents machine-readable metadata line (deciqai.com/s/lean-startup.json)","fileCount":7,"zipByteSize":14742},{"version":"1.0.3","createdAt":"2026-07-08T11:07:40.103Z","changelog":"Footer now uses /c/ short link (fixes UTM truncation when SKILL.md is read in a terminal)","fileCount":7,"zipByteSize":14565},{"version":"1.0.2","createdAt":"2026-07-08T00:52:26.756Z","changelog":"Refreshed content + GitHub star link in footer","fileCount":6,"zipByteSize":11205},{"version":"1.0.1","createdAt":"2026-07-07T22:28:07.768Z","changelog":"Add catalog categories and topics","fileCount":5,"zipByteSize":8543},{"version":"1.0.0","createdAt":"2026-06-29T10:17:16.748Z","changelog":"Initial publish","fileCount":5,"zipByteSize":8524}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:lean-startup","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T20:56:27.111Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-lean-startup/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T15:57:55.272Z","emptyReason":null},"readme":"Skill: Lean Startup\n\nOwner: deciqai\n\nSummary: Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te...\n\nTags: latest:1.0.4\n\nVersion history:\n\nv1.0.4 | 2026-07-16T18:04:47.149Z | user\n\nDescription tail link + agents machine-readable metadata line (deciqai.com/s/lean-startup.json)\n\nv1.0.3 | 2026-07-08T11:07:40.103Z | user\n\nFooter now uses /c/ short link (fixes UTM truncation when SKILL.md is read in a terminal)\n\nv1.0.2 | 2026-07-08T00:52:26.756Z | user\n\nRefreshed content + GitHub star link in footer\n\nv1.0.1 | 2026-07-07T22:28:07.768Z | user\n\nAdd catalog categories and topics\n\nv1.0.0 | 2026-06-29T10:17:16.748Z | user\n\nInitial publish\n\nArchive index:\n\nArchive v1.0.4: 7 files, 14742 bytes\n\nFiles: examples/ai-native-lean-startups-2023-2026.md (5793b), examples/dropboxs-video-mvp-2007.md (3413b), examples/votizens-pivot-sequence-2010-2011.md (4571b), references/sources.md (2042b), skill-card.md (2789b), SKILL.md (9865b), _meta.json (131b)\n\nFile v1.0.4:SKILL.md\n\n---\nname: lean-startup\ndescription: \"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to test this idea before building', or 'how do we know if anyone wants this?'; team is about to build something significant before testing demand; a pivot decision is on the table after early data.\n Do NOT activate when: operating a known business model in known conditions (use execution frameworks instead); decision is below business-model level (button color, which CRM). More: deciqai.com/c/lean-startup\"\n---\n\n# Lean Startup\n\n## Overview\n\nA startup is a **temporary organization searching for a repeatable, scalable business model under extreme uncertainty** (Steve Blank). Most early-stage failures are from building something no one wanted because the demand assumption was never tested.\n\n**Eric Ries** (2011): name the riskiest assumption, build the smallest test (MVP), measure real behavior, decide to **pivot or persevere** — the **Build–Measure–Learn loop**, run as fast as possible.\n\n**Compose:** first-principles to find what the model truly depends on; probabilistic-thinking to calibrate experiments; inversion before each Build phase; business-model-canvas to surface the riskiest assumption blocks.\n\n## When to Use\n\nApply when: high uncertainty + limited capital; a team is about to build before testing demand; a pivot-or-persevere decision is on the table; you're building an AI feature on a foundation-model API and worried \"the next model release will commoditize us\" / \"are we just a GPT wrapper?\"; no clear answer to \"what is the load-bearing assumption and how would we know if it's wrong?\"\n\n**When NOT to use:** known business model in known conditions (execution, not search); decision is not business-model-level; cannot ethically run a test with real customers; using \"lean\" as a schedule excuse to ship buggy software.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete hypothesis → run The Process directly.\n- **Coach mode:** no concrete hypothesis or signals unfamiliarity → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. **One-line what-it-is.** Most startups fail by building before knowing if anyone wants it; lean startup names the riskiest assumption, tests it with the smallest MVP, measures real behavior, and decides pivot or persevere — fast.\n2. **Check fit.** Match against When to Use / When NOT to use; if low uncertainty + known model, redirect.\n3. **Elicit their real hypothesis.** Force them to name one load-bearing assumption — specific segment, specific value, specific willingness-to-pay.\n> **[WAIT — do not advance until user responds]**\n4. **Walk the loop step by step.** Name assumption → design MVP → define metric → set threshold. Pause at each.\n> **[WAIT — do not advance until user responds]**\n5. **Close by naming the next-week experiment.** One assumption, one MVP, one threshold, one date — not a strategy doc.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Build–Measure–Learn cycle**. Identify, test, decide.\n\n1. **State the load-bearing assumption.** Specific segment, specific value, specific willingness-to-pay, specific timeframe. Not \"users want X.\"\n2. **Pre-commit to a pivot-or-persevere threshold.** Write the metric value *before* running the experiment. You will rationalize if you have not pre-committed.\n3. **Design the smallest MVP that tests the assumption.** Often not a product — a landing page, concierge/\"Wizard of Oz\" version, or 3-minute video. Purpose is *learning*, not selling.\n4. **Build the MVP fast.** Time-box. If an early-stage test takes more than 4–6 weeks, cut.\n5. **Measure real customer behavior, not stated intent.** Actionable metrics (conversion, retention, willingness-to-pay) test the assumption. Vanity metrics (signups, likes) do not.\n6. **Compare result to the pre-committed threshold.** Don't move the goalposts.\n7. **Decide pivot or persevere — explicitly.** Persevere = assumption held; pivot = assumption failed in a specific way, change the load-bearing block and re-test.\n8. **Document and iterate.** Write: assumption, MVP, threshold, result, decision, rationale. Each loop must produce a durable carry-forward learning.\n\n### Output: Experiment Card\n\n```\nAssumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: \n```\n\n*→ Method in Action: [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md) · [Votizen's Pivot Sequence (2010–2011)](examples/votizens-pivot-sequence-2010-2011.md)*\n*→ 2026 lens: [AI-native lean startups (2023–2026)](examples/ai-native-lean-startups-2023-2026.md) — when the next model release commoditizes your AI feature, that's an invalidated assumption, not bad luck*\n## Experiment Packs\n\n| Domain | Load-bearing assumption | MVP type | Common failure |\n|---|---|---|---|\n| Consumer apps | install + day-7 retention | concierge, video, single-feature build | testing acquisition, ignoring retention |\n| B2B SaaS | willingness-to-pay vs. specific budget owner | pre-order page or 3–5 paid pilots | talking to users (love it), not buyers (hold budget) |\n| Two-sided marketplaces | liquidity on the harder side (usually supply) | manually-matched concierge, single ZIP | launching both sides at once |\n| Hardware | people willing to pay (not just click) | video demo + Kickstarter or pre-order | conflating click-throughs with payment intent |\n\n## Applying It Well\n\n- MVPs are for learning, not revenue — the deliverable is evidence, not a launch.\n- Pre-commit to the threshold or you will rationalize whatever you get.\n- In B2B, talk to buyers (hold budget), not just users (love the product).\n- Vanity metrics (signups, likes) ≠ actionable metrics (conversion, retention, willingness-to-pay).\n- The MVP is disposable — a test instrument, not v0 of your product.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **\"We're lean\" while shipping a six-month build with no validated demand** | Lean Startup is a loop, not a label. If you haven't tested the load-bearing demand assumption before building, you are doing waterfall. |\n| [D] **MVP confused with v1 of the product** | The MVP is a test instrument, designed to be disposable. Polishing it as v1 inflates scope and breaks the loop. |\n| [D] **No pre-committed pivot/persevere threshold** | Without it, you will explain any result. The pre-commitment IS the discipline. |\n| [D] **Counting vanity metrics** (signups, traffic, likes) | These move with marketing spend, not product-market fit. Actionable metrics test the assumption. |\n| [D] **Talking only to users, not buyers** (especially in B2B) | User love is necessary but not sufficient. The buyer's willingness-to-pay is the load-bearing test. |\n| [D] **\"The customer said they'd buy\"** | Stated intent is famously unreliable. Measure behavior (a credit card swipe, retention to day 7), not intent. |\n| [D] **Pivoting on noise** | A single bad week is not a signal to pivot. Pre-commit the threshold and time-window; pivot only when both fire. |\n| [D] **Pivoting \"because we got bored\"** | A pivot is a response to invalidated assumptions, not to founder restlessness. |\n| [D] **Using \"lean\" as schedule cover** | Lean is not \"ship buggy fast.\" It is \"test the demand-side assumption before building the supply-side capability.\" |\n| [D] **No documented validated learning** | If each loop doesn't produce a written carry-forward insight, you are running random experiments. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n## Red Flags\n\n- The team is building for months with no MVP yet shipped\n- \"MVP\" is a six-month build with full polish\n- Vanity metrics dominate the dashboard; conversion/retention/willingness-to-pay are absent or untracked\n- Customer interviews reported as \"they love it\" with no behavioral data\n- Pivot decisions made on a single week's noise, or after founders simply got bored\n- No pre-committed pivot/persevere threshold exists for any experiment\n- \"Lean\" is being used to justify low-quality shipping rather than test-before-build\n## Verification\n\n- [ ] The load-bearing assumption is named in specific segment/value/willingness-to-pay/timeframe form\n- [ ] The pivot-or-persevere threshold is pre-committed in writing, before the experiment runs\n- [ ] The MVP is the smallest test of the assumption (time-boxed ≤ 4–6 weeks early-stage)\n- [ ] An *actionable* metric (not vanity) is pre-specified for evaluation\n- [ ] Result is compared to the pre-committed threshold — without moving goalposts\n- [ ] Pivot vs. persevere decision is made explicitly, with type if pivoting\n- [ ] Validated learning is documented in one sentence carry-forward\n---\n\n*Part of **deciqAI Knowledge Skills** — 227 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/lean-startup** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\n*Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/lean-startup.json*\n\nFile v1.0.4:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"lean-startup\",\n \"version\": \"1.0.4\",\n \"publishedAt\": 1784225087149\n}\n\nFile v1.0.4:references/sources.md\n\n# Sources — lean-startup\n\n> *Primary sources for the [lean-startup](../SKILL.md) skill.*\n\n- **Ries, Eric.** *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown, 2011. **Canonical primary source** for Lean Startup and Build-Measure-Learn; verbatim Overview quote is p. 9; Dropbox case discussion pp. 99–101; Votizen pivot sequence opens ch. 8, \"Pivot (or Persevere)\".\n- **Blank, Steve.** *The Four Steps to the Epiphany: Successful Strategies for Products That Win*. K&S Ranch, 2nd ed. 2013 (orig. self-published 2005). **Primary source** for the Customer Development methodology that grounds Lean Startup.\n- **Blank, Steve.** \"Why the Lean Start-Up Changes Everything.\" *Harvard Business Review*, May 2013. The methodology's founder synthesizing the framework for HBR. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything\n- **Houston, Drew.** Original 2007 Dropbox demo video (the MVP) — currently re-hosted at: https://www.youtube.com/watch?v=7QmCUDHpNzE\n- **Sequoia Capital, Dropbox pitch deck, 2007** — primary-source artifact from the early Dropbox story.\n- **OpenAI.** \"Introducing ChatGPT.\" 30 November 2022. https://openai.com/index/chatgpt/ — public marker for the foundation-model API wave that made the *Build* phase nearly free for AI-native startups (2023–2026 example).\n- **Reuters / Associated Press / Financial Times**, late January 2025 coverage of DeepSeek's low-cost open-weight model release and the ~27 January 2025 selloff in Nvidia and AI-linked equities — durable, widely-reported reminder that AI moat/cost assumptions can reset without warning (2023–2026 example). Exact intraday figures varied by source and are cited qualitatively.\n- The popular framing \"fail fast\" is **not** cited here as a source — by this skill's own rule, an aphorism is not evidence. Lean Startup is more precisely \"**test cheaply** the demand-side assumption *before* paying to build the supply-side capability\"; failure speed is incidental.\n\nFile v1.0.4:examples/ai-native-lean-startups-2023-2026.md\n\n# Method in Action: AI-Native Lean Startups (2023–2026)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA 2026 lens on the same loop. Not a prediction of which company wins — a worked example of how Build–Measure–Learn behaves when the *supply-side capability* is a rented foundation model that a competitor's next release can commoditize overnight.\n\nAfter the November 2022 release of ChatGPT and the 2023–2024 arrival of capable foundation-model APIs (OpenAI, Anthropic, Google), a wave of small teams built products as thin layers over these models. The economics inverted the classic build cost: a two-person team could ship a working AI feature in days by calling an API, rather than spending months training a model. This made the *Build* phase almost free — and moved the real risk somewhere the Lean Startup framework anticipates but that demo culture ignores.\n\nThe recurring 2023–2026 failure pattern: a startup demos an impressive AI feature, raises on the demo, and then a subsequent model release from the underlying provider (or an open-weight model) absorbs that feature into the base capability — the \"GPT-wrapper gets wrapped\" problem. The dramatic public reminder came in **January 2025**, when the Chinese lab **DeepSeek** released a strong, low-cost open-weight reasoning model; the reaction rippled through markets and, on **27 January 2025**, Nvidia's share price fell sharply in a single session — a widely reported signal that the cost and moat assumptions underpinning many AI plans could shift without warning.\n\nThe Lean Startup correction: in an AI-native startup, the load-bearing assumption is almost never \"can we build the feature?\" (you can — cheaply). It is **\"does a specific customer keep using and paying for the workflow *after* the underlying model capability becomes a commodity available to everyone?\"** That is a retention-and-willingness-to-pay assumption, and it is exactly what a demo does not test.\n\nWalk the Experiment Card on a representative AI-native workflow product (a small team building an AI tool for a specific professional segment):\n\n- **Load-bearing assumption (Step 1):** *A defined professional segment (say, mid-market legal or support teams) will adopt an AI-drafting workflow, retain it past day-30, and pay a per-seat fee — where the retained value comes from our proprietary data/workflow/integration, not from raw model capability any competitor can also call.* Specific segment, specific value, specific willingness-to-pay, specific timeframe — not \"people want AI.\"\n- **Pre-commit to a threshold (Step 2):** Write the pivot bar before building — e.g. *persevere only if paid day-30 retention clears a stated bar and the value survives a hypothetical \"the base model now does the naive version for free\" test.* Pre-committing matters more here because a slick demo tempts you to rationalize any signal into a persevere.\n- **Design the smallest MVP (Step 3):** Because the model is rented, the MVP is not \"train a model.\" It is a landing page, a concierge/\"Wizard of Oz\" run over an existing API, or a single-workflow build for a handful of design-partner accounts — a *learning* instrument, not the product. Purpose is to isolate durable value from model novelty.\n- **Build fast (Step 4):** Time-boxed. The API makes this the cheapest Build phase in startup history — which is precisely why teams over-build polish and skip the demand test. Cut anything past the 4–6 week early-stage box.\n- **Measure real behavior (Step 5):** Paid retention and expansion within design-partner accounts — actionable. Demo applause, waitlist size, and social virality are vanity metrics that move with model hype, not with durable fit.\n- **Compare to threshold (Step 6):** Judge against the pre-committed bar, including the commoditization stress test. If retained usage evaporated the moment the base model improved, the value was model novelty, not your product.\n- **Decide pivot or persevere (Step 7):** *Persevere* only if durable, model-independent value holds. Otherwise **pivot** — and the AI-native pivots mirror the classic types: move up the stack toward proprietary data and integrations; pivot customer segment; or pivot from a commoditized feature to the workflow/system-of-record around it. When the next model release \"eats\" your feature, that is not bad luck — it is an invalidated assumption firing exactly as the loop predicts.\n- **Document and iterate (Step 8):** Carry forward one durable learning per loop: *which* part of the value was model-independent and which was borrowed from the provider. That distinction is the compounding asset across the fast, frequent loops the AI stack enables.\n\nThe key feature of this case for the Lean Startup canon: cheap models make *building* nearly free, so the discipline shifts almost entirely onto **testing the right assumption** — durable, model-independent retention and willingness-to-pay — and **pre-committing a threshold that a demo cannot flatter you past**. The impressive demo is not the product; like Dropbox's video, it is a disposable test instrument. In 2023–2026 the trap is mistaking the demo's applause for validated learning while a competitor's next release quietly resets the moat.\n\n*Sources: OpenAI, \"Introducing ChatGPT,\" 30 November 2022 (openai.com/index/chatgpt/). DeepSeek's late-January 2025 open-weight model release and the ~27 January 2025 selloff in Nvidia and AI-linked equities, as widely reported by Reuters, the Associated Press, and the Financial Times. Ries, Eric, *The Lean Startup* (Crown, 2011) — Build–Measure–Learn, MVP, and pivot-or-persevere framework applied here. Figures on the market reaction are given qualitatively; exact intraday percentages varied by source and session.*\n\nFile v1.0.4:examples/dropboxs-video-mvp-2007.md\n\n# Method in Action: Dropbox's Video MVP (2007)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA worked example. Not founder hagiography — primary-source documented.\n\nIn **2007**, **Drew Houston** had built an early prototype of what would become Dropbox: cloud file synchronization with conflict-free updates across devices. The space was crowded with incumbents (Microsoft Live Mesh, FolderShare, Mozy, Carbonite, Apple's planned iDisk), and the prototype's killer feature — a kernel-level filesystem driver that just-worked on Mac, Windows, and Linux — was hard to demonstrate without a working installer on every OS.\n\nHouston faced the classic Lean Startup question: **before committing months of engineering to a polished cross-platform release, was the load-bearing demand assumption true?** Specifically: would early-adopter tech users, given a frictionless sync experience, be willing to share email addresses and try the product in numbers large enough to validate a freemium-to-paid funnel?\n\nHis MVP was a **3-minute screencast video** posted to Hacker News and Digg in late 2007, demonstrating the working prototype: drag a file into a folder, watch it appear on another machine seconds later, watch conflict resolution work cleanly. The video referenced specific tech-community in-jokes (XKCD references, music chosen for the audience) — Drew explicitly designed it for the *Hacker News* / *Digg* segment most likely to convert.\n\nThe result: **the beta waiting list jumped from roughly 5,000 to 75,000 overnight** — a measurable, actionable spike directly attributable to a single MVP costing only the time to film the video. Eric Ries described this exact case in *The Lean Startup* as a textbook example of a video MVP testing demand before building.\n\nWalk the Experiment Card on Dropbox's 2007 video MVP:\n\n- **Load-bearing assumption (Step 1):** *Early-adopter tech users (HN/Digg-readers) will sign up for a waitlist for frictionless cross-device file sync in numbers large enough to suggest a viable freemium-to-paid funnel.*\n- **Pre-committed threshold (Step 2):** Houston has not published the exact pre-committed number, but the 15× jump in beta waitlist signups would have cleared almost any reasonable pre-committed threshold.\n- **MVP design (Step 3):** A 3-minute screencast video, not a working installer. The minimum thing that could elicit signup behavior. Time-box: days, not months.\n- **Measurement (Step 4):** Waitlist signups in the 72 hours post-publication, segmented by referrer source (HN vs. Digg vs. organic).\n- **Result vs. threshold (Step 5):** Signup spike from ~5K to ~75K. Strongly above any reasonable threshold for \"demand exists.\"\n- **Decision (Step 6):** **Persevere.** Build the cross-platform client; the demand assumption holds. (Houston did exactly this through 2008; Dropbox launched publicly in September 2008.)\n- **Validated learning (Step 7):** *Tech-segment early-adopters will give email addresses for a frictionless-sync promise; the freemium funnel is worth building.*\n\nThe key feature of this case for the Lean Startup canon: **the MVP cost essentially nothing**, **tested a specific assumption** (demand at scale for sync among the target segment), and **produced a clear actionable signal** that justified the much-larger build that followed. The video is not Dropbox's product; it is the disposable test that justified the product.\n\nFile v1.0.4:examples/votizens-pivot-sequence-2010-2011.md\n\n# Method in Action: Votizen's Pivot Sequence (2010–2011)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nThe Dropbox example ends in **persevere**. This case shows the other branch — the one the loop exists for. It is the case Eric Ries himself uses to open his treatment of the pivot in *The Lean Startup* (2011).\n\n**David Binetti** — a Silicon Valley veteran who had helped build USA.gov in the 1990s — founded **Votizen** on a civic-tech thesis: citizens wanted a **social network of verified registered voters**, where political identity was authenticated against public voter rolls rather than self-declared. The load-bearing assumption was not \"people care about politics.\" It was specific and testable: *citizens will sign up, verify their voter registration, invite friends, and keep coming back.*\n\n**The first experiment.** Instead of building the full vision, Binetti shipped a minimum viable product in about **three months for roughly $1,200** — just enough to test the four behaviors the model depended on. Ries breaks the assumption into four actionable metrics: **registration** (do they sign up?), **activation** (do they verify voter status?), **referral** (do they invite others?), **retention** (do they come back?). Vanity metrics — press coverage, raw traffic — were deliberately not the scoreboard.\n\n**The measurement.** Baseline funnel numbers came back far below what a viable consumer product needs (Ries reports the exact percentages in the book). Binetti did not pivot on the first bad reading: he spent the following months running disciplined split-tests on onboarding and messaging. Activation improved substantially under optimization — but **referral and retention barely moved**. A funnel that optimization cannot fix is not a tuning problem; it is an invalidated assumption.\n\n**Pivot one.** Binetti compared the result to what any honest persevere bar would require and pivoted — while **preserving the validated learning**: voter-roll identity verification worked and was valued; the social network around it was not. The new product, **@2gov**, dropped the network entirely. It let citizens contact their Congressional representatives through Twitter, with Votizen verifying the sender as a real registered voter and delivering the message through official channels.\n\n**The second loop.** Engagement metrics on @2gov came back dramatically stronger — the civic-contact behavior was real. But the loop now exposed the next load-bearing assumption: *consumers will pay for this.* They would not. High activity, negligible willingness-to-pay. Stated enthusiasm failed the behavioral test that matters — the payment.\n\n**Pivot two.** A customer-segment pivot: keep the verified voter-contact capability, change who pays. Votizen turned to **organizations** — advocacy groups and political campaigns — as paying customers for authenticated voter-to-voter contact. Willingness-to-pay validated where the consumer model had failed, and Binetti went on to raise funding from prominent Silicon Valley investors on the back of the validated model.\n\nEach cycle ran the same discipline: name the assumption, ship the smallest test, measure behavior against the assumption, decide explicitly. Nothing was rationalized into a persevere; nothing was pivoted on noise or boredom.\n\nThe mapped steps:\n\n1. Load-bearing assumption stated specifically: citizens will register, verify, refer, and retain on a verified-voter social network — not \"people want civic tools\"\n2. Smallest MVP: ~3 months, ~$1,200 — a test instrument for four behaviors, not v1 of the vision\n3. Actionable metrics pre-specified: registration, activation, referral, retention; press and traffic ignored as vanity\n4. Result vs. threshold, honestly: split-tests lifted activation, but referral and retention stayed flat — the assumption failed in a specific way\n5. Pivot, preserving validated learning: verified-voter identity carried forward into @2gov; the social network dropped\n6. Loop re-run on the new assumption: engagement validated, consumer willingness-to-pay invalidated by behavior, not surveys\n7. Second pivot (customer segment): from consumers to paying organizations — the revenue assumption finally holds\n8. Documented learning compounds across loops, ending in a fundable, revenue-bearing model\n\nPrimary source: Ries, Eric (2011). *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown. Votizen pivot sequence documented in Chapter 8, \"Pivot (or Persevere).\"\n\nFile v1.0.4:skill-card.md\n\n## Description:\n\nGuides agents through Lean Startup coaching: identify the riskiest business-model assumption, design a minimal MVP, measure real customer behavior, and decide whether to pivot or persevere.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[deciqai](https://clawhub.ai/user/deciqai)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal users, founders, product teams, and agents use this skill to structure startup uncertainty into testable MVP experiments with pre-committed metrics and pivot-or-persevere decisions. It is most relevant when demand, willingness-to-pay, retention, or durable AI-workflow value remains unvalidated.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad activation terms may bring this skill into ordinary product or build-planning discussions where a narrower execution framework would be better.\n\nMitigation: Check fit before applying it: use the skill for business-model uncertainty and pivot-or-persevere decisions, and redirect known-model execution work to a more appropriate framework.\n\nRisk: Lean Startup framing can be misused as schedule cover for low-quality shipping rather than disciplined demand testing.\n\nMitigation: Require a named load-bearing assumption, a smallest ethical MVP, an actionable metric, and a pre-committed threshold before recommending build work.\n\n## Reference(s):\n\n- [Sources - lean-startup](references/sources.md)\n- [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md)\n- [Votizen's Pivot Sequence (2010-2011)](examples/votizens-pivot-sequence-2010-2011.md)\n- [AI-Native Lean Startups (2023-2026)](examples/ai-native-lean-startups-2023-2026.md)\n- [Why the Lean Start-Up Changes Everything](https://hbr.org/2013/05/why-the-lean-start-up-changes-everything)\n- [Dropbox 2007 Demo Video](https://www.youtube.com/watch?v=7QmCUDHpNzE)\n- [Introducing ChatGPT](https://openai.com/index/chatgpt/)\n- [Lean Startup Skill Page](https://clawhub.ai/deciqai/skills/lean-startup)\n- [Lean Startup Machine-Readable Metadata](https://www.deciqai.com/s/lean-startup.json)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown coaching steps and experiment-card templates]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May stop at explicit wait points when coaching novices through hypothesis, MVP, metric, and threshold definition.]\n\n## Skill Version(s):\n\n1.0.4 (source: server release evidence and target metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.3: 7 files, 14565 bytes\n\nFiles: examples/ai-native-lean-startups-2023-2026.md (5793b), examples/dropboxs-video-mvp-2007.md (3413b), examples/votizens-pivot-sequence-2010-2011.md (4571b), references/sources.md (2042b), skill-card.md (2634b), SKILL.md (9730b), _meta.json (131b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: lean-startup\ndescription: \"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to test this idea before building', or 'how do we know if anyone wants this?'; team is about to build something significant before testing demand; a pivot decision is on the table after early data.\n Do NOT activate when: operating a known business model in known conditions (use execution frameworks instead); decision is below business-model level (button color, which CRM).\"\n---\n\n# Lean Startup\n\n## Overview\n\nA startup is a **temporary organization searching for a repeatable, scalable business model under extreme uncertainty** (Steve Blank). Most early-stage failures are from building something no one wanted because the demand assumption was never tested.\n\n**Eric Ries** (2011): name the riskiest assumption, build the smallest test (MVP), measure real behavior, decide to **pivot or persevere** — the **Build–Measure–Learn loop**, run as fast as possible.\n\n**Compose:** first-principles to find what the model truly depends on; probabilistic-thinking to calibrate experiments; inversion before each Build phase; business-model-canvas to surface the riskiest assumption blocks.\n\n## When to Use\n\nApply when: high uncertainty + limited capital; a team is about to build before testing demand; a pivot-or-persevere decision is on the table; you're building an AI feature on a foundation-model API and worried \"the next model release will commoditize us\" / \"are we just a GPT wrapper?\"; no clear answer to \"what is the load-bearing assumption and how would we know if it's wrong?\"\n\n**When NOT to use:** known business model in known conditions (execution, not search); decision is not business-model-level; cannot ethically run a test with real customers; using \"lean\" as a schedule excuse to ship buggy software.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete hypothesis → run The Process directly.\n- **Coach mode:** no concrete hypothesis or signals unfamiliarity → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. **One-line what-it-is.** Most startups fail by building before knowing if anyone wants it; lean startup names the riskiest assumption, tests it with the smallest MVP, measures real behavior, and decides pivot or persevere — fast.\n2. **Check fit.** Match against When to Use / When NOT to use; if low uncertainty + known model, redirect.\n3. **Elicit their real hypothesis.** Force them to name one load-bearing assumption — specific segment, specific value, specific willingness-to-pay.\n> **[WAIT — do not advance until user responds]**\n4. **Walk the loop step by step.** Name assumption → design MVP → define metric → set threshold. Pause at each.\n> **[WAIT — do not advance until user responds]**\n5. **Close by naming the next-week experiment.** One assumption, one MVP, one threshold, one date — not a strategy doc.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Build–Measure–Learn cycle**. Identify, test, decide.\n\n1. **State the load-bearing assumption.** Specific segment, specific value, specific willingness-to-pay, specific timeframe. Not \"users want X.\"\n2. **Pre-commit to a pivot-or-persevere threshold.** Write the metric value *before* running the experiment. You will rationalize if you have not pre-committed.\n3. **Design the smallest MVP that tests the assumption.** Often not a product — a landing page, concierge/\"Wizard of Oz\" version, or 3-minute video. Purpose is *learning*, not selling.\n4. **Build the MVP fast.** Time-box. If an early-stage test takes more than 4–6 weeks, cut.\n5. **Measure real customer behavior, not stated intent.** Actionable metrics (conversion, retention, willingness-to-pay) test the assumption. Vanity metrics (signups, likes) do not.\n6. **Compare result to the pre-committed threshold.** Don't move the goalposts.\n7. **Decide pivot or persevere — explicitly.** Persevere = assumption held; pivot = assumption failed in a specific way, change the load-bearing block and re-test.\n8. **Document and iterate.** Write: assumption, MVP, threshold, result, decision, rationale. Each loop must produce a durable carry-forward learning.\n\n### Output: Experiment Card\n\n```\nAssumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: \n```\n\n*→ Method in Action: [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md) · [Votizen's Pivot Sequence (2010–2011)](examples/votizens-pivot-sequence-2010-2011.md)*\n*→ 2026 lens: [AI-native lean startups (2023–2026)](examples/ai-native-lean-startups-2023-2026.md) — when the next model release commoditizes your AI feature, that's an invalidated assumption, not bad luck*\n## Experiment Packs\n\n| Domain | Load-bearing assumption | MVP type | Common failure |\n|---|---|---|---|\n| Consumer apps | install + day-7 retention | concierge, video, single-feature build | testing acquisition, ignoring retention |\n| B2B SaaS | willingness-to-pay vs. specific budget owner | pre-order page or 3–5 paid pilots | talking to users (love it), not buyers (hold budget) |\n| Two-sided marketplaces | liquidity on the harder side (usually supply) | manually-matched concierge, single ZIP | launching both sides at once |\n| Hardware | people willing to pay (not just click) | video demo + Kickstarter or pre-order | conflating click-throughs with payment intent |\n\n## Applying It Well\n\n- MVPs are for learning, not revenue — the deliverable is evidence, not a launch.\n- Pre-commit to the threshold or you will rationalize whatever you get.\n- In B2B, talk to buyers (hold budget), not just users (love the product).\n- Vanity metrics (signups, likes) ≠ actionable metrics (conversion, retention, willingness-to-pay).\n- The MVP is disposable — a test instrument, not v0 of your product.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **\"We're lean\" while shipping a six-month build with no validated demand** | Lean Startup is a loop, not a label. If you haven't tested the load-bearing demand assumption before building, you are doing waterfall. |\n| [D] **MVP confused with v1 of the product** | The MVP is a test instrument, designed to be disposable. Polishing it as v1 inflates scope and breaks the loop. |\n| [D] **No pre-committed pivot/persevere threshold** | Without it, you will explain any result. The pre-commitment IS the discipline. |\n| [D] **Counting vanity metrics** (signups, traffic, likes) | These move with marketing spend, not product-market fit. Actionable metrics test the assumption. |\n| [D] **Talking only to users, not buyers** (especially in B2B) | User love is necessary but not sufficient. The buyer's willingness-to-pay is the load-bearing test. |\n| [D] **\"The customer said they'd buy\"** | Stated intent is famously unreliable. Measure behavior (a credit card swipe, retention to day 7), not intent. |\n| [D] **Pivoting on noise** | A single bad week is not a signal to pivot. Pre-commit the threshold and time-window; pivot only when both fire. |\n| [D] **Pivoting \"because we got bored\"** | A pivot is a response to invalidated assumptions, not to founder restlessness. |\n| [D] **Using \"lean\" as schedule cover** | Lean is not \"ship buggy fast.\" It is \"test the demand-side assumption before building the supply-side capability.\" |\n| [D] **No documented validated learning** | If each loop doesn't produce a written carry-forward insight, you are running random experiments. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n## Red Flags\n\n- The team is building for months with no MVP yet shipped\n- \"MVP\" is a six-month build with full polish\n- Vanity metrics dominate the dashboard; conversion/retention/willingness-to-pay are absent or untracked\n- Customer interviews reported as \"they love it\" with no behavioral data\n- Pivot decisions made on a single week's noise, or after founders simply got bored\n- No pre-committed pivot/persevere threshold exists for any experiment\n- \"Lean\" is being used to justify low-quality shipping rather than test-before-build\n## Verification\n\n- [ ] The load-bearing assumption is named in specific segment/value/willingness-to-pay/timeframe form\n- [ ] The pivot-or-persevere threshold is pre-committed in writing, before the experiment runs\n- [ ] The MVP is the smallest test of the assumption (time-boxed ≤ 4–6 weeks early-stage)\n- [ ] An *actionable* metric (not vanity) is pre-specified for evaluation\n- [ ] Result is compared to the pre-committed threshold — without moving goalposts\n- [ ] Pivot vs. persevere decision is made explicitly, with type if pivoting\n- [ ] Validated learning is documented in one sentence carry-forward\n---\n\n*Part of **deciqAI Knowledge Skills** — 164 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/lean-startup** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.3:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"lean-startup\",\n \"version\": \"1.0.3\",\n \"publishedAt\": 1783508860103\n}\n\nFile v1.0.3:references/sources.md\n\n# Sources — lean-startup\n\n> *Primary sources for the [lean-startup](../SKILL.md) skill.*\n\n- **Ries, Eric.** *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown, 2011. **Canonical primary source** for Lean Startup and Build-Measure-Learn; verbatim Overview quote is p. 9; Dropbox case discussion pp. 99–101; Votizen pivot sequence opens ch. 8, \"Pivot (or Persevere)\".\n- **Blank, Steve.** *The Four Steps to the Epiphany: Successful Strategies for Products That Win*. K&S Ranch, 2nd ed. 2013 (orig. self-published 2005). **Primary source** for the Customer Development methodology that grounds Lean Startup.\n- **Blank, Steve.** \"Why the Lean Start-Up Changes Everything.\" *Harvard Business Review*, May 2013. The methodology's founder synthesizing the framework for HBR. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything\n- **Houston, Drew.** Original 2007 Dropbox demo video (the MVP) — currently re-hosted at: https://www.youtube.com/watch?v=7QmCUDHpNzE\n- **Sequoia Capital, Dropbox pitch deck, 2007** — primary-source artifact from the early Dropbox story.\n- **OpenAI.** \"Introducing ChatGPT.\" 30 November 2022. https://openai.com/index/chatgpt/ — public marker for the foundation-model API wave that made the *Build* phase nearly free for AI-native startups (2023–2026 example).\n- **Reuters / Associated Press / Financial Times**, late January 2025 coverage of DeepSeek's low-cost open-weight model release and the ~27 January 2025 selloff in Nvidia and AI-linked equities — durable, widely-reported reminder that AI moat/cost assumptions can reset without warning (2023–2026 example). Exact intraday figures varied by source and are cited qualitatively.\n- The popular framing \"fail fast\" is **not** cited here as a source — by this skill's own rule, an aphorism is not evidence. Lean Startup is more precisely \"**test cheaply** the demand-side assumption *before* paying to build the supply-side capability\"; failure speed is incidental.\n\nFile v1.0.3:examples/ai-native-lean-startups-2023-2026.md\n\n# Method in Action: AI-Native Lean Startups (2023–2026)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA 2026 lens on the same loop. Not a prediction of which company wins — a worked example of how Build–Measure–Learn behaves when the *supply-side capability* is a rented foundation model that a competitor's next release can commoditize overnight.\n\nAfter the November 2022 release of ChatGPT and the 2023–2024 arrival of capable foundation-model APIs (OpenAI, Anthropic, Google), a wave of small teams built products as thin layers over these models. The economics inverted the classic build cost: a two-person team could ship a working AI feature in days by calling an API, rather than spending months training a model. This made the *Build* phase almost free — and moved the real risk somewhere the Lean Startup framework anticipates but that demo culture ignores.\n\nThe recurring 2023–2026 failure pattern: a startup demos an impressive AI feature, raises on the demo, and then a subsequent model release from the underlying provider (or an open-weight model) absorbs that feature into the base capability — the \"GPT-wrapper gets wrapped\" problem. The dramatic public reminder came in **January 2025**, when the Chinese lab **DeepSeek** released a strong, low-cost open-weight reasoning model; the reaction rippled through markets and, on **27 January 2025**, Nvidia's share price fell sharply in a single session — a widely reported signal that the cost and moat assumptions underpinning many AI plans could shift without warning.\n\nThe Lean Startup correction: in an AI-native startup, the load-bearing assumption is almost never \"can we build the feature?\" (you can — cheaply). It is **\"does a specific customer keep using and paying for the workflow *after* the underlying model capability becomes a commodity available to everyone?\"** That is a retention-and-willingness-to-pay assumption, and it is exactly what a demo does not test.\n\nWalk the Experiment Card on a representative AI-native workflow product (a small team building an AI tool for a specific professional segment):\n\n- **Load-bearing assumption (Step 1):** *A defined professional segment (say, mid-market legal or support teams) will adopt an AI-drafting workflow, retain it past day-30, and pay a per-seat fee — where the retained value comes from our proprietary data/workflow/integration, not from raw model capability any competitor can also call.* Specific segment, specific value, specific willingness-to-pay, specific timeframe — not \"people want AI.\"\n- **Pre-commit to a threshold (Step 2):** Write the pivot bar before building — e.g. *persevere only if paid day-30 retention clears a stated bar and the value survives a hypothetical \"the base model now does the naive version for free\" test.* Pre-committing matters more here because a slick demo tempts you to rationalize any signal into a persevere.\n- **Design the smallest MVP (Step 3):** Because the model is rented, the MVP is not \"train a model.\" It is a landing page, a concierge/\"Wizard of Oz\" run over an existing API, or a single-workflow build for a handful of design-partner accounts — a *learning* instrument, not the product. Purpose is to isolate durable value from model novelty.\n- **Build fast (Step 4):** Time-boxed. The API makes this the cheapest Build phase in startup history — which is precisely why teams over-build polish and skip the demand test. Cut anything past the 4–6 week early-stage box.\n- **Measure real behavior (Step 5):** Paid retention and expansion within design-partner accounts — actionable. Demo applause, waitlist size, and social virality are vanity metrics that move with model hype, not with durable fit.\n- **Compare to threshold (Step 6):** Judge against the pre-committed bar, including the commoditization stress test. If retained usage evaporated the moment the base model improved, the value was model novelty, not your product.\n- **Decide pivot or persevere (Step 7):** *Persevere* only if durable, model-independent value holds. Otherwise **pivot** — and the AI-native pivots mirror the classic types: move up the stack toward proprietary data and integrations; pivot customer segment; or pivot from a commoditized feature to the workflow/system-of-record around it. When the next model release \"eats\" your feature, that is not bad luck — it is an invalidated assumption firing exactly as the loop predicts.\n- **Document and iterate (Step 8):** Carry forward one durable learning per loop: *which* part of the value was model-independent and which was borrowed from the provider. That distinction is the compounding asset across the fast, frequent loops the AI stack enables.\n\nThe key feature of this case for the Lean Startup canon: cheap models make *building* nearly free, so the discipline shifts almost entirely onto **testing the right assumption** — durable, model-independent retention and willingness-to-pay — and **pre-committing a threshold that a demo cannot flatter you past**. The impressive demo is not the product; like Dropbox's video, it is a disposable test instrument. In 2023–2026 the trap is mistaking the demo's applause for validated learning while a competitor's next release quietly resets the moat.\n\n*Sources: OpenAI, \"Introducing ChatGPT,\" 30 November 2022 (openai.com/index/chatgpt/). DeepSeek's late-January 2025 open-weight model release and the ~27 January 2025 selloff in Nvidia and AI-linked equities, as widely reported by Reuters, the Associated Press, and the Financial Times. Ries, Eric, *The Lean Startup* (Crown, 2011) — Build–Measure–Learn, MVP, and pivot-or-persevere framework applied here. Figures on the market reaction are given qualitatively; exact intraday percentages varied by source and session.*\n\nFile v1.0.3:examples/dropboxs-video-mvp-2007.md\n\n# Method in Action: Dropbox's Video MVP (2007)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA worked example. Not founder hagiography — primary-source documented.\n\nIn **2007**, **Drew Houston** had built an early prototype of what would become Dropbox: cloud file synchronization with conflict-free updates across devices. The space was crowded with incumbents (Microsoft Live Mesh, FolderShare, Mozy, Carbonite, Apple's planned iDisk), and the prototype's killer feature — a kernel-level filesystem driver that just-worked on Mac, Windows, and Linux — was hard to demonstrate without a working installer on every OS.\n\nHouston faced the classic Lean Startup question: **before committing months of engineering to a polished cross-platform release, was the load-bearing demand assumption true?** Specifically: would early-adopter tech users, given a frictionless sync experience, be willing to share email addresses and try the product in numbers large enough to validate a freemium-to-paid funnel?\n\nHis MVP was a **3-minute screencast video** posted to Hacker News and Digg in late 2007, demonstrating the working prototype: drag a file into a folder, watch it appear on another machine seconds later, watch conflict resolution work cleanly. The video referenced specific tech-community in-jokes (XKCD references, music chosen for the audience) — Drew explicitly designed it for the *Hacker News* / *Digg* segment most likely to convert.\n\nThe result: **the beta waiting list jumped from roughly 5,000 to 75,000 overnight** — a measurable, actionable spike directly attributable to a single MVP costing only the time to film the video. Eric Ries described this exact case in *The Lean Startup* as a textbook example of a video MVP testing demand before building.\n\nWalk the Experiment Card on Dropbox's 2007 video MVP:\n\n- **Load-bearing assumption (Step 1):** *Early-adopter tech users (HN/Digg-readers) will sign up for a waitlist for frictionless cross-device file sync in numbers large enough to suggest a viable freemium-to-paid funnel.*\n- **Pre-committed threshold (Step 2):** Houston has not published the exact pre-committed number, but the 15× jump in beta waitlist signups would have cleared almost any reasonable pre-committed threshold.\n- **MVP design (Step 3):** A 3-minute screencast video, not a working installer. The minimum thing that could elicit signup behavior. Time-box: days, not months.\n- **Measurement (Step 4):** Waitlist signups in the 72 hours post-publication, segmented by referrer source (HN vs. Digg vs. organic).\n- **Result vs. threshold (Step 5):** Signup spike from ~5K to ~75K. Strongly above any reasonable threshold for \"demand exists.\"\n- **Decision (Step 6):** **Persevere.** Build the cross-platform client; the demand assumption holds. (Houston did exactly this through 2008; Dropbox launched publicly in September 2008.)\n- **Validated learning (Step 7):** *Tech-segment early-adopters will give email addresses for a frictionless-sync promise; the freemium funnel is worth building.*\n\nThe key feature of this case for the Lean Startup canon: **the MVP cost essentially nothing**, **tested a specific assumption** (demand at scale for sync among the target segment), and **produced a clear actionable signal** that justified the much-larger build that followed. The video is not Dropbox's product; it is the disposable test that justified the product.\n\nFile v1.0.3:examples/votizens-pivot-sequence-2010-2011.md\n\n# Method in Action: Votizen's Pivot Sequence (2010–2011)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nThe Dropbox example ends in **persevere**. This case shows the other branch — the one the loop exists for. It is the case Eric Ries himself uses to open his treatment of the pivot in *The Lean Startup* (2011).\n\n**David Binetti** — a Silicon Valley veteran who had helped build USA.gov in the 1990s — founded **Votizen** on a civic-tech thesis: citizens wanted a **social network of verified registered voters**, where political identity was authenticated against public voter rolls rather than self-declared. The load-bearing assumption was not \"people care about politics.\" It was specific and testable: *citizens will sign up, verify their voter registration, invite friends, and keep coming back.*\n\n**The first experiment.** Instead of building the full vision, Binetti shipped a minimum viable product in about **three months for roughly $1,200** — just enough to test the four behaviors the model depended on. Ries breaks the assumption into four actionable metrics: **registration** (do they sign up?), **activation** (do they verify voter status?), **referral** (do they invite others?), **retention** (do they come back?). Vanity metrics — press coverage, raw traffic — were deliberately not the scoreboard.\n\n**The measurement.** Baseline funnel numbers came back far below what a viable consumer product needs (Ries reports the exact percentages in the book). Binetti did not pivot on the first bad reading: he spent the following months running disciplined split-tests on onboarding and messaging. Activation improved substantially under optimization — but **referral and retention barely moved**. A funnel that optimization cannot fix is not a tuning problem; it is an invalidated assumption.\n\n**Pivot one.** Binetti compared the result to what any honest persevere bar would require and pivoted — while **preserving the validated learning**: voter-roll identity verification worked and was valued; the social network around it was not. The new product, **@2gov**, dropped the network entirely. It let citizens contact their Congressional representatives through Twitter, with Votizen verifying the sender as a real registered voter and delivering the message through official channels.\n\n**The second loop.** Engagement metrics on @2gov came back dramatically stronger — the civic-contact behavior was real. But the loop now exposed the next load-bearing assumption: *consumers will pay for this.* They would not. High activity, negligible willingness-to-pay. Stated enthusiasm failed the behavioral test that matters — the payment.\n\n**Pivot two.** A customer-segment pivot: keep the verified voter-contact capability, change who pays. Votizen turned to **organizations** — advocacy groups and political campaigns — as paying customers for authenticated voter-to-voter contact. Willingness-to-pay validated where the consumer model had failed, and Binetti went on to raise funding from prominent Silicon Valley investors on the back of the validated model.\n\nEach cycle ran the same discipline: name the assumption, ship the smallest test, measure behavior against the assumption, decide explicitly. Nothing was rationalized into a persevere; nothing was pivoted on noise or boredom.\n\nThe mapped steps:\n\n1. Load-bearing assumption stated specifically: citizens will register, verify, refer, and retain on a verified-voter social network — not \"people want civic tools\"\n2. Smallest MVP: ~3 months, ~$1,200 — a test instrument for four behaviors, not v1 of the vision\n3. Actionable metrics pre-specified: registration, activation, referral, retention; press and traffic ignored as vanity\n4. Result vs. threshold, honestly: split-tests lifted activation, but referral and retention stayed flat — the assumption failed in a specific way\n5. Pivot, preserving validated learning: verified-voter identity carried forward into @2gov; the social network dropped\n6. Loop re-run on the new assumption: engagement validated, consumer willingness-to-pay invalidated by behavior, not surveys\n7. Second pivot (customer segment): from consumers to paying organizations — the revenue assumption finally holds\n8. Documented learning compounds across loops, ending in a fundable, revenue-bearing model\n\nPrimary source: Ries, Eric (2011). *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown. Votizen pivot sequence documented in Chapter 8, \"Pivot (or Persevere).\"\n\nFile v1.0.3:skill-card.md\n\n## Description:
\nGuides agents through Lean Startup coaching by identifying the riskiest business-model assumption, designing a small MVP, measuring real behavior, and deciding whether to pivot or persevere.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal founders, product teams, and business-building agents use this skill to test demand under high uncertainty before committing to a larger build. It helps turn a vague startup idea into an experiment card with an assumption, MVP, metric, threshold, result, and pivot-or-persevere decision.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Business experimentation guidance may be misapplied to known business models, unethical customer tests, or low-quality shipping under a lean label.
\nMitigation: Use the skill only for high-uncertainty business-model search, review customer-facing tests for ethics and quality, and require pre-committed actionable metrics before acting.
\nRisk: The skill references external business examples and promotional publisher links.
\nMitigation: Treat external links as reference material, review them before relying on them, and note that security evidence found no indication that the skill executes code, collects secrets, changes files automatically, or contacts services on its own.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/deciqai/skills/lean-startup)
\n- [Sources - lean-startup](references/sources.md)
\n- [Why the Lean Start-Up Changes Everything](https://hbr.org/2013/05/why-the-lean-start-up-changes-everything)
\n- [Dropbox 2007 Demo Video](https://www.youtube.com/watch?v=7QmCUDHpNzE)
\n- [Introducing ChatGPT](https://openai.com/index/chatgpt/)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, Markdown, Text]
\n**Output Format:** [Markdown experiment cards and step-by-step coaching prompts]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Non-executable coaching output; may include experiment thresholds, metrics, red flags, and pivot-or-persevere recommendations.]
\n\n## Skill Version(s):
\n1.0.3 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.2: 6 files, 11205 bytes\n\nFiles: examples/dropboxs-video-mvp-2007.md (3413b), examples/votizens-pivot-sequence-2010-2011.md (4571b), references/sources.md (1435b), skill-card.md (2739b), SKILL.md (9474b), _meta.json (131b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: lean-startup\ndescription: \"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to test this idea before building', or 'how do we know if anyone wants this?'; team is about to build something significant before testing demand; a pivot decision is on the table after early data.\n Do NOT activate when: operating a known business model in known conditions (use execution frameworks instead); decision is below business-model level (button color, which CRM).\"\n---\n\n# Lean Startup\n\n## Overview\n\nA startup is a **temporary organization searching for a repeatable, scalable business model under extreme uncertainty** (Steve Blank). Most early-stage failures are from building something no one wanted because the demand assumption was never tested.\n\n**Eric Ries** (2011): name the riskiest assumption, build the smallest test (MVP), measure real behavior, decide to **pivot or persevere** — the **Build–Measure–Learn loop**, run as fast as possible.\n\n**Compose:** first-principles to find what the model truly depends on; probabilistic-thinking to calibrate experiments; inversion before each Build phase; business-model-canvas to surface the riskiest assumption blocks.\n\n## When to Use\n\nApply when: high uncertainty + limited capital; a team is about to build before testing demand; a pivot-or-persevere decision is on the table; no clear answer to \"what is the load-bearing assumption and how would we know if it's wrong?\"\n\n**When NOT to use:** known business model in known conditions (execution, not search); decision is not business-model-level; cannot ethically run a test with real customers; using \"lean\" as a schedule excuse to ship buggy software.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete hypothesis → run The Process directly.\n- **Coach mode:** no concrete hypothesis or signals unfamiliarity → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. **One-line what-it-is.** Most startups fail by building before knowing if anyone wants it; lean startup names the riskiest assumption, tests it with the smallest MVP, measures real behavior, and decides pivot or persevere — fast.\n2. **Check fit.** Match against When to Use / When NOT to use; if low uncertainty + known model, redirect.\n3. **Elicit their real hypothesis.** Force them to name one load-bearing assumption — specific segment, specific value, specific willingness-to-pay.\n> **[WAIT — do not advance until user responds]**\n4. **Walk the loop step by step.** Name assumption → design MVP → define metric → set threshold. Pause at each.\n> **[WAIT — do not advance until user responds]**\n5. **Close by naming the next-week experiment.** One assumption, one MVP, one threshold, one date — not a strategy doc.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Build–Measure–Learn cycle**. Identify, test, decide.\n\n1. **State the load-bearing assumption.** Specific segment, specific value, specific willingness-to-pay, specific timeframe. Not \"users want X.\"\n2. **Pre-commit to a pivot-or-persevere threshold.** Write the metric value *before* running the experiment. You will rationalize if you have not pre-committed.\n3. **Design the smallest MVP that tests the assumption.** Often not a product — a landing page, concierge/\"Wizard of Oz\" version, or 3-minute video. Purpose is *learning*, not selling.\n4. **Build the MVP fast.** Time-box. If an early-stage test takes more than 4–6 weeks, cut.\n5. **Measure real customer behavior, not stated intent.** Actionable metrics (conversion, retention, willingness-to-pay) test the assumption. Vanity metrics (signups, likes) do not.\n6. **Compare result to the pre-committed threshold.** Don't move the goalposts.\n7. **Decide pivot or persevere — explicitly.** Persevere = assumption held; pivot = assumption failed in a specific way, change the load-bearing block and re-test.\n8. **Document and iterate.** Write: assumption, MVP, threshold, result, decision, rationale. Each loop must produce a durable carry-forward learning.\n\n### Output: Experiment Card\n\n```\nAssumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: \n```\n\n*→ Method in Action: [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md) · [Votizen's Pivot Sequence (2010–2011)](examples/votizens-pivot-sequence-2010-2011.md)*\n## Experiment Packs\n\n| Domain | Load-bearing assumption | MVP type | Common failure |\n|---|---|---|---|\n| Consumer apps | install + day-7 retention | concierge, video, single-feature build | testing acquisition, ignoring retention |\n| B2B SaaS | willingness-to-pay vs. specific budget owner | pre-order page or 3–5 paid pilots | talking to users (love it), not buyers (hold budget) |\n| Two-sided marketplaces | liquidity on the harder side (usually supply) | manually-matched concierge, single ZIP | launching both sides at once |\n| Hardware | people willing to pay (not just click) | video demo + Kickstarter or pre-order | conflating click-throughs with payment intent |\n\n## Applying It Well\n\n- MVPs are for learning, not revenue — the deliverable is evidence, not a launch.\n- Pre-commit to the threshold or you will rationalize whatever you get.\n- In B2B, talk to buyers (hold budget), not just users (love the product).\n- Vanity metrics (signups, likes) ≠ actionable metrics (conversion, retention, willingness-to-pay).\n- The MVP is disposable — a test instrument, not v0 of your product.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **\"We're lean\" while shipping a six-month build with no validated demand** | Lean Startup is a loop, not a label. If you haven't tested the load-bearing demand assumption before building, you are doing waterfall. |\n| [D] **MVP confused with v1 of the product** | The MVP is a test instrument, designed to be disposable. Polishing it as v1 inflates scope and breaks the loop. |\n| [D] **No pre-committed pivot/persevere threshold** | Without it, you will explain any result. The pre-commitment IS the discipline. |\n| [D] **Counting vanity metrics** (signups, traffic, likes) | These move with marketing spend, not product-market fit. Actionable metrics test the assumption. |\n| [D] **Talking only to users, not buyers** (especially in B2B) | User love is necessary but not sufficient. The buyer's willingness-to-pay is the load-bearing test. |\n| [D] **\"The customer said they'd buy\"** | Stated intent is famously unreliable. Measure behavior (a credit card swipe, retention to day 7), not intent. |\n| [D] **Pivoting on noise** | A single bad week is not a signal to pivot. Pre-commit the threshold and time-window; pivot only when both fire. |\n| [D] **Pivoting \"because we got bored\"** | A pivot is a response to invalidated assumptions, not to founder restlessness. |\n| [D] **Using \"lean\" as schedule cover** | Lean is not \"ship buggy fast.\" It is \"test the demand-side assumption before building the supply-side capability.\" |\n| [D] **No documented validated learning** | If each loop doesn't produce a written carry-forward insight, you are running random experiments. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n## Red Flags\n\n- The team is building for months with no MVP yet shipped\n- \"MVP\" is a six-month build with full polish\n- Vanity metrics dominate the dashboard; conversion/retention/willingness-to-pay are absent or untracked\n- Customer interviews reported as \"they love it\" with no behavioral data\n- Pivot decisions made on a single week's noise, or after founders simply got bored\n- No pre-committed pivot/persevere threshold exists for any experiment\n- \"Lean\" is being used to justify low-quality shipping rather than test-before-build\n## Verification\n\n- [ ] The load-bearing assumption is named in specific segment/value/willingness-to-pay/timeframe form\n- [ ] The pivot-or-persevere threshold is pre-committed in writing, before the experiment runs\n- [ ] The MVP is the smallest test of the assumption (time-boxed ≤ 4–6 weeks early-stage)\n- [ ] An *actionable* metric (not vanity) is pre-specified for evaluation\n- [ ] Result is compared to the pre-committed threshold — without moving goalposts\n- [ ] Pivot vs. persevere decision is made explicitly, with type if pivoting\n- [ ] Validated learning is documented in one sentence carry-forward\n---\n\n*Part of **deciqAI Knowledge Skills** — 163 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/skills/lean-startup?utm_source=clawhub&utm_medium=marketplace&utm_campaign=knowledge-skills&utm_content=lean-startup** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.2:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"lean-startup\",\n \"version\": \"1.0.2\",\n \"publishedAt\": 1783471946756\n}\n\nFile v1.0.2:references/sources.md\n\n# Sources — lean-startup\n\n> *Primary sources for the [lean-startup](../SKILL.md) skill.*\n\n- **Ries, Eric.** *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown, 2011. **Canonical primary source** for Lean Startup and Build-Measure-Learn; verbatim Overview quote is p. 9; Dropbox case discussion pp. 99–101; Votizen pivot sequence opens ch. 8, \"Pivot (or Persevere)\".\n- **Blank, Steve.** *The Four Steps to the Epiphany: Successful Strategies for Products That Win*. K&S Ranch, 2nd ed. 2013 (orig. self-published 2005). **Primary source** for the Customer Development methodology that grounds Lean Startup.\n- **Blank, Steve.** \"Why the Lean Start-Up Changes Everything.\" *Harvard Business Review*, May 2013. The methodology's founder synthesizing the framework for HBR. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything\n- **Houston, Drew.** Original 2007 Dropbox demo video (the MVP) — currently re-hosted at: https://www.youtube.com/watch?v=7QmCUDHpNzE\n- **Sequoia Capital, Dropbox pitch deck, 2007** — primary-source artifact from the early Dropbox story.\n- The popular framing \"fail fast\" is **not** cited here as a source — by this skill's own rule, an aphorism is not evidence. Lean Startup is more precisely \"**test cheaply** the demand-side assumption *before* paying to build the supply-side capability\"; failure speed is incidental.\n\nFile v1.0.2:examples/dropboxs-video-mvp-2007.md\n\n# Method in Action: Dropbox's Video MVP (2007)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA worked example. Not founder hagiography — primary-source documented.\n\nIn **2007**, **Drew Houston** had built an early prototype of what would become Dropbox: cloud file synchronization with conflict-free updates across devices. The space was crowded with incumbents (Microsoft Live Mesh, FolderShare, Mozy, Carbonite, Apple's planned iDisk), and the prototype's killer feature — a kernel-level filesystem driver that just-worked on Mac, Windows, and Linux — was hard to demonstrate without a working installer on every OS.\n\nHouston faced the classic Lean Startup question: **before committing months of engineering to a polished cross-platform release, was the load-bearing demand assumption true?** Specifically: would early-adopter tech users, given a frictionless sync experience, be willing to share email addresses and try the product in numbers large enough to validate a freemium-to-paid funnel?\n\nHis MVP was a **3-minute screencast video** posted to Hacker News and Digg in late 2007, demonstrating the working prototype: drag a file into a folder, watch it appear on another machine seconds later, watch conflict resolution work cleanly. The video referenced specific tech-community in-jokes (XKCD references, music chosen for the audience) — Drew explicitly designed it for the *Hacker News* / *Digg* segment most likely to convert.\n\nThe result: **the beta waiting list jumped from roughly 5,000 to 75,000 overnight** — a measurable, actionable spike directly attributable to a single MVP costing only the time to film the video. Eric Ries described this exact case in *The Lean Startup* as a textbook example of a video MVP testing demand before building.\n\nWalk the Experiment Card on Dropbox's 2007 video MVP:\n\n- **Load-bearing assumption (Step 1):** *Early-adopter tech users (HN/Digg-readers) will sign up for a waitlist for frictionless cross-device file sync in numbers large enough to suggest a viable freemium-to-paid funnel.*\n- **Pre-committed threshold (Step 2):** Houston has not published the exact pre-committed number, but the 15× jump in beta waitlist signups would have cleared almost any reasonable pre-committed threshold.\n- **MVP design (Step 3):** A 3-minute screencast video, not a working installer. The minimum thing that could elicit signup behavior. Time-box: days, not months.\n- **Measurement (Step 4):** Waitlist signups in the 72 hours post-publication, segmented by referrer source (HN vs. Digg vs. organic).\n- **Result vs. threshold (Step 5):** Signup spike from ~5K to ~75K. Strongly above any reasonable threshold for \"demand exists.\"\n- **Decision (Step 6):** **Persevere.** Build the cross-platform client; the demand assumption holds. (Houston did exactly this through 2008; Dropbox launched publicly in September 2008.)\n- **Validated learning (Step 7):** *Tech-segment early-adopters will give email addresses for a frictionless-sync promise; the freemium funnel is worth building.*\n\nThe key feature of this case for the Lean Startup canon: **the MVP cost essentially nothing**, **tested a specific assumption** (demand at scale for sync among the target segment), and **produced a clear actionable signal** that justified the much-larger build that followed. The video is not Dropbox's product; it is the disposable test that justified the product.\n\nFile v1.0.2:examples/votizens-pivot-sequence-2010-2011.md\n\n# Method in Action: Votizen's Pivot Sequence (2010–2011)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nThe Dropbox example ends in **persevere**. This case shows the other branch — the one the loop exists for. It is the case Eric Ries himself uses to open his treatment of the pivot in *The Lean Startup* (2011).\n\n**David Binetti** — a Silicon Valley veteran who had helped build USA.gov in the 1990s — founded **Votizen** on a civic-tech thesis: citizens wanted a **social network of verified registered voters**, where political identity was authenticated against public voter rolls rather than self-declared. The load-bearing assumption was not \"people care about politics.\" It was specific and testable: *citizens will sign up, verify their voter registration, invite friends, and keep coming back.*\n\n**The first experiment.** Instead of building the full vision, Binetti shipped a minimum viable product in about **three months for roughly $1,200** — just enough to test the four behaviors the model depended on. Ries breaks the assumption into four actionable metrics: **registration** (do they sign up?), **activation** (do they verify voter status?), **referral** (do they invite others?), **retention** (do they come back?). Vanity metrics — press coverage, raw traffic — were deliberately not the scoreboard.\n\n**The measurement.** Baseline funnel numbers came back far below what a viable consumer product needs (Ries reports the exact percentages in the book). Binetti did not pivot on the first bad reading: he spent the following months running disciplined split-tests on onboarding and messaging. Activation improved substantially under optimization — but **referral and retention barely moved**. A funnel that optimization cannot fix is not a tuning problem; it is an invalidated assumption.\n\n**Pivot one.** Binetti compared the result to what any honest persevere bar would require and pivoted — while **preserving the validated learning**: voter-roll identity verification worked and was valued; the social network around it was not. The new product, **@2gov**, dropped the network entirely. It let citizens contact their Congressional representatives through Twitter, with Votizen verifying the sender as a real registered voter and delivering the message through official channels.\n\n**The second loop.** Engagement metrics on @2gov came back dramatically stronger — the civic-contact behavior was real. But the loop now exposed the next load-bearing assumption: *consumers will pay for this.* They would not. High activity, negligible willingness-to-pay. Stated enthusiasm failed the behavioral test that matters — the payment.\n\n**Pivot two.** A customer-segment pivot: keep the verified voter-contact capability, change who pays. Votizen turned to **organizations** — advocacy groups and political campaigns — as paying customers for authenticated voter-to-voter contact. Willingness-to-pay validated where the consumer model had failed, and Binetti went on to raise funding from prominent Silicon Valley investors on the back of the validated model.\n\nEach cycle ran the same discipline: name the assumption, ship the smallest test, measure behavior against the assumption, decide explicitly. Nothing was rationalized into a persevere; nothing was pivoted on noise or boredom.\n\nThe mapped steps:\n\n1. Load-bearing assumption stated specifically: citizens will register, verify, refer, and retain on a verified-voter social network — not \"people want civic tools\"\n2. Smallest MVP: ~3 months, ~$1,200 — a test instrument for four behaviors, not v1 of the vision\n3. Actionable metrics pre-specified: registration, activation, referral, retention; press and traffic ignored as vanity\n4. Result vs. threshold, honestly: split-tests lifted activation, but referral and retention stayed flat — the assumption failed in a specific way\n5. Pivot, preserving validated learning: verified-voter identity carried forward into @2gov; the social network dropped\n6. Loop re-run on the new assumption: engagement validated, consumer willingness-to-pay invalidated by behavior, not surveys\n7. Second pivot (customer segment): from consumers to paying organizations — the revenue assumption finally holds\n8. Documented learning compounds across loops, ending in a fundable, revenue-bearing model\n\nPrimary source: Ries, Eric (2011). *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown. Votizen pivot sequence documented in Chapter 8, \"Pivot (or Persevere).\"\n\nFile v1.0.2:skill-card.md\n\n## Description:
\nGuides agents through Lean Startup coaching by identifying load-bearing assumptions, designing MVP experiments, measuring actionable behavior, and supporting pivot-or-persevere decisions.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nFounders, product teams, operators, and agents use this skill to test uncertain business-model assumptions before committing to larger builds. It produces structured experiment guidance for MVP design, actionable metrics, thresholds, validated learning, and pivot-or-persevere decisions.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Real customer experiments can create ethical, privacy, legal, or compliance issues.
\nMitigation: Review planned MVPs with appropriate business, legal, privacy, or compliance stakeholders before involving customers or collecting data.
\nRisk: Business decisions can be distorted if users rely on vanity metrics, skip pre-committed thresholds, or rationalize weak experiment results.
\nMitigation: Require an explicit assumption, actionable metric, pivot-or-persevere threshold, result, decision, and validated learning before acting on the guidance.
\nRisk: The skill includes external reference links that may send users outside the platform.
\nMitigation: Review external links before visiting and prefer organization-approved copies of reference materials when required.
\n\n\n## Reference(s):
\n- [Lean Startup primary sources](references/sources.md)
\n- [Dropbox's Video MVP example](examples/dropboxs-video-mvp-2007.md)
\n- [Votizen pivot sequence example](examples/votizens-pivot-sequence-2010-2011.md)
\n- [Why the Lean Start-Up Changes Everything](https://hbr.org/2013/05/why-the-lean-start-up-changes-everything)
\n- [Original Dropbox demo video](https://www.youtube.com/watch?v=7QmCUDHpNzE)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, Markdown, Text]
\n**Output Format:** [Markdown coaching responses and Experiment Card templates]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May proceed step by step with explicit wait points when coaching users who have not yet stated a concrete hypothesis.]
\n\n## Skill Version(s):
\n1.0.2 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.1: 5 files, 8543 bytes\n\nFiles: examples/dropboxs-video-mvp-2007.md (3413b), references/sources.md (1375b), skill-card.md (2405b), SKILL.md (9263b), _meta.json (131b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: lean-startup\ndescription: \"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to test this idea before building', or 'how do we know if anyone wants this?'; team is about to build something significant before testing demand; a pivot decision is on the table after early data.\n Do NOT activate when: operating a known business model in known conditions (use execution frameworks instead); decision is below business-model level (button color, which CRM).\"\n---\n\n# Lean Startup\n\n## Overview\n\nA startup is a **temporary organization searching for a repeatable, scalable business model under extreme uncertainty** (Steve Blank). Most early-stage failures are from building something no one wanted because the demand assumption was never tested.\n\n**Eric Ries** (2011): name the riskiest assumption, build the smallest test (MVP), measure real behavior, decide to **pivot or persevere** — the **Build–Measure–Learn loop**, run as fast as possible.\n\n**Compose:** [first-principles](../first-principles/SKILL.md) to find what the model truly depends on; [probabilistic-thinking](../probabilistic-thinking/SKILL.md) to calibrate experiments; [inversion](../inversion/SKILL.md) before each Build phase; [business-model-canvas](../business-model-canvas/SKILL.md) to surface the riskiest assumption blocks.\n\n## When to Use\n\nApply when: high uncertainty + limited capital; a team is about to build before testing demand; a pivot-or-persevere decision is on the table; no clear answer to \"what is the load-bearing assumption and how would we know if it's wrong?\"\n\n**When NOT to use:** known business model in known conditions (execution, not search); decision is not business-model-level; cannot ethically run a test with real customers; using \"lean\" as a schedule excuse to ship buggy software.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete hypothesis → run The Process directly.\n- **Coach mode:** no concrete hypothesis or signals unfamiliarity → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. **One-line what-it-is.** Most startups fail by building before knowing if anyone wants it; lean startup names the riskiest assumption, tests it with the smallest MVP, measures real behavior, and decides pivot or persevere — fast.\n2. **Check fit.** Match against When to Use / When NOT to use; if low uncertainty + known model, redirect.\n3. **Elicit their real hypothesis.** Force them to name one load-bearing assumption — specific segment, specific value, specific willingness-to-pay.\n> **[WAIT — do not advance until user responds]**\n4. **Walk the loop step by step.** Name assumption → design MVP → define metric → set threshold. Pause at each.\n> **[WAIT — do not advance until user responds]**\n5. **Close by naming the next-week experiment.** One assumption, one MVP, one threshold, one date — not a strategy doc.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Build–Measure–Learn cycle**. Identify, test, decide.\n\n1. **State the load-bearing assumption.** Specific segment, specific value, specific willingness-to-pay, specific timeframe. Not \"users want X.\"\n2. **Pre-commit to a pivot-or-persevere threshold.** Write the metric value *before* running the experiment. You will rationalize if you have not pre-committed.\n3. **Design the smallest MVP that tests the assumption.** Often not a product — a landing page, concierge/\"Wizard of Oz\" version, or 3-minute video. Purpose is *learning*, not selling.\n4. **Build the MVP fast.** Time-box. If an early-stage test takes more than 4–6 weeks, cut.\n5. **Measure real customer behavior, not stated intent.** Actionable metrics (conversion, retention, willingness-to-pay) test the assumption. Vanity metrics (signups, likes) do not.\n6. **Compare result to the pre-committed threshold.** Don't move the goalposts.\n7. **Decide pivot or persevere — explicitly.** Persevere = assumption held; pivot = assumption failed in a specific way, change the load-bearing block and re-test.\n8. **Document and iterate.** Write: assumption, MVP, threshold, result, decision, rationale. Each loop must produce a durable carry-forward learning.\n\n### Output: Experiment Card\n\n```\nAssumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: \n```\n\n*→ Method in Action: [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md)*\n## Experiment Packs\n\n| Domain | Load-bearing assumption | MVP type | Common failure |\n|---|---|---|---|\n| Consumer apps | install + day-7 retention | concierge, video, single-feature build | testing acquisition, ignoring retention |\n| B2B SaaS | willingness-to-pay vs. specific budget owner | pre-order page or 3–5 paid pilots | talking to users (love it), not buyers (hold budget) |\n| Two-sided marketplaces | liquidity on the harder side (usually supply) | manually-matched concierge, single ZIP | launching both sides at once |\n| Hardware | people willing to pay (not just click) | video demo + Kickstarter or pre-order | conflating click-throughs with payment intent |\n\n## Applying It Well\n\n- MVPs are for learning, not revenue — the deliverable is evidence, not a launch.\n- Pre-commit to the threshold or you will rationalize whatever you get.\n- In B2B, talk to buyers (hold budget), not just users (love the product).\n- Vanity metrics (signups, likes) ≠ actionable metrics (conversion, retention, willingness-to-pay).\n- The MVP is disposable — a test instrument, not v0 of your product.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **\"We're lean\" while shipping a six-month build with no validated demand** | Lean Startup is a loop, not a label. If you haven't tested the load-bearing demand assumption before building, you are doing waterfall. |\n| [D] **MVP confused with v1 of the product** | The MVP is a test instrument, designed to be disposable. Polishing it as v1 inflates scope and breaks the loop. |\n| [D] **No pre-committed pivot/persevere threshold** | Without it, you will explain any result. The pre-commitment IS the discipline. |\n| [D] **Counting vanity metrics** (signups, traffic, likes) | These move with marketing spend, not product-market fit. Actionable metrics test the assumption. |\n| [D] **Talking only to users, not buyers** (especially in B2B) | User love is necessary but not sufficient. The buyer's willingness-to-pay is the load-bearing test. |\n| [D] **\"The customer said they'd buy\"** | Stated intent is famously unreliable. Measure behavior (a credit card swipe, retention to day 7), not intent. |\n| [D] **Pivoting on noise** | A single bad week is not a signal to pivot. Pre-commit the threshold and time-window; pivot only when both fire. |\n| [D] **Pivoting \"because we got bored\"** | A pivot is a response to invalidated assumptions, not to founder restlessness. |\n| [D] **Using \"lean\" as schedule cover** | Lean is not \"ship buggy fast.\" It is \"test the demand-side assumption before building the supply-side capability.\" |\n| [D] **No documented validated learning** | If each loop doesn't produce a written carry-forward insight, you are running random experiments. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n## Red Flags\n\n- The team is building for months with no MVP yet shipped\n- \"MVP\" is a six-month build with full polish\n- Vanity metrics dominate the dashboard; conversion/retention/willingness-to-pay are absent or untracked\n- Customer interviews reported as \"they love it\" with no behavioral data\n- Pivot decisions made on a single week's noise, or after founders simply got bored\n- No pre-committed pivot/persevere threshold exists for any experiment\n- \"Lean\" is being used to justify low-quality shipping rather than test-before-build\n## Verification\n\n- [ ] The load-bearing assumption is named in specific segment/value/willingness-to-pay/timeframe form\n- [ ] The pivot-or-persevere threshold is pre-committed in writing, before the experiment runs\n- [ ] The MVP is the smallest test of the assumption (time-boxed ≤ 4–6 weeks early-stage)\n- [ ] An *actionable* metric (not vanity) is pre-specified for evaluation\n- [ ] Result is compared to the pre-committed threshold — without moving goalposts\n- [ ] Pivot vs. persevere decision is made explicitly, with type if pivoting\n- [ ] Validated learning is documented in one sentence carry-forward\n---\n\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.1:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"lean-startup\",\n \"version\": \"1.0.1\",\n \"publishedAt\": 1783463287768\n}\n\nFile v1.0.1:references/sources.md\n\n# Sources — lean-startup\n\n> *Primary sources for the [lean-startup](../SKILL.md) skill.*\n\n- **Ries, Eric.** *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown, 2011. **Canonical primary source** for Lean Startup and Build-Measure-Learn; verbatim Overview quote is p. 9; Dropbox case discussion pp. 99–101.\n- **Blank, Steve.** *The Four Steps to the Epiphany: Successful Strategies for Products That Win*. K&S Ranch, 2nd ed. 2013 (orig. self-published 2005). **Primary source** for the Customer Development methodology that grounds Lean Startup.\n- **Blank, Steve.** \"Why the Lean Start-Up Changes Everything.\" *Harvard Business Review*, May 2013. The methodology's founder synthesizing the framework for HBR. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything\n- **Houston, Drew.** Original 2007 Dropbox demo video (the MVP) — currently re-hosted at: https://www.youtube.com/watch?v=7QmCUDHpNzE\n- **Sequoia Capital, Dropbox pitch deck, 2007** — primary-source artifact from the early Dropbox story.\n- The popular framing \"fail fast\" is **not** cited here as a source — by this skill's own rule, an aphorism is not evidence. Lean Startup is more precisely \"**test cheaply** the demand-side assumption *before* paying to build the supply-side capability\"; failure speed is incidental.\n\nFile v1.0.1:examples/dropboxs-video-mvp-2007.md\n\n# Method in Action: Dropbox's Video MVP (2007)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA worked example. Not founder hagiography — primary-source documented.\n\nIn **2007**, **Drew Houston** had built an early prototype of what would become Dropbox: cloud file synchronization with conflict-free updates across devices. The space was crowded with incumbents (Microsoft Live Mesh, FolderShare, Mozy, Carbonite, Apple's planned iDisk), and the prototype's killer feature — a kernel-level filesystem driver that just-worked on Mac, Windows, and Linux — was hard to demonstrate without a working installer on every OS.\n\nHouston faced the classic Lean Startup question: **before committing months of engineering to a polished cross-platform release, was the load-bearing demand assumption true?** Specifically: would early-adopter tech users, given a frictionless sync experience, be willing to share email addresses and try the product in numbers large enough to validate a freemium-to-paid funnel?\n\nHis MVP was a **3-minute screencast video** posted to Hacker News and Digg in late 2007, demonstrating the working prototype: drag a file into a folder, watch it appear on another machine seconds later, watch conflict resolution work cleanly. The video referenced specific tech-community in-jokes (XKCD references, music chosen for the audience) — Drew explicitly designed it for the *Hacker News* / *Digg* segment most likely to convert.\n\nThe result: **the beta waiting list jumped from roughly 5,000 to 75,000 overnight** — a measurable, actionable spike directly attributable to a single MVP costing only the time to film the video. Eric Ries described this exact case in *The Lean Startup* as a textbook example of a video MVP testing demand before building.\n\nWalk the Experiment Card on Dropbox's 2007 video MVP:\n\n- **Load-bearing assumption (Step 1):** *Early-adopter tech users (HN/Digg-readers) will sign up for a waitlist for frictionless cross-device file sync in numbers large enough to suggest a viable freemium-to-paid funnel.*\n- **Pre-committed threshold (Step 2):** Houston has not published the exact pre-committed number, but the 15× jump in beta waitlist signups would have cleared almost any reasonable pre-committed threshold.\n- **MVP design (Step 3):** A 3-minute screencast video, not a working installer. The minimum thing that could elicit signup behavior. Time-box: days, not months.\n- **Measurement (Step 4):** Waitlist signups in the 72 hours post-publication, segmented by referrer source (HN vs. Digg vs. organic).\n- **Result vs. threshold (Step 5):** Signup spike from ~5K to ~75K. Strongly above any reasonable threshold for \"demand exists.\"\n- **Decision (Step 6):** **Persevere.** Build the cross-platform client; the demand assumption holds. (Houston did exactly this through 2008; Dropbox launched publicly in September 2008.)\n- **Validated learning (Step 7):** *Tech-segment early-adopters will give email addresses for a frictionless-sync promise; the freemium funnel is worth building.*\n\nThe key feature of this case for the Lean Startup canon: **the MVP cost essentially nothing**, **tested a specific assumption** (demand at scale for sync among the target segment), and **produced a clear actionable signal** that justified the much-larger build that followed. The video is not Dropbox's product; it is the disposable test that justified the product.\n\nFile v1.0.1:skill-card.md\n\n## Description:
\nGuides agents through Lean Startup coaching by identifying demand assumptions, designing MVP experiments, measuring customer behavior, and making pivot-or-persevere decisions.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal users and agents use this skill to test early business-model uncertainty before committing to a build. It helps teams define the load-bearing assumption, choose the smallest ethical MVP, pre-commit metrics, and document validated learning.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Lean Startup recommendations could be mistaken for guaranteed business outcomes.
\nMitigation: Treat the skill's advice as decision support and verify proposed experiments against actual customer behavior and business context.
\nRisk: Real-customer MVP experiments can create ethical, consent, or expectation-management concerns.
\nMitigation: Review each proposed experiment for ethics, consent, and customer impact before running it.
\nRisk: External reference links may change or become unavailable.
\nMitigation: Verify external links before relying on them.
\n\n\n## Reference(s):
\n- [Sources - lean-startup](references/sources.md)
\n- [Method in Action: Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md)
\n- [Why the Lean Start-Up Changes Everything](https://hbr.org/2013/05/why-the-lean-start-up-changes-everything)
\n- [Original 2007 Dropbox demo video](https://www.youtube.com/watch?v=7QmCUDHpNzE)
\n\n\n## Skill Output:
\n**Output Type(s):** [guidance, markdown, text]
\n**Output Format:** [Markdown coaching responses and experiment cards]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May include stepwise coaching questions, pivot-or-persevere thresholds, MVP plans, metrics, and validated-learning summaries.]
\n\n## Skill Version(s):
\n1.0.1 (source: server release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.0: 5 files, 8524 bytes\n\nFiles: examples/dropboxs-video-mvp-2007.md (3413b), references/sources.md (1375b), skill-card.md (2325b), SKILL.md (9263b), _meta.json (131b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: lean-startup\ndescription: \"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to test this idea before building', or 'how do we know if anyone wants this?'; team is about to build something significant before testing demand; a pivot decision is on the table after early data.\n Do NOT activate when: operating a known business model in known conditions (use execution frameworks instead); decision is below business-model level (button color, which CRM).\"\n---\n\n# Lean Startup\n\n## Overview\n\nA startup is a **temporary organization searching for a repeatable, scalable business model under extreme uncertainty** (Steve Blank). Most early-stage failures are from building something no one wanted because the demand assumption was never tested.\n\n**Eric Ries** (2011): name the riskiest assumption, build the smallest test (MVP), measure real behavior, decide to **pivot or persevere** — the **Build–Measure–Learn loop**, run as fast as possible.\n\n**Compose:** [first-principles](../first-principles/SKILL.md) to find what the model truly depends on; [probabilistic-thinking](../probabilistic-thinking/SKILL.md) to calibrate experiments; [inversion](../inversion/SKILL.md) before each Build phase; [business-model-canvas](../business-model-canvas/SKILL.md) to surface the riskiest assumption blocks.\n\n## When to Use\n\nApply when: high uncertainty + limited capital; a team is about to build before testing demand; a pivot-or-persevere decision is on the table; no clear answer to \"what is the load-bearing assumption and how would we know if it's wrong?\"\n\n**When NOT to use:** known business model in known conditions (execution, not search); decision is not business-model-level; cannot ethically run a test with real customers; using \"lean\" as a schedule excuse to ship buggy software.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete hypothesis → run The Process directly.\n- **Coach mode:** no concrete hypothesis or signals unfamiliarity → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. **One-line what-it-is.** Most startups fail by building before knowing if anyone wants it; lean startup names the riskiest assumption, tests it with the smallest MVP, measures real behavior, and decides pivot or persevere — fast.\n2. **Check fit.** Match against When to Use / When NOT to use; if low uncertainty + known model, redirect.\n3. **Elicit their real hypothesis.** Force them to name one load-bearing assumption — specific segment, specific value, specific willingness-to-pay.\n> **[WAIT — do not advance until user responds]**\n4. **Walk the loop step by step.** Name assumption → design MVP → define metric → set threshold. Pause at each.\n> **[WAIT — do not advance until user responds]**\n5. **Close by naming the next-week experiment.** One assumption, one MVP, one threshold, one date — not a strategy doc.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Build–Measure–Learn cycle**. Identify, test, decide.\n\n1. **State the load-bearing assumption.** Specific segment, specific value, specific willingness-to-pay, specific timeframe. Not \"users want X.\"\n2. **Pre-commit to a pivot-or-persevere threshold.** Write the metric value *before* running the experiment. You will rationalize if you have not pre-committed.\n3. **Design the smallest MVP that tests the assumption.** Often not a product — a landing page, concierge/\"Wizard of Oz\" version, or 3-minute video. Purpose is *learning*, not selling.\n4. **Build the MVP fast.** Time-box. If an early-stage test takes more than 4–6 weeks, cut.\n5. **Measure real customer behavior, not stated intent.** Actionable metrics (conversion, retention, willingness-to-pay) test the assumption. Vanity metrics (signups, likes) do not.\n6. **Compare result to the pre-committed threshold.** Don't move the goalposts.\n7. **Decide pivot or persevere — explicitly.** Persevere = assumption held; pivot = assumption failed in a specific way, change the load-bearing block and re-test.\n8. **Document and iterate.** Write: assumption, MVP, threshold, result, decision, rationale. Each loop must produce a durable carry-forward learning.\n\n### Output: Experiment Card\n\n```\nAssumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: \n```\n\n*→ Method in Action: [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md)*\n## Experiment Packs\n\n| Domain | Load-bearing assumption | MVP type | Common failure |\n|---|---|---|---|\n| Consumer apps | install + day-7 retention | concierge, video, single-feature build | testing acquisition, ignoring retention |\n| B2B SaaS | willingness-to-pay vs. specific budget owner | pre-order page or 3–5 paid pilots | talking to users (love it), not buyers (hold budget) |\n| Two-sided marketplaces | liquidity on the harder side (usually supply) | manually-matched concierge, single ZIP | launching both sides at once |\n| Hardware | people willing to pay (not just click) | video demo + Kickstarter or pre-order | conflating click-throughs with payment intent |\n\n## Applying It Well\n\n- MVPs are for learning, not revenue — the deliverable is evidence, not a launch.\n- Pre-commit to the threshold or you will rationalize whatever you get.\n- In B2B, talk to buyers (hold budget), not just users (love the product).\n- Vanity metrics (signups, likes) ≠ actionable metrics (conversion, retention, willingness-to-pay).\n- The MVP is disposable — a test instrument, not v0 of your product.\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] **\"We're lean\" while shipping a six-month build with no validated demand** | Lean Startup is a loop, not a label. If you haven't tested the load-bearing demand assumption before building, you are doing waterfall. |\n| [D] **MVP confused with v1 of the product** | The MVP is a test instrument, designed to be disposable. Polishing it as v1 inflates scope and breaks the loop. |\n| [D] **No pre-committed pivot/persevere threshold** | Without it, you will explain any result. The pre-commitment IS the discipline. |\n| [D] **Counting vanity metrics** (signups, traffic, likes) | These move with marketing spend, not product-market fit. Actionable metrics test the assumption. |\n| [D] **Talking only to users, not buyers** (especially in B2B) | User love is necessary but not sufficient. The buyer's willingness-to-pay is the load-bearing test. |\n| [D] **\"The customer said they'd buy\"** | Stated intent is famously unreliable. Measure behavior (a credit card swipe, retention to day 7), not intent. |\n| [D] **Pivoting on noise** | A single bad week is not a signal to pivot. Pre-commit the threshold and time-window; pivot only when both fire. |\n| [D] **Pivoting \"because we got bored\"** | A pivot is a response to invalidated assumptions, not to founder restlessness. |\n| [D] **Using \"lean\" as schedule cover** | Lean is not \"ship buggy fast.\" It is \"test the demand-side assumption before building the supply-side capability.\" |\n| [D] **No documented validated learning** | If each loop doesn't produce a written carry-forward insight, you are running random experiments. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n## Red Flags\n\n- The team is building for months with no MVP yet shipped\n- \"MVP\" is a six-month build with full polish\n- Vanity metrics dominate the dashboard; conversion/retention/willingness-to-pay are absent or untracked\n- Customer interviews reported as \"they love it\" with no behavioral data\n- Pivot decisions made on a single week's noise, or after founders simply got bored\n- No pre-committed pivot/persevere threshold exists for any experiment\n- \"Lean\" is being used to justify low-quality shipping rather than test-before-build\n## Verification\n\n- [ ] The load-bearing assumption is named in specific segment/value/willingness-to-pay/timeframe form\n- [ ] The pivot-or-persevere threshold is pre-committed in writing, before the experiment runs\n- [ ] The MVP is the smallest test of the assumption (time-boxed ≤ 4–6 weeks early-stage)\n- [ ] An *actionable* metric (not vanity) is pre-specified for evaluation\n- [ ] Result is compared to the pre-committed threshold — without moving goalposts\n- [ ] Pivot vs. persevere decision is made explicitly, with type if pivoting\n- [ ] Validated learning is documented in one sentence carry-forward\n---\n\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.0:_meta.json\n\n{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"lean-startup\",\n \"version\": \"1.0.0\",\n \"publishedAt\": 1782728236748\n}\n\nFile v1.0.0:references/sources.md\n\n# Sources — lean-startup\n\n> *Primary sources for the [lean-startup](../SKILL.md) skill.*\n\n- **Ries, Eric.** *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown, 2011. **Canonical primary source** for Lean Startup and Build-Measure-Learn; verbatim Overview quote is p. 9; Dropbox case discussion pp. 99–101.\n- **Blank, Steve.** *The Four Steps to the Epiphany: Successful Strategies for Products That Win*. K&S Ranch, 2nd ed. 2013 (orig. self-published 2005). **Primary source** for the Customer Development methodology that grounds Lean Startup.\n- **Blank, Steve.** \"Why the Lean Start-Up Changes Everything.\" *Harvard Business Review*, May 2013. The methodology's founder synthesizing the framework for HBR. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything\n- **Houston, Drew.** Original 2007 Dropbox demo video (the MVP) — currently re-hosted at: https://www.youtube.com/watch?v=7QmCUDHpNzE\n- **Sequoia Capital, Dropbox pitch deck, 2007** — primary-source artifact from the early Dropbox story.\n- The popular framing \"fail fast\" is **not** cited here as a source — by this skill's own rule, an aphorism is not evidence. Lean Startup is more precisely \"**test cheaply** the demand-side assumption *before* paying to build the supply-side capability\"; failure speed is incidental.\n\nFile v1.0.0:examples/dropboxs-video-mvp-2007.md\n\n# Method in Action: Dropbox's Video MVP (2007)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA worked example. Not founder hagiography — primary-source documented.\n\nIn **2007**, **Drew Houston** had built an early prototype of what would become Dropbox: cloud file synchronization with conflict-free updates across devices. The space was crowded with incumbents (Microsoft Live Mesh, FolderShare, Mozy, Carbonite, Apple's planned iDisk), and the prototype's killer feature — a kernel-level filesystem driver that just-worked on Mac, Windows, and Linux — was hard to demonstrate without a working installer on every OS.\n\nHouston faced the classic Lean Startup question: **before committing months of engineering to a polished cross-platform release, was the load-bearing demand assumption true?** Specifically: would early-adopter tech users, given a frictionless sync experience, be willing to share email addresses and try the product in numbers large enough to validate a freemium-to-paid funnel?\n\nHis MVP was a **3-minute screencast video** posted to Hacker News and Digg in late 2007, demonstrating the working prototype: drag a file into a folder, watch it appear on another machine seconds later, watch conflict resolution work cleanly. The video referenced specific tech-community in-jokes (XKCD references, music chosen for the audience) — Drew explicitly designed it for the *Hacker News* / *Digg* segment most likely to convert.\n\nThe result: **the beta waiting list jumped from roughly 5,000 to 75,000 overnight** — a measurable, actionable spike directly attributable to a single MVP costing only the time to film the video. Eric Ries described this exact case in *The Lean Startup* as a textbook example of a video MVP testing demand before building.\n\nWalk the Experiment Card on Dropbox's 2007 video MVP:\n\n- **Load-bearing assumption (Step 1):** *Early-adopter tech users (HN/Digg-readers) will sign up for a waitlist for frictionless cross-device file sync in numbers large enough to suggest a viable freemium-to-paid funnel.*\n- **Pre-committed threshold (Step 2):** Houston has not published the exact pre-committed number, but the 15× jump in beta waitlist signups would have cleared almost any reasonable pre-committed threshold.\n- **MVP design (Step 3):** A 3-minute screencast video, not a working installer. The minimum thing that could elicit signup behavior. Time-box: days, not months.\n- **Measurement (Step 4):** Waitlist signups in the 72 hours post-publication, segmented by referrer source (HN vs. Digg vs. organic).\n- **Result vs. threshold (Step 5):** Signup spike from ~5K to ~75K. Strongly above any reasonable threshold for \"demand exists.\"\n- **Decision (Step 6):** **Persevere.** Build the cross-platform client; the demand assumption holds. (Houston did exactly this through 2008; Dropbox launched publicly in September 2008.)\n- **Validated learning (Step 7):** *Tech-segment early-adopters will give email addresses for a frictionless-sync promise; the freemium funnel is worth building.*\n\nThe key feature of this case for the Lean Startup canon: **the MVP cost essentially nothing**, **tested a specific assumption** (demand at scale for sync among the target segment), and **produced a clear actionable signal** that justified the much-larger build that followed. The video is not Dropbox's product; it is the disposable test that justified the product.\n\nFile v1.0.0:skill-card.md\n\n## Description:
\nGuides founders and product teams through Lean Startup experiments that identify a load-bearing assumption, build the smallest MVP, measure actionable behavior, and decide whether to pivot or persevere.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[deciqai](https://clawhub.ai/user/deciqai)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nExternal founders, product teams, and agents supporting them use this skill to test business-model assumptions before building. It helps them name the riskiest assumption, design a small MVP, pre-commit metrics, and decide pivot or persevere from real behavior.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Business-method guidance can be misapplied if cited claims or assumptions are treated as conclusive.
\nMitigation: Verify important business claims and compare recommendations against real customer behavior before making product or funding decisions.
\nRisk: Users may provide sensitive customer, buyer, or company information while framing an experiment.
\nMitigation: Share only information the user intends the agent to reason about, and remove unnecessary confidential details from prompts.
\n\n\n## Reference(s):
\n- [Sources - lean-startup](references/sources.md)
\n- [Dropbox's Video MVP (2007)](examples/dropboxs-video-mvp-2007.md)
\n- [Why the Lean Start-Up Changes Everything](https://hbr.org/2013/05/why-the-lean-start-up-changes-everything)
\n- [Dropbox demo video](https://www.youtube.com/watch?v=7QmCUDHpNzE)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, guidance]
\n**Output Format:** [Markdown coaching response and experiment card]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May pause at explicit wait points in coach mode; produces guidance rather than executable code or shell commands.]
\n\n## Skill Version(s):
\n1.0.0 (source: server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
","readmeExcerpt":"Skill: Lean Startup Owner: deciqai Summary: Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te... Tags: latest:1.0.4 Version history: v1.0.4 | 2026-07-16T18:04:47.149Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/lean-startup.json) v1.0.3 | 2026-07-08T11:07:40.103Z | user F","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Assumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: "},{"language":"text","snippet":"Assumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: "},{"language":"text","snippet":"Assumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: "},{"language":"text","snippet":"Assumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: "},{"language":"text","snippet":"Assumption: \" will at for by \"\nThreshold: Persevere if | Pivot if \nMVP: \nMetric: | Vanity to ignore: \nResult: \nDecision: [ ] Persevere [ ] Pivot (type: ___) [ ] Re-test\nValidated learning: "}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: lean-startup\ndescription: \"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to test this idea before building', or 'how do we know if anyone wants this?'; team is about to build something significant before testing demand; a pivot decision is on the table after early data.\n Do NOT activate when: operating a known business model in known conditions (use execution frameworks instead); decision is below business-model level (button color, which CRM). More: deciqai.com/c/lean-startup\"\n---\n\n# Lean Startup\n\n## Overview\n\nA startup is a **temporary organization searching for a repeatable, scalable business model under extreme uncertainty** (Steve Blank). Most early-stage failures are from building something no one wanted because the demand assumption was never tested.\n\n**Eric Ries** (2011): name the riskiest assumption, build the smallest test (MVP), measure real behavior, decide to **pivot or persevere** — the **Build–Measure–Learn loop**, run as fast as possible.\n\n**Compose:** first-principles to find what the model truly depends on; probabilistic-thinking to calibrate experiments; inversion before each Build phase; business-model-canvas to surface the riskiest assumption blocks.\n\n## When to Use\n\nApply when: high uncertainty + limited capital; a team is about to build before testing demand; a pivot-or-persevere decision is on the table; you're building an AI feature on a foundation-model API and worried \"the next model release will commoditize us\" / \"are we just a GPT wrapper?\"; no clear answer to \"what is the load-bearing assumption and how would we know if it's wrong?\"\n\n**When NOT to use:** known business model in known conditions (execution, not search); decision is not business-model-level; cannot ethically run a test with real customers; using \"lean\" as a schedule excuse to ship buggy software.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** user has a concrete hypothesis → run The Process directly.\n- **Coach mode:** no concrete hypothesis or signals unfamiliarity → guide step by step.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. **One-line what-it-is.** Most startups fail by building before knowing if anyone wants it; lean startup names the riskiest assumption, tests it with the smallest MVP, measures real behavior, and decides pivot or persevere — fast.\n2. **Check fit.** Match against When to Use / When NOT to use; if low uncertainty + known model, redirect.\n3. **Elicit their real hypothesis.** Force them to name one load-bearing assumption — specific segment, specific value, specific willingness-to-pay.\n> **[WAIT — do not advance until user responds]**\n4. **Walk the loop step by step.** Name assumption → design MVP → define metric → set threshold. Pause at each.\n> **[WAIT — do not advance until user responds]**\n5. **Close by naming the next-w"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n \"slug\": \"lean-startup\",\n \"version\": \"1.0.4\",\n \"publishedAt\": 1784225087149\n}"},{"path":"references/sources.md","content":"# Sources — lean-startup\n\n> *Primary sources for the [lean-startup](../SKILL.md) skill.*\n\n- **Ries, Eric.** *The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*. Crown, 2011. **Canonical primary source** for Lean Startup and Build-Measure-Learn; verbatim Overview quote is p. 9; Dropbox case discussion pp. 99–101; Votizen pivot sequence opens ch. 8, \"Pivot (or Persevere)\".\n- **Blank, Steve.** *The Four Steps to the Epiphany: Successful Strategies for Products That Win*. K&S Ranch, 2nd ed. 2013 (orig. self-published 2005). **Primary source** for the Customer Development methodology that grounds Lean Startup.\n- **Blank, Steve.** \"Why the Lean Start-Up Changes Everything.\" *Harvard Business Review*, May 2013. The methodology's founder synthesizing the framework for HBR. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything\n- **Houston, Drew.** Original 2007 Dropbox demo video (the MVP) — currently re-hosted at: https://www.youtube.com/watch?v=7QmCUDHpNzE\n- **Sequoia Capital, Dropbox pitch deck, 2007** — primary-source artifact from the early Dropbox story.\n- **OpenAI.** \"Introducing ChatGPT.\" 30 November 2022. https://openai.com/index/chatgpt/ — public marker for the foundation-model API wave that made the *Build* phase nearly free for AI-native startups (2023–2026 example).\n- **Reuters / Associated Press / Financial Times**, late January 2025 coverage of DeepSeek's low-cost open-weight model release and the ~27 January 2025 selloff in Nvidia and AI-linked equities — durable, widely-reported reminder that AI moat/cost assumptions can reset without warning (2023–2026 example). Exact intraday figures varied by source and are cited qualitatively.\n- The popular framing \"fail fast\" is **not** cited here as a source — by this skill's own rule, an aphorism is not evidence. Lean Startup is more precisely \"**test cheaply** the demand-side assumption *before* paying to build the supply-side capability\"; failure speed is incidental."},{"path":"examples/ai-native-lean-startups-2023-2026.md","content":"# Method in Action: AI-Native Lean Startups (2023–2026)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA 2026 lens on the same loop. Not a prediction of which company wins — a worked example of how Build–Measure–Learn behaves when the *supply-side capability* is a rented foundation model that a competitor's next release can commoditize overnight.\n\nAfter the November 2022 release of ChatGPT and the 2023–2024 arrival of capable foundation-model APIs (OpenAI, Anthropic, Google), a wave of small teams built products as thin layers over these models. The economics inverted the classic build cost: a two-person team could ship a working AI feature in days by calling an API, rather than spending months training a model. This made the *Build* phase almost free — and moved the real risk somewhere the Lean Startup framework anticipates but that demo culture ignores.\n\nThe recurring 2023–2026 failure pattern: a startup demos an impressive AI feature, raises on the demo, and then a subsequent model release from the underlying provider (or an open-weight model) absorbs that feature into the base capability — the \"GPT-wrapper gets wrapped\" problem. The dramatic public reminder came in **January 2025**, when the Chinese lab **DeepSeek** released a strong, low-cost open-weight reasoning model; the reaction rippled through markets and, on **27 January 2025**, Nvidia's share price fell sharply in a single session — a widely reported signal that the cost and moat assumptions underpinning many AI plans could shift without warning.\n\nThe Lean Startup correction: in an AI-native startup, the load-bearing assumption is almost never \"can we build the feature?\" (you can — cheaply). It is **\"does a specific customer keep using and paying for the workflow *after* the underlying model capability becomes a commodity available to everyone?\"** That is a retention-and-willingness-to-pay assumption, and it is exactly what a demo does not test.\n\nWalk the Experiment Card on a representative AI-native workflow product (a small team building an AI tool for a specific professional segment):\n\n- **Load-bearing assumption (Step 1):** *A defined professional segment (say, mid-market legal or support teams) will adopt an AI-drafting workflow, retain it past day-30, and pay a per-seat fee — where the retained value comes from our proprietary data/workflow/integration, not from raw model capability any competitor can also call.* Specific segment, specific value, specific willingness-to-pay, specific timeframe — not \"people want AI.\"\n- **Pre-commit to a threshold (Step 2):** Write the pivot bar before building — e.g. *persevere only if paid day-30 retention clears a stated bar and the value survives a hypothetical \"the base model now does the naive version for free\" test.* Pre-committing matters more here because a slick demo tempts you to rationalize any signal into a persevere.\n- **Design the smallest MVP (Step 3):** Because the model is rented, the MVP is not \"train a model.\" It is"},{"path":"examples/dropboxs-video-mvp-2007.md","content":"# Method in Action: Dropbox's Video MVP (2007)\n\n> *Example for the [lean-startup](../SKILL.md) skill.*\n\nA worked example. Not founder hagiography — primary-source documented.\n\nIn **2007**, **Drew Houston** had built an early prototype of what would become Dropbox: cloud file synchronization with conflict-free updates across devices. The space was crowded with incumbents (Microsoft Live Mesh, FolderShare, Mozy, Carbonite, Apple's planned iDisk), and the prototype's killer feature — a kernel-level filesystem driver that just-worked on Mac, Windows, and Linux — was hard to demonstrate without a working installer on every OS.\n\nHouston faced the classic Lean Startup question: **before committing months of engineering to a polished cross-platform release, was the load-bearing demand assumption true?** Specifically: would early-adopter tech users, given a frictionless sync experience, be willing to share email addresses and try the product in numbers large enough to validate a freemium-to-paid funnel?\n\nHis MVP was a **3-minute screencast video** posted to Hacker News and Digg in late 2007, demonstrating the working prototype: drag a file into a folder, watch it appear on another machine seconds later, watch conflict resolution work cleanly. The video referenced specific tech-community in-jokes (XKCD references, music chosen for the audience) — Drew explicitly designed it for the *Hacker News* / *Digg* segment most likely to convert.\n\nThe result: **the beta waiting list jumped from roughly 5,000 to 75,000 overnight** — a measurable, actionable spike directly attributable to a single MVP costing only the time to film the video. Eric Ries described this exact case in *The Lean Startup* as a textbook example of a video MVP testing demand before building.\n\nWalk the Experiment Card on Dropbox's 2007 video MVP:\n\n- **Load-bearing assumption (Step 1):** *Early-adopter tech users (HN/Digg-readers) will sign up for a waitlist for frictionless cross-device file sync in numbers large enough to suggest a viable freemium-to-paid funnel.*\n- **Pre-committed threshold (Step 2):** Houston has not published the exact pre-committed number, but the 15× jump in beta waitlist signups would have cleared almost any reasonable pre-committed threshold.\n- **MVP design (Step 3):** A 3-minute screencast video, not a working installer. The minimum thing that could elicit signup behavior. Time-box: days, not months.\n- **Measurement (Step 4):** Waitlist signups in the 72 hours post-publication, segmented by referrer source (HN vs. Digg vs. organic).\n- **Result vs. threshold (Step 5):** Signup spike from ~5K to ~75K. Strongly above any reasonable threshold for \"demand exists.\"\n- **Decision (Step 6):** **Persevere.** Build the cross-platform client; the demand assumption holds. (Houston did exactly this through 2008; Dropbox launched publicly in September 2008.)\n- **Validated learning (Step 7):** *Tech-segment early-adopters will give email addresses for a frictionless-sync promise; the f"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te... Skill: Lean Startup Owner: deciqai Summary: Activate when: user says 'lean startup', 'build-measure-learn', 'MVP', 'validated learning', 'pivot or persevere', 'should we just build it?', 'we need to te... Tags: latest:1.0.4 Version history: v1.0.4 | 2026-07-16T18:04:47.149Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/lean-startup.json) v1.0.3 | 2026-07-08T11:07:40.103Z | user F","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":2052,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T15:57:55.272Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T15:57:55.272Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:56:27.115Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}