Mmcp.market

lean-analytics skill

by wondelai·wondelai/skills·2.3k stars·MIT

Choose and audit startup metrics using Croll and Yoskovitz''s "Lean Analytics". Use when the user mentions "what metrics should we track", "KPIs", "north star metric", "One Metric That Matters (OMTM)", "vanity metrics", "analytics dashboard", "DAU/MAU", "churn benchmark", or "measure product-market fit". Also trigger when choosing metrics for a startup or feature, auditing a dashboard for vanity metrics, setting metric targets and baselines, or instrumenting a product by business model and stage. Covers good-vs-vanity metrics, the One Metric That Matters, metrics by business model, the five startup stages, and benchmarks. For the build-measure-learn loop, see lean-startup. For fixing activation and retention, see improve-retention.

A100/100content scan

Is the lean-analytics skill safe?

Clean: nothing in its files matched our rules. We read 6 files in the folder on 2026-09-28.

No findings.

Install the lean-analytics skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/lean-analytics ~/.claude/skills/lean-analytics
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Lean Analytics

A data discipline for startups distilled from Alistair Croll and Benjamin Yoskovitz's Lean Analytics: separate metrics that change decisions from numbers that merely flatter, then point the whole company at the One Metric That Matters for your business model and stage. Use it to choose metrics, audit dashboards, set targets, and plan instrumentation.

Core Principle

Focus on the one metric that matters right now — everything else is noise that feels like progress. Startups die from lack of focus more often than lack of data. The discipline is knowing your business model, knowing your stage, and tracking the single number that tells you whether the riskiest part of the business is working. A metric earns attention only if it changes what you do next.

Scoring

Goal: 10/10. Rate metric choices, dashboards, and instrumentation plans 0-10 against these principles. Report the current score and the specific changes needed to reach 10/10.

  • 9-10: One OMTM matched to model and stage, paired counter-metric, a line in the sand with a pre-committed miss response, cohorted and segmented data
  • 7-8: Mostly actionable ratios and a plausible OMTM, but no explicit target, weak cohorting, or too many "key" metrics
  • 5-6: Actionable and vanity metrics mixed; dashboard exists but rarely changes a decision; model and stage never named
  • 3-4: Vanity metrics dominate — totals, cumulative charts, blended averages; metrics copied from other companies
  • 0-2: No instrumentation, or numbers chosen to impress investors rather than drive decisions

Framework

1. Good Metrics vs Vanity Metrics

Core concept: A good metric is comparative (versus last week, versus another cohort), understandable (the team can recall and debate it), a ratio or rate (not an ever-growing total), and behavior-changing — if a number won't change what you do, stop measuring it. Vanity metrics — total signups, page views, cumulative anything — only go up and only make you feel good.

Why it works: The output of analytics is decisions, not data. Ratios are inherently comparative and operable, while totals hide decay: total registered users rises even while the product bleeds actives. Forcing every metric through the "what will we do differently?" test converts reporting into learning.

Key insights:

  • Work the lens pairs: qualitative vs quantitative (interviews reveal why, numbers reveal how much), exploratory vs reporting (exploration finds your unfair advantage; reporting keeps the lights on), leading vs lagging (complaints predict churn before churn happens), correlated vs causal
  • Correlation finds the lever; only an experiment proves it — find metrics that move together, then change one for a randomized group to test causality
  • Cohorts make time honest: compare users by signup month, or real improvement vanishes inside blended averages
  • Segments make comparisons honest: split by channel, plan, and geography — a flat aggregate often hides one segment soaring and another collapsing
  • Averages lie under skew: whales and lurkers are different businesses, so read medians and percentiles
  • A cumulative up-and-to-the-right chart is the single most reliable vanity tell

Applications:

See references/good-metrics.md when auditing a dashboard or running a metric through the four tests — full test definitions, the 10-row vanity rewrite table, a worked cohort-retention example, segmentation rules, the correlation-to-causation experiment loop, and a metric-definition template.

2. The One Metric That Matters (OMTM)

Core concept: At any moment there is one number that matters above all others — the one that tells you whether the current riskiest assumption is working. Pick it, display it everywhere, and let it drive every experiment until you graduate to the next stage.

Why it works: The OMTM answers the most important question you have right now, forces you to draw a line in the sand so "good" is defined before results arrive, and focuses the entire company. A dashboard of forty numbers diffuses accountability; one number creates a shared scoreboard and a culture of experimentation.

Key insights:

  • The OMTM rotates — it is the metric that matters now, not forever; passing a stage gate or pivoting changes it
  • Pair it with a counter-metric so it can't be gamed: activation speed paired with 30-day retention, sales velocity paired with refund rate
  • A line in the sand has three parts: a target number, a date, and a pre-committed answer to "what do we do if we miss?"
  • "Good enough" is a decision made in advance, not a discovery made after — otherwise the goalposts move
  • If the team can't agree on the OMTM, you haven't agreed what the riskiest part of the business is — that argument is the valuable part
  • Collect many metrics, but watch one — the rest live in drill-down reports, not on the wall

Applications:

Ethical boundary: The line in the sand disciplines the company's bets, not individuals — turning the OMTM into personal quotas invites gaming and hides truth.

See references/omtm.md when choosing or rotating the OMTM, pairing a counter-metric, or drawing the line in the sand — the six-step selection procedure, the 6x3 stage x model matrix, a 7-row counter-metric gaming table, line-in-the-sand and rotation-trigger rules, and three worked examples.

3. Metrics by Business Model

Core concept: Your business model dictates which metrics exist and which matter. Lean Analytics defines six archetypes — e-commerce, SaaS, free mobile app, media site, user-generated content, and two-sided marketplace — each with its own metric tree and its own definition of "working."

Why it works: Copying another company's north star fails because metrics encode the mechanics of a model: a marketplace lives or dies on liquidity, a SaaS business on churn, a media site on engaged attention. Naming your model first turns "what should we measure?" from a brainstorm into a lookup.

Key insights:

  • E-commerce runs on conversion rate, average order value, and repurchase rate — annual repurchase under ~40% means acquisition mode, over ~60% loyalty mode, and each mode has a different playbook
  • SaaS runs on MRR, churn, LTV:CAC, expansion, and time-to-value; free mobile apps run on downloads → DAU/MAU, percent paying, and ARPDAU vs ARPPU (whales skew every average)
  • Media runs on audience, engaged time (not raw pageviews), CTR, and RPM; UGC runs on the engagement funnel — visitor → voyeur → commenter → creator — plus content per user and spam rate
  • Marketplaces run on liquidity: listings, fill/sell-through rate, time-to-transaction, take rate, buyer/seller ratio — GMV is vanity until multiplied by take rate
  • Hybrid businesses must pick ONE primary model to own the OMTM; the secondary model contributes counter-metrics, not equal billing
  • The model also dictates instrumentation: define each metric's formula and source up front, or every team computes "churn" differently

Applications:

See references/business-model-metrics.md when instrumenting a product or picking a model's canonical ratios — metric trees for all six models with formulas, instrumentation notes, measurement failure modes, and hybrid-model guidance.

4. Metrics by Stage: The Lean Analytics Stages

Core concept: Startups move through five stages — Empathy, Stickiness, Virality, Revenue, Scale — and each has a gate. The OMTM is the intersection of business model and current stage; working on a later stage's metric before passing the current gate is the canonical startup mistake.

Why it works: Sequencing prevents waste. Virality poured into a product that doesn't retain is a leaky bucket; paid acquisition before unit economics burns runway with precision. Each gate de-risks the next, larger investment of money and time.

Key insights:

  • Empathy: have 15+ problem interviews shown a painful, frequent problem people will pay to fix? The metric is mostly conversation notes — and that's correct at this stage
  • Stickiness: do people use it repeatedly on their own? Track retention cohorts and core-action engagement; don't pour users into a leaky bucket
  • Virality: do users bring users? Track viral coefficient AND cycle time — shortening the cycle often grows you faster than raising the coefficient, and inherent virality beats incentivized invites
  • Revenue: does a dollar in return more than a dollar out, soon enough? Revenue per customer, CAC payback, gross margin
  • Scale: channels, partners, and new markets — metrics shift from product risk to ecosystem and operations
  • Gates are evidence, not time: a flattening retention curve exits Stickiness; positive unit economics within payback tolerance exits Revenue

Applications:

See references/five-stages.md when locating your stage or deciding whether you've passed a gate — the per-stage playbook with gating metrics, exit-criteria checklists, premature-scaling symptoms, and funding/runway interactions.

5. Baselines and Lines in the Sand

Core concept: A metric without a target is trivia. Use published baselines as starting heuristics — not laws — to define "good enough," then draw your line in the sand: a number, a date, and a pre-committed action if you miss.

Why it works: Baselines convert open-ended measurement into falsifiable bets. Knowing that ~5% monthly churn is the early-SaaS ceiling tells you whether to optimize or rebuild; without a line, every result can be rationalized and no experiment can fail.

Key insights:

  • Early SaaS: ~5% monthly customer churn is the upper bound of viable; healthy companies push toward ~2% or lower
  • Habitual and social apps: DAU/MAU around 20%+ signals real engagement; casual mobile apps average roughly 14% day-30 retention, so plan for steep decay
  • Conversion: e-commerce typically converts ~1-3% of visitors; landing pages on good paid traffic usually convert low single digits — 25-30% is exceptional, not a planning number
  • A viral coefficient above 1 is rare and fleeting; treat virality as CAC reduction and optimize cycle time before coefficient
  • No benchmark for your case? Measure your current value, improve relative to it, and watch the derivative — 5% weekly improvement compounds into category-leading numbers
  • Benchmarks shift by market, channel, price point, and era — always re-derive against your own cohorts before adopting someone else's number

Applications:

See references/case-studies.md when you want a full worked walkthrough — three scenarios: SaaS dashboard to OMTM, marketplace liquidity discovery, and a mobile app fixing stickiness before growth.

Common Mistakes

Quick Diagnostic

Further Reading

  • "Lean Analytics: Use Data to Build a Better Startup Faster" by Alistair Croll & Benjamin Yoskovitz
  • "The Lean Startup" by Eric Ries
  • "Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing" by Ron Kohavi, Diane Tang & Ya Xu

About the Authors

Alistair Croll is an entrepreneur and analyst who co-founded web performance company Coradiant, founded Solve For Interesting, and chairs Startupfest among other technology conferences. Benjamin Yoskovitz is a founding partner at venture studio Highline Beta and a serial founder and startup investor. They wrote Lean Analytics for Eric Ries's Lean Series.

More skills from wondelai/skills

  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

All agent skills → · MCP servers