Skills / Entrepreneurship

Lean Startup

The only way to win is to learn faster than anyone else.

The Lean Startup is Eric Ries's science-driven framework for building companies and products under conditions of extreme uncertainty. It replaces guesswork with structured experimentation: identify your leap-of-faith hypothesis, design the smallest possible experiment (your MVP) to test it, measure outcomes against pre-defined metrics, and decide to pivot or persevere. Designed for startup founders, product managers, and corporate innovators who need to validate ideas before spending months building the wrong thing.

By Eric Ries  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisLean Startup

Input

“I'm building a B2B SaaS tool that helps operations managers track contractor compliance documents — licenses, insurance certs, that kind of thing. My…”

Diagnosis

Let's run a Build-Measure-Learn cycle together.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Stop building what nobody wants — test your riskiest assumption first

The Lean Startup is built on a single engine: the Build-Measure-Learn feedback loop. Every cycle begins with a leap-of-faith hypothesis — the riskiest assumption your business depends on — and ends with validated learning: a confirmed or falsified belief about customer behavior. The Minimum Viable Product (MVP) is not a minimal product; it is the smallest experiment that generates maximum validated learning, and Ries names specific MVP types (Concierge, Wizard of Oz, landing page, video) for different contexts. Progress is measured not by features shipped but by innovation accounting: establish baseline metrics, tune the engine toward the ideal, then make a data-grounded pivot-or-persevere decision. When pivoting is warranted, Ries provides a taxonomy of 10 named pivot types — from Zoom-in and Customer Segment to Engine of Growth — so teams can change course precisely rather than randomly. Growth is modeled through three Engines of Growth (Sticky, Viral, Paid), each with a defining metric that tells you whether the engine is actually working.

The problem

Most founders spend months building products customers don't want, then discover this only after launch. They track vanity metrics (registered users, page views) that feel like progress but don't reveal whether the core business hypothesis is true. Without a structured experiment design, every feature shipped is an act of faith — expensive, slow, and reversible only at enormous cost.

The solution

Stop treating product development as a guessing game. Run tight Build-Measure-Learn cycles that falsify your riskiest assumptions in days or weeks — before investing months of engineering time — and know exactly when to pivot versus when to push harder.

You bring

Your startup idea, product concept, or feature assumption you need to validate
Any data or customer signals you've already collected (even informal feedback counts)
Your current constraints: team size, runway, and technical capabilities
The business model or growth assumption you're most uncertain about

You get

A completed Validated Learning Hypothesis Card with your riskiest assumption, falsifiable test, and pre-defined success threshold
An MVP Experiment Brief specifying which MVP type fits your context and exactly what to build (and not build)
An Innovation Accounting Dashboard structure with baseline metrics, tuning milestones, and a pivot/persevere decision trigger
A named pivot diagnosis — which of the 10 pivot types applies to your situation — with a structured memo of evidence and recommendation

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“You have a product idea, 6 months of runway, and a developer ready to start. You've done market research and believe strongly in the concept. Three months into building, your first customer interviews reveal that the core workflow you automated doesn't match how users actually work — and the buyer you designed for doesn't control the budget. You're too far in to change directions without abandoning what you've built.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Lean Startup

“Before a single line of code is written, you've run a Concierge MVP with 3 real companies, confirmed that the pain is acute and the buyer has budget authority, and collected a signed letter of intent from one of them. Your Validated Learning Hypothesis Card documents exactly what you learned, your Innovation Accounting baseline is set, and your first sprint is scoped to automate only what the manual experiment proved customers actually use.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Lean StartupClaude

Lean Startup

Let's run a Build-Measure-Learn cycle together. Before we talk about what to build, I want to surface your leap-of-faith hypothesis — the single riskiest assumption your business depends on. If it's wrong, the rest of the plan collapses. What's the core idea, and what has to be true about customer behavior for it to work?

I'm building a B2B SaaS tool that helps operations managers track contractor compliance documents — licenses, insurance certs, that kind of thing. My assumption is that operations managers at mid-size construction firms are actively losing sleep over expired certs and would pay $300/month to automate the tracking.

