lean-startup
정보
이 스킬은 개발자들이 린 스타트업 원칙을 적용하여 MVP를 설계하고, 검증된 학습 실험을 실행하며, 데이터 기반의 전환 또는 고수 결정을 내리는 데 도움을 줍니다. 사용자를 '구축-측정-학습' 루프로 안내하며, 허영 지표보다 혁신 회계와 실행 가능한 지표에 중점을 둡니다. 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 if 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.
The foundation: Most startups fail not because they couldn't build what they planned, but because they built the wrong thing. The Lean Startup methodology applies scientific experimentation to eliminate waste and accelerate validated learning.
Scoring
Goal: 10/10. When reviewing or creating product development plans, experiments, or metrics, rate them 0-10 based on adherence to Lean Startup principles. A 10/10 means full application of Build-Measure-Learn, validated learning, and evidence-based decisions; lower scores indicate waterfall thinking or waste. Always provide the current score and specific improvements needed to reach 10/10.
The Build-Measure-Learn Loop
The fundamental cycle of Lean Startup:
IDEAS
↓
BUILD → Product
↓
MEASURE → Data
↓
LEARN → Knowledge
↓
(back to IDEAS)
Critical insight: The loop is actually backward. Start with what you want to learn, determine metrics that will inform that learning, then build the minimum product to collect those metrics.
Reverse planning:
- 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 for detailed loop execution.
Validated Learning
Definition: Learning what customers really want through validated experiments, not opinion or anecdotes.
Validated learning is not:
- Building features customers request (they don't know what they want)
- Achieving vanity metrics (downloads, signups without engagement)
- Doing surveys or focus groups (people lie/mispredict behavior)
Validated learning is:
- Testing hypotheses with real behavior
- Measuring what customers do, not what they say
- Running experiments that could falsify your assumptions
- Learning = when your predictions were wrong
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)
Definition: The version of a new product that allows a team to collect the maximum amount of validated learning with the least effort.
MVP is not:
- A prototype (not about proving technical feasibility)
- A beta version (not about quality or features)
- A minimum marketable product (it might be embarrassing)
MVP is:
- A learning vehicle
- The smallest experiment to test a hypothesis
- Often 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) |
MVP Design Questions:
- What's the riskiest assumption to test first?
- What's the minimum to test that assumption?
- How do we measure if the assumption was validated?
Common mistakes:
- Building too much (overestimate MVP size)
- Optimizing for scale prematurely
- Confusing quality with learning (MVP can be low quality)
- Skipping the experiment (building without hypothesis)
See: references/mvp-design.md for MVP types and design patterns.
Leap-of-Faith Assumptions
Definition: The assumptions that, if wrong, will cause your business to fail.
Process:
- Identify your business model's critical assumptions
- Prioritize by risk (which failure would be fatal?)
- Test the riskiest assumption first
Common leap-of-faith assumptions:
| 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 showing product (before building full version)
- Metric: Beta signup list grew from 5,000 to 75,000 overnight
- Learning: Validated demand before building scale infrastructure
Anti-pattern: Testing assumptions in order of ease rather than risk.
See: references/assumptions.md for assumption mapping frameworks.
Innovation Accounting
Definition: Measuring progress when traditional accounting doesn't apply.
The problem with traditional metrics:
- Revenue (startups start at $0)
- Customers (startups start at 0)
- Vanity metrics (look good but don't drive decisions)
Innovation accounting framework:
1. Establish the Baseline
Question: Where are we today?
Measure current reality, even if it's zero or embarrassing.
Metrics to establish:
- Conversion funnel (signup → active → retained → paying)
- Engagement (DAU/MAU, session length, features used)
- Economics (CAC, LTV, churn rate)
Goal: Know your starting point precisely.
2. Tune the Engine
Question: What can we improve to move toward our goal?
Run experiments to improve baseline metrics.
Examples:
- A/B test pricing ($9/mo vs. $19/mo)
- Test onboarding flows (% who complete setup)
- Experiment with channels (SEO vs. paid vs. referral)
Goal: Systematically improve metrics through validated learning.
3. Pivot or Persevere
Question: Are we making sufficient progress, or do we need to change strategy?
Based on data, decide whether to continue or pivot.
Criteria:
- Are metrics moving in the right direction?
- Is the rate of improvement acceptable?
- Are we learning what we expected?
Goal: Make evidence-based strategic decisions.
See: references/innovation-accounting.md for metric frameworks and dashboards.
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 (can reproduce)
- Accessible: Simple, understandable by everyone
- Auditable: Can check the underlying data (not a black box)
Example:
- Vanity: "We have 100,000 users!"
- Actionable: "Users from channel X have 2x retention vs. channel Y. Let's double down on X."
Cohort analysis: Group users by signup date and track behavior over time. Reveals if product is actually improving.
See: references/metrics.md for metric selection and tracking.
Pivot or Persevere
Pivot: A structured course correction designed to test a new hypothesis about the product, strategy, or engine of growth.
When to pivot:
- Experiments consistently fail to validate hypotheses
- Metrics are flat despite multiple iterations
- Customer feedback contradicts your vision
- Progress is too slow given runway
When to persevere:
- Metrics are improving (even if slowly)
- Clear learning is happening
- Adjustments are moving in right direction
Pivot Types:
| Pivot Type | What Changes | Example |
|---|---|---|
| Zoom-in pivot | Single feature becomes the whole product | Instagram (photo filters from Burbn check-in app) |
| Zoom-out pivot | 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 Sandwich (antique store → sandwiches) |
| Platform | App → Platform or Platform → App | 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 growth model | Facebook (viral within colleges → paid advertising) |
| Channel | How you reach customers | Salesforce (direct sales → self-service) |
| Technology | Different technology, same solution | Apple (Intel → ARM chips) |
Pivot cadence: Many successful startups pivot 1-5 times before finding product-market fit.
Anti-pattern: "Pivot" without validating that the new direction solves the core problem.
See: references/pivots.md for pivot decision frameworks and case studies.
The Three Engines of Growth
Growth engine: How your startup acquires and retains customers sustainably.
Choose one engine to focus on:
1. Sticky Engine of Growth
Mechanism: High retention, low churn
Formula: Growth rate = New customer acquisition rate - Churn rate
Focus: Keep customers coming back
Metrics:
- Churn rate (% who stop using per month)
- Retention cohorts (% still active after 30/60/90 days)
- Engagement (DAU/MAU ratio)
Examples: SaaS, subscription services, social networks
Strategy: Improve product until churn rate is low enough that natural growth exceeds churn.
2. Viral Engine of Growth
Mechanism: Customers bring other customers
Formula: Viral coefficient = (% who invite) × (invites sent) × (% who join)
Focus: Viral coefficient > 1.0 = exponential growth
Metrics:
- Viral coefficient (invites → signups)
- Viral cycle time (how long until referred user invites others)
- Referral source attribution
Examples: Dropbox, Hotmail, WhatsApp
Strategy: Build virality into the product. Must be > 1.0 to be self-sustaining.
3. Paid Engine of Growth
Mechanism: Spend money to acquire customers
Formula: LTV (Lifetime Value) > CAC (Customer Acquisition Cost)
Focus: Unit economics that allow reinvestment
Metrics:
- CAC (cost per acquisition)
- LTV (average revenue per customer)
- LTV/CAC ratio (target: > 3x)
- Payback period (how long to recoup CAC)
Examples: E-commerce, traditional businesses
Strategy: Optimize until each customer generates enough profit to acquire more customers.
Warning: Don't use multiple engines simultaneously. Pick one, optimize it, then consider adding others.
See: references/growth-engines.md for engine selection and optimization.
The Five Whys
Purpose: Root cause analysis to prevent problems from recurring.
Process:
- A problem occurs (bug, outage, customer complaint)
- Ask "Why did this happen?" → Answer
- Ask "Why?" about that answer → Second answer
- Repeat 5 times until you reach the root cause
- Make proportional investments at each level
Example:
Problem: Website went down
- Why? Server ran out of memory
- Why? Memory leak in 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 immediate bug (level 1)
- Add memory monitoring (level 2)
- Implement code review (level 3-4)
- Slow down to build quality processes (level 5)
Anti-pattern: Stop at level 1 (just fix the symptom).
See: references/five-whys.md for facilitation guides.
Small Batches
Principle: Work in small batches to accelerate learning and reduce waste.
Why small batches win:
- Faster feedback loops
- Easier to pivot
- Less waste when you're wrong
- Faster time to market
Examples:
| 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: The ultimate small batch = deploy every code commit.
Benefits:
- Bugs are caught immediately
- Learning happens continuously
- Reduced risk per deployment
See: references/small-batches.md for implementation patterns.
Lean Startup Applied
For different contexts:
SaaS Startup
- Smoke test: Landing page + email list (validate demand)
- Concierge MVP: Manually deliver service to 10 customers (validate value)
- Single-feature MVP: Build one core workflow (validate engagement)
- Measure: Retention, NPS, feature usage
- Pivot or scale: Based on cohort data
Corporate Innovation
- Innovation accounting: Separate metrics from core business
- Protected teams: Shield from quarterly revenue pressure
- Metered funding: Unlock funding based on validated learning milestones
- Internal entrepreneurship: Treat team as startup within company
Product Features
- Feature flags: Deploy behind flag, test with small cohort
- A/B test: Measure impact on core metrics
- Kill, iterate, or scale: Based on data
See: references/applications.md for context-specific guides.
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 |
Quick Diagnostic
Audit any product development plan:
| Question | If No | Action |
|---|---|---|
| What's the riskiest assumption? | You're building on shaky ground | Map leap-of-faith assumptions |
| How will you test it? | You're guessing | Design MVP to test assumption |
| What metric will validate/invalidate? | You won't learn | Define actionable metrics |
| Can you test with less than this? | You're over-building | Shrink MVP further |
| What will you do if the experiment fails? | No pivot criteria | Define pivot triggers upfront |
The Lean Startup Applied: From Idea to Scale
Phase 1: Problem/Solution Fit
- Goal: Validate the problem exists and customers care
- Method: Customer discovery, smoke tests, concierge MVP
- Metric: Customers willing to pay or commit
Phase 2: Product/Market Fit
- Goal: Build something people want
- Method: Build MVP, iterate based on usage data
- Metric: High retention, organic growth, strong engagement
Phase 3: Scale
- Goal: Grow efficiently
- Method: Optimize growth engine, improve unit economics
- Metric: Sustainable, profitable growth
Anti-pattern: Skipping Phase 1-2 and jumping straight to scale.
Reference Files
- build-measure-learn.md: Detailed loop execution, reverse planning
- mvp-design.md: MVP types, design patterns, sizing
- assumptions.md: Leap-of-faith assumption mapping
- innovation-accounting.md: Metric frameworks, dashboards
- metrics.md: Actionable vs. vanity, cohort analysis, metric selection
- pivots.md: Pivot types, decision frameworks, case studies
- growth-engines.md: Sticky, viral, paid engines in depth
- five-whys.md: Root cause analysis, facilitation guides
- small-batches.md: Batch size reduction, continuous deployment
- applications.md: SaaS, corporate innovation, features
- case-studies.md: Dropbox, IMVU, Zappos, Groupon, and failures
Further Reading
This skill is based on Eric Ries' Lean Startup methodology. 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 best known for developing the Lean Startup methodology. He was co-founder and CTO of IMVU, where he pioneered continuous deployment and customer development practices that became the foundation of Lean Startup. The Lean Startup has been translated into over 30 languages and has influenced startup culture worldwide. Ries is also the creator of the Long-Term Stock Exchange (LTSE), a new stock exchange designed for companies focused on long-term value creation.
GitHub 저장소
연관 스킬
content-collections
메타이 스킬은 콘텐츠 콜렉션(Content Collections)을 위한 프로덕션 검증된 설정을 제공합니다. 콘텐츠 콜렉션은 Markdown/MDX 파일을 Zod 검증이 포함된 타입 안전한 데이터 콜렉션으로 변환해주는 TypeScript 최우선 도구입니다. 블로그, 문서 사이트 또는 콘텐츠 중심의 Vite + React 애플리케이션을 구축할 때 타입 안전성과 자동 콘텐츠 검증을 보장하기 위해 사용하세요. Vite 플러그인 구성과 MDX 컴파일부터 배포 최적화 및 스키마 검증에 이르기까지 모든 것을 다룹니다.
polymarket
메타이 스킬은 개발자들이 Polymarket 예측 시장 플랫폼을 활용한 애플리케이션을 구축할 수 있도록 지원하며, 거래 및 시장 데이터를 위한 API 통합 기능을 포함합니다. 또한 WebSocket을 통한 실시간 데이터 스트리밍을 제공하여 실시간 거래와 시장 활동을 모니터링할 수 있습니다. 이를 통해 거래 전략을 구현하거나 실시간 시장 업데이트를 처리하는 도구를 생성하는 데 활용할 수 있습니다.
creating-opencode-plugins
메타이 스킬은 개발자들이 명령어, 파일, LSP 작업 등 25개 이상의 이벤트 유형에 연결되는 OpenCode 플러그인을 만들 수 있도록 돕습니다. JavaScript/TypeScript 모듈을 위한 플러그인 구조, 이벤트 API 명세, 구현 패턴을 제공합니다. OpenCode AI 어시스턴트의 라이프사이클을 사용자 정의 이벤트 기반 로직으로 가로채거나, 모니터링하거나, 확장해야 할 때 사용하세요.
sglang
메타SGLang은 RadixAttention 프리픽스 캐싱을 활용하여 JSON, 정규식, 에이전트 워크플로우를 위한 고속 구조화 생성에 특화된 고성능 LLM 서빙 프레임워크입니다. 특히 반복되는 프리픽스가 있는 작업에서 상당히 빠른 추론 속도를 제공하여 복잡한 구조화 출력 및 다중 턴 대화에 이상적입니다. 제약 디코딩이 필요하거나 광범위한 프리픽스 공유가 있는 애플리케이션을 구축할 때는 vLLM과 같은 대안보다 SGLang을 선택하십시오.
