정보
이 스킬은 개발자들이 '만들기-측정하기-배우기' 루프를 활용해 최소 기능 제품(MVP)과 검증된 학습 실험을 설계하도록 돕습니다. 첫 번째 버전에 무엇을 포함할지, 실행 가능한 지표로 진행 상황을 측정하는 방법, 방향 전환(pivot)을 할지 지속할지(persevere)에 대한 결정을 안내합니다. MVP 범위를 설정하거나, 비즈니스 가정을 저비용으로 테스트하거나, 제품 방향성을 평가할 때 사용하세요.
빠른 설치
Claude Code
추천npx skills add wondelai/skills -a claude-code/plugin add https://github.com/wondelai/skillsgit clone https://github.com/wondelai/skills.git ~/.claude/skills/lean-startupClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Lean Startup Methodology
A systematic approach to building startups and launching new products that shortens development cycles and rapidly discovers whether a business model is viable.
Core Principle
Entrepreneurship is a form of management. Success doesn't require a perfect plan or brilliant insight—it requires a systematic process for testing assumptions, learning from customers, and iterating rapidly. Most startups fail not because they couldn't build what they planned, but because they built the wrong thing: treat every plan as a set of hypotheses to falsify, and spend effort to eliminate waste and accelerate validated learning, not to execute a fixed roadmap.
Scoring
Goal: 10/10. Score a plan, experiment, or metric set by the five Quick Diagnostic rows—1 point each when the answer is yes, 2 points when it is also backed by evidence on the Validation Ladder (Level 3+):
- 9-10: every leap-of-faith assumption named and ranked by risk, the riskiest tested by a real MVP, actionable metrics defined, and explicit pivot criteria set before building.
- 5-6: a hypothesis and some MVP exist, but metrics are vanity or pivot criteria are undefined—decisions can't be made from the data.
- ≤3: waterfall thinking—building the full product first, asking customers what they want, or scaling before product/market fit.
State the current score and the lowest-scoring diagnostic row to fix next.
The Build-Measure-Learn Loop
The fundamental cycle: IDEAS → BUILD (product) → MEASURE (data) → LEARN (knowledge) → back to IDEAS.
Critical insight: Plan the loop backward:
- What do we want to learn? (hypothesis to test)
- How will we know if we learned it? (metrics)
- What's the minimum we can build? (MVP)
Goal: Minimize total time through the loop.
See references/build-measure-learn.md when planning an experiment—reverse-planning sequence, an experiment-design template, per-product-type loop examples, and the build/vanity-metric loop traps.
Validated Learning
Learning what customers really want through experiments on real behavior—not feature requests, surveys, or focus groups (people mispredict their own behavior). Measure what customers do, not what they say, and run experiments that could falsify your assumptions. Vanity wins (downloads, signups without engagement) are not learning.
The Validation Ladder:
| Level | Evidence | Strength |
|---|---|---|
| 1 | "I think customers want this" | Weakest (opinion) |
| 2 | "Customers said they want this" | Weak (stated preference) |
| 3 | "Customers signed up for early access" | Medium (low commitment) |
| 4 | "Customers paid a deposit" | Strong (real commitment) |
| 5 | "Customers are actively using it" | Strongest (revealed preference) |
Target: Level 4-5 before building at scale.
Minimum Viable Product (MVP)
The version of a new product that allows maximum validated learning with the least effort. Not a prototype (technical feasibility), not a beta (quality), not a minimum marketable product—a learning vehicle, often embarrassingly small and low quality, and usually much smaller than you think.
MVP Types:
| Type | What It Is | When to Use | Example |
|---|---|---|---|
| Concierge | Manual service pretending to be automated | Test if solution is valuable | Food on the Table (manual meal planning) |
| Wizard of Oz | Fake automation, manual backend | Test if automation is needed | Zappos (no inventory, bought shoes retail) |
| Smoke test | Landing page + signup, no product | Test demand before building | Dropbox video (explained concept, measured signups) |
| Single feature | One core feature only | Test which feature is most valuable | Twitter (just status updates) |
| Piecemeal | Combine existing tools | Test workflow before custom build | Groupon (WordPress + email) |
Design questions: What's the riskiest assumption? What's the minimum that tests it? How do we measure whether it was validated?
See references/mvp-design.md when choosing and sizing an MVP—seven types in depth, a type-selection decision matrix, lower/upper sizing bounds, and the MVP Design Canvas.
Leap-of-Faith Assumptions
The assumptions that, if wrong, will cause your business to fail. Identify them, prioritize by risk (which failure would be fatal?), and test the riskiest first—never in order of ease.
| Assumption Type | Question | Test Method |
|---|---|---|
| Value hypothesis | Do customers care about this problem? | Smoke test, concierge MVP |
| Growth hypothesis | How will customers discover us? | Channel tests, referral experiments |
| Retention hypothesis | Will customers come back? | Cohort analysis, engagement metrics |
| Monetization hypothesis | Will customers pay? | Pre-orders, pricing tests |
Example—Dropbox: Leap of faith: "people will download and use a file sync tool." Test: explainer video before building scale infrastructure. Result: beta list grew from 5,000 to 75,000 overnight—demand validated.
See references/assumptions.md when mapping and ranking assumptions—the Impact-Uncertainty matrix, a prioritization scoring template, test methods per assumption type, and industry-specific assumption lists.
Innovation Accounting
Measuring progress when traditional metrics fail: revenue and customers start at zero, and vanity metrics look good without driving decisions.
1. Establish the Baseline
Measure current reality precisely, even if it's zero or embarrassing: conversion funnel (signup → active → retained → paying), engagement (DAU/MAU, session length, features used), economics (CAC, LTV, churn).
2. Tune the Engine
Run experiments to improve baseline metrics: A/B test pricing ($9 vs. $19/mo), onboarding completion rates, acquisition channels (SEO vs. paid vs. referral). Each experiment targets a measurable improvement through validated learning.
3. Pivot or Persevere
When tuning stalls, make the evidence-based call (criteria and pivot types below in Pivot or Persevere).
See references/innovation-accounting.md when building the baseline dashboard—funnel, cohort, and economics metric frameworks.
Actionable vs. Vanity Metrics
Vanity metrics make you feel good but don't change behavior; actionable metrics drive decisions and clarify cause and effect.
| Vanity | Why It's Bad | Actionable Alternative |
|---|---|---|
| Total signups | Always goes up, no context | % signup → active (conversion rate) |
| Page views | Doesn't indicate value | Time on page, bounce rate |
| Total users | Includes inactive/churned | Active users (DAU, WAU, MAU) |
| Downloads | Doesn't mean usage | DAU/downloads (activation rate) |
| Revenue | Without context | Revenue per cohort, LTV/CAC |
Three characteristics of actionable metrics: actionable (clear cause-and-effect, reproducible), accessible (simple, understood by everyone), auditable (underlying data can be checked).
Example: Vanity: "We have 100,000 users!" Actionable: "Channel X users retain 2x better than channel Y—double down on X."
Cohort analysis: Group users by signup date and track behavior over time—the only way to see whether the product is actually improving.
See references/metrics.md when building a cohort table or choosing what to track—a five-step cohort walkthrough and AARRR (Pirate Metrics) aligned with Lean Startup stages.
Pivot or Persevere
A pivot is a structured course correction designed to test a new hypothesis about the product, strategy, or engine of growth.
Pivot when: experiments repeatedly fail to validate hypotheses, metrics stay flat despite iterations, customer feedback contradicts the vision, or progress is too slow for the runway. Persevere when: metrics are improving (even slowly), clear learning is happening, and adjustments move the right direction.
Pivot Types:
| Pivot Type | What Changes | Example |
|---|---|---|
| Zoom-in | Single feature becomes the whole product | Instagram (photo filters from Burbn) |
| Zoom-out | Product becomes a single feature | Flickr (photo-sharing from Game Neverending) |
| Customer segment | Same problem, different customer | Groupon (activism platform → local deals) |
| Customer need | Same customer, different problem | Potbelly (antique store → sandwiches) |
| Platform | App ↔ Platform | YouTube (dating site → video platform) |
| Business architecture | High margin/low volume ↔ low margin/high volume | Salesforce (software → SaaS) |
| Value capture | Monetization model change | Android (paid → free + app revenue) |
| Engine of growth | Viral, sticky, or paid model | Facebook (viral in colleges → paid advertising) |
| Channel | How you reach customers | Salesforce (direct sales → self-service) |
| Technology | Different technology, same solution | Apple (Intel → ARM chips) |
Cadence: Successful startups commonly pivot 1-5 times before product-market fit. Anti-pattern: "pivoting" without validating that the new direction solves the core problem.
See references/pivots.md when the data suggests a pivot—the data-driven pivot signals, a structured pivot-meeting agenda, leading indicators, and the Instagram/Slack/YouTube pivot stories.
The Three Engines of Growth
How a startup acquires and retains customers sustainably. Pick one engine, optimize it, then consider adding others—running multiple engines simultaneously dilutes focus and learning.
1. Sticky Engine of Growth
Retention-driven: growth rate = new customer acquisition rate − churn rate. Track churn rate, retention cohorts (30/60/90 days), and DAU/MAU. Fits SaaS, subscriptions, social networks. Strategy: improve the product until natural growth exceeds churn.
2. Viral Engine of Growth
Customers bring customers: viral coefficient = (% who invite) × (invites sent) × (% who join); above 1.0 means exponential, self-sustaining growth. Track the coefficient, viral cycle time, and referral attribution. Fits Dropbox, Hotmail, WhatsApp. Strategy: build virality into the product itself.
3. Paid Engine of Growth
Spend to acquire: requires LTV > CAC (target LTV/CAC > 3x). Track CAC, LTV, and payback period. Fits e-commerce and traditional businesses. Strategy: optimize until each customer's profit funds acquiring more.
See references/growth-engines.md when picking or tuning an engine—churn-reduction tactics, the K-factor and viral-loop design, LTV/CAC optimization, a channel-economics table, and the product-to-engine matching framework.
The Five Whys
Root cause analysis: when a problem occurs, ask "why?" five times, then invest proportionally at every level—not just the symptom.
Example—website went down:
- Why? Server ran out of memory
- Why? Memory leak in a new feature
- Why? Code wasn't reviewed for memory management
- Why? No code review process for infrastructure changes
- Why? Team is moving too fast to create processes
Proportional investments: fix the bug (1), add memory monitoring (2), implement code review (3-4), slow down to build quality processes (5). Anti-pattern: stopping at level 1.
See references/five-whys.md when facilitating a session—three worked examples (outage, churn spike, launch failure) and how to handle diverging chains, blame creep, and root causes outside your control.
Small Batches
Work in small batches for faster feedback loops, easier pivots, less waste when you're wrong, and faster time to market.
| Large Batch | Small Batch |
|---|---|
| Build entire product, then launch | Launch landing page, then build |
| Release quarterly | Release weekly or daily |
| Plan 12-month roadmap | Plan 6-week cycles |
| Big bang rewrite | Incremental refactoring |
Continuous deployment is the ultimate small batch: deploy every commit, catch bugs immediately, learn continuously, reduce risk per release.
See references/small-batches.md when setting up faster release cadence—the continuous-deployment pipeline and prerequisites, feature-flag types, a progressive-rollout checklist, and work-decomposition techniques.
Lean Startup Applied: From Idea to Scale
Phase 1—Problem/Solution Fit: validate that the problem exists and customers care, via customer discovery, smoke tests, and concierge MVPs. Metric: customers willing to pay or commit.
Phase 2—Product/Market Fit: build the MVP and iterate on usage data. Metric: high retention, organic growth, strong engagement.
Phase 3—Scale: optimize the growth engine and unit economics. Metric: sustainable, profitable growth. Anti-pattern: skipping Phases 1-2 and jumping straight to scale.
By context:
- SaaS startup: smoke test (landing page + email list) → concierge MVP with 10 customers → single-feature MVP → measure retention, NPS, feature usage → pivot or scale on cohort data
- Corporate innovation: separate innovation accounting from core-business metrics, shield teams from quarterly revenue pressure, unlock metered funding on validated-learning milestones
- Product features: deploy behind a feature flag → A/B test against core metrics → kill, iterate, or scale based on data
See references/applications.md for context-specific playbooks (SaaS, corporate innovation, features), and references/case-studies.md for the full Dropbox, IMVU, Zappos, and Groupon stories—including failures—when you want a worked precedent for the bet in front of you.
Common Mistakes
| Mistake | Why It Fails | Fix |
|---|---|---|
| Building too much | Waste before validation | Test with smoke test or concierge first |
| Asking customers | People don't know/mispredict | Observe behavior, not opinions |
| Vanity metrics | Feel-good numbers, no decisions | Track cohorts, conversion, retention |
| No hypothesis | Can't learn if you don't predict | Write hypothesis before each experiment |
| Pivot too slow | Waste runway | Set clear pivot criteria upfront |
| Skip innovation accounting | Can't tell if you're improving | Establish baseline, measure tuning efforts |
| Premature scale optimization | Polishing before product-market fit | Validate learning first; quality follows evidence |
Quick Diagnostic
Audit any product development plan:
| Question | If No | Action |
|---|---|---|
| What's the riskiest assumption? | Building on shaky ground | Map leap-of-faith assumptions |
| How will you test it? | You're guessing | Design MVP to test the assumption |
| What metric will validate/invalidate? | You won't learn | Define actionable metrics |
| Can you test with less than this? | Over-building | Shrink the MVP further |
| What will you do if the experiment fails? | No pivot criteria | Define pivot triggers upfront |
Further Reading
For the complete framework, research, and case studies:
- "The Lean Startup" by Eric Ries
- "The Startup Way" by Eric Ries (applying Lean Startup to established companies)
About the Author
Eric Ries is an entrepreneur and author who developed the Lean Startup methodology as co-founder and CTO of IMVU, where he pioneered the continuous deployment and customer development practices behind it. The Lean Startup has been translated into over 30 languages and shaped startup culture worldwide. He later created the Long-Term Stock Exchange (LTSE).
GitHub 저장소
자주 묻는 질문
lean-startup Skill이란 무엇인가요?
lean-startup은(는) wondelai이(가) 만든 Claude Skill입니다. Skill은 Claude가 필요할 때 불러오는 지침과 리소스를 묶어 추가 프롬프트 없이 lean-startup 관련 작업을 수행할 수 있게 합니다.
lean-startup은(는) 어떻게 설치하나요?
이 페이지의 설치 명령을 사용하세요. lean-startup을(를) Claude Code 플러그인으로 추가하거나 저장소를 skills 디렉터리에 복제한 다음 Claude를 다시 시작해 Skill을 불러옵니다.
lean-startup은(는) 어떤 카테고리에 속하나요?
lean-startup은(는) 메타 카테고리에 속합니다.
lean-startup은(는) 무료로 사용할 수 있나요?
네. lean-startup은(는) AIMCP에 등록되어 있으며 무료로 설치할 수 있습니다.
연관 스킬
이 스킬은 콘텐츠 콜렉션(Content Collections)을 위한 프로덕션 검증된 설정을 제공합니다. 콘텐츠 콜렉션은 Markdown/MDX 파일을 Zod 검증이 포함된 타입 안전한 데이터 콜렉션으로 변환해주는 TypeScript 최우선 도구입니다. 블로그, 문서 사이트 또는 콘텐츠 중심의 Vite + React 애플리케이션을 구축할 때 타입 안전성과 자동 콘텐츠 검증을 보장하기 위해 사용하세요. Vite 플러그인 구성과 MDX 컴파일부터 배포 최적화 및 스키마 검증에 이르기까지 모든 것을 다룹니다.
이 스킬은 개발자들이 Polymarket 예측 시장 플랫폼을 활용한 애플리케이션을 구축할 수 있도록 지원하며, 거래 및 시장 데이터를 위한 API 통합 기능을 포함합니다. 또한 WebSocket을 통한 실시간 데이터 스트리밍을 제공하여 실시간 거래와 시장 활동을 모니터링할 수 있습니다. 이를 통해 거래 전략을 구현하거나 실시간 시장 업데이트를 처리하는 도구를 생성하는 데 활용할 수 있습니다.
이 스킬은 개발자들이 명령어, 파일, LSP 작업 등 25개 이상의 이벤트 유형에 연결되는 OpenCode 플러그인을 만들 수 있도록 돕습니다. JavaScript/TypeScript 모듈을 위한 플러그인 구조, 이벤트 API 명세, 구현 패턴을 제공합니다. OpenCode AI 어시스턴트의 라이프사이클을 사용자 정의 이벤트 기반 로직으로 가로채거나, 모니터링하거나, 확장해야 할 때 사용하세요.
SGLang은 RadixAttention 프리픽스 캐싱을 활용하여 JSON, 정규식, 에이전트 워크플로우를 위한 고속 구조화 생성에 특화된 고성능 LLM 서빙 프레임워크입니다. 특히 반복되는 프리픽스가 있는 작업에서 상당히 빠른 추론 속도를 제공하여 복잡한 구조화 출력 및 다중 턴 대화에 이상적입니다. 제약 디코딩이 필요하거나 광범위한 프리픽스 공유가 있는 애플리케이션을 구축할 때는 vLLM과 같은 대안보다 SGLang을 선택하십시오.