Good — you've actually named two distinct leap-of-faith hypotheses. The value hypothesis: that expired contractor certs are a painful, active problem (not just an annoyance managers tolerate). The growth hypothesis: that they'll pay $300/month for automation rather than hiring an admin or using a spreadsheet. These need to be tested in sequence — value hypothesis first, because if the pain isn't acute, the price question doesn't matter. Have you talked to 10 operations managers and heard any of them describe this problem without you prompting it? Or are you inferring the pain from observation?

I've talked to 4 of them. Two said they use spreadsheets and it's annoying. The other two said compliance is managed by their legal/HR team and they don't own it.

That's a critical signal — 50% of your sample don't own the problem you're solving. Before building anything, you need to validate the customer segment assumption: is the buyer the operations manager, the HR/compliance officer, or someone else? This points toward a Customer Segment pivot risk. I'd recommend a Concierge MVP here: offer to manage compliance tracking manually for 3 firms at no charge for 30 days in exchange for access and feedback. You'll learn whether they engage, who actually cares, and whether the workflow you'd automate matches their real process. Success metric: do at least 2 of 3 firms actively use the manual service and report that a flagged expiring cert would have caused a real business problem? That's your value hypothesis test — not a survey, but observed behavior.

I hadn't thought about running it manually first. What metrics should I track during those 30 days?

Avoid vanity metrics like 'number of documents uploaded.' Focus on actionable metrics tied to the pain: (1) Engagement rate — did they send you cert renewals unprompted, or did you have to chase them? High friction means the pain isn't acute enough. (2) Near-miss catch rate — did you flag at least one cert about to expire, and did the manager react with urgency or indifference? (3) Willingness to extend — at day 30, do they ask to continue? That's the strongest proxy for value. Track these in a simple cohort log: one row per firm, one column per week. If 2 of 3 firms show all three signals, your value hypothesis is validated and you move to testing the $300/month price point with a real invoice. If fewer than 2 do, you've learned something expensive without writing a line of code — and we can use the data to diagnose which of the 10 pivot types fits.

This is way more structured than how I was approaching it. I was about to start building the full app next week.

That's exactly the trap the Lean Startup is designed to prevent. You would have spent 3-4 months building an app for a customer segment that may not own the problem, at a price point untested against real alternatives. The Concierge MVP costs you 30 days and zero engineering. If the value hypothesis fails, you pivot — maybe to the compliance officer segment, which is a Customer Segment pivot — and run the same manual experiment there. You only start building when you have validated learning that the pain is real, the buyer is identified, and someone has paid or committed to pay. Let me help you draft the Hypothesis Card and the 30-day MVP Experiment Brief so you have a concrete document to run from.

Reply to Lean Startup…

What the skill is doing

01Leap-of-Faith Hypothesis Design

02MVP Experiment Builder

03Innovation Accounting Setup

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

LSLean Startuptyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

I'm building a B2B SaaS tool that helps operations managers track contractor compliance documents — licenses, insurance certs, that kind of thing. My…9:14✓✓

Let's run a Build-Measure-Learn cycle together.9:14

Before we talk about what to build, I want to surface your leap-of-faith hypothesis — the single riskiest assumption your business…9:15

If it's wrong, the rest of the plan collapses.9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Leap-of-Faith Hypothesis Design

Surfaces and sharpens the single riskiest assumption your business depends on — the one that, if false, collapses everything else. Transforms vague beliefs ('people will pay for this') into falsifiable, time-bound, metric-anchored hypotheses ready for experimental test design.

◦ MethodBased on Ries's concept that every startup has leap-of-faith assumptions — a value hypothesis (does the product deliver value?) and a growth hypothesis (how do new customers discover it?) — and that identifying the right one to test first is the founder's most important strategic decision.

CapabilityC-02

MVP Experiment Builder

Designs the smallest possible experiment to test your hypothesis, matching the MVP type to your constraints: a landing page to test demand, a Concierge MVP to test value delivery manually, a Wizard of Oz MVP to test a workflow before automating it, or a video (like Dropbox's) to test purchase intent before building anything.

◦ MethodDraws on Ries's taxonomy of MVP types and the principle that an MVP is not a minimal product but the smallest vehicle for validated learning — defined by what you need to learn, not by what is technically easiest to build.

CapabilityC-03

Innovation Accounting Setup

Replaces vanity metrics with actionable ones by structuring a three-milestone accounting framework: establish a baseline (where your metrics actually are), tune the engine (targeted improvements to move toward ideal), and reach the decision point (pivot or persevere based on real cohort behavior, not aggregate totals).

◦ MethodBased on Ries's innovation accounting system, which requires cohort analysis over aggregate metrics — replacing 'we grew total users' with 'cohort retention improved from 20% to 35% after the onboarding redesign,' a causal claim testable in the next Build-Measure-Learn cycle.

CapabilityC-04

Pivot Type Diagnosis

When your experiment reveals the current strategy isn't working, this capability guides a structured pivot analysis — diagnosing which of Ries's 10 named pivot types best matches your situation and building a pivot/persevere decision memo with the specific evidence, recommended pivot type, and next hypothesis to test.

◦ MethodBased on Ries's pivot typology — Zoom-in, Zoom-out, Customer Segment, Customer Need, Platform, Business Architecture, Value Capture, Engine of Growth, Channel, Technology — which gives founders a precise vocabulary for a directional change rather than a vague 'let's try something different.'

CapabilityC-05

Engine of Growth Identification

Identifies which of the three Engines of Growth (Sticky, Viral, or Paid) your business model relies on, defines the single defining metric for that engine, and builds a test to determine whether the engine is working or stalled — preventing teams from optimizing the wrong metrics entirely.

◦ MethodBased on Ries's three-engine framework: Sticky growth depends on retention rate exceeding churn; Viral growth requires a viral coefficient greater than 1.0; Paid growth requires lifetime value (LTV) exceeding customer acquisition cost (CAC) — each implying a completely different set of actionable metrics.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Validated Learning Hypothesis Card

A structured one-page document capturing your leap-of-faith assumption, the specific experiment designed to test it (including MVP type and build scope), the pre-defined success threshold, and the decision rule — if metric X reaches Y within Z days, we persevere; otherwise, we diagnose a pivot.

OutputD-02

Innovation Accounting Dashboard

A metric framework structured around three milestones — baseline, tuned, decision — with cohort-based metrics (not vanity aggregates) for your specific Engine of Growth. Replaces 'total signups' with retention curves, conversion funnels, or viral coefficients that actually reveal whether the business model is working.

OutputD-03

Pivot/Persevere Decision Memo

A structured memo that states the original hypothesis, summarizes the experimental evidence from the last Build-Measure-Learn cycle, names the specific pivot type recommended from Ries's 10-type taxonomy, and defines the next leap-of-faith hypothesis to test in the next cycle.

OutputD-04

MVP Experiment Brief

A concise spec for the minimum viable experiment: which MVP type (Concierge, landing page, Wizard of Oz, etc.), exactly what to build and what to leave out, who the test participants are, how you'll measure the outcome, and what result constitutes validated learning versus a failed hypothesis.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Eric Ries

Eric Ries is the entrepreneur and author who coined the term 'Lean Startup' while co-founding IMVU, a social avatar platform, where he served as CTO. His 2011 book The Lean Startup became an international bestseller translated into 30+ languages, and his 2017 follow-up The Startup Way extended the framework to enterprise and government organizations. He is also the founder of the Long-Term Stock Exchange (LTSE), a registered national securities exchange built on Lean Startup principles.

Status · Inspired by Eric Ries’s work — not yet claimed. Are you Eric Ries?

Primary sourceS-01

The Lean Startup (2011)

by Eric Ries

Co-founder & CTO, IMVU; international bestselling author of The Lean Startup (30+ languages); founder, Long-Term Stock Exchange (LTSE); advisor to startups, Fortune 500s, and the U.S. government.

Read the original ↗

Citationtheleanstartup.com

In the build queue

Be first to run it.

Lean Startup is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchI have a startup idea I'm ready to start building — but I want to run a proper Build-Measure-Learn cycle first. Can you help me identify my leap-of-faith hypothesis and design the right MVP to test it before I write any code?