| name | pm-analytics |
| description | Measurement and operations workflow - metrics, financial modeling, data-driven decisions, platform ops, and design systems |
| triggers | ["metrics","financial model","dashboard","data-driven","analytics","KPI","unit economics","cohort analysis","platform","design system","tech debt","product operations","AI evaluation","evals"] |
PM Analytics: Measure What Matters
Analytics turns intuition into evidence. This module covers metrics design, financial modeling, data-driven decision-making, and the operational infrastructure that keeps products healthy.
When to Use This Module
- Defining metrics for a new product/feature
- Building financial models or unit economics
- Setting up dashboards and review cadences
- Evaluating technical investments (platform, tech debt)
- Running data-informed product reviews
Workflow Overview
Define Metrics → Build Dashboards → Review Cadence → Financial Model → Platform Health → Iterate
Skills
1. Product Operations
Context: Product ops builds the systems that make product teams effective — data pipelines, review cadences, tooling, and processes.
Framework — Product Ops Pillars:
- Data infrastructure: Ensure teams can self-serve data (event tracking, dashboards, analysis tools)
- Review cadence: Weekly metrics review, monthly business review, quarterly strategy review
- Process standardization: Templates, launch processes, feedback loops
- Tooling: Evaluate and maintain product tools (analytics, A/B testing, feature flags)
- Knowledge management: Document decisions, experiments, learnings
2. Metrics Tree Methodology
Context: A metrics tree connects your north star to actionable team-level metrics. It's the translation layer between strategy and execution.
Framework — Building a Metrics Tree:
- North Star (top): The one metric that captures core value (see pm-strategy)
- Input Metrics (level 2): 3-5 metrics that mathematically or causally drive the north star
- Team Metrics (level 3): Metrics each team owns and can directly influence
- Leading Indicators (level 4): Early signals that team metrics will move
Example:
North Star: Weekly Active Users
├── New Users (Acquisition team)
│ ├── Signups
│ └── Signup-to-activation rate
├── Returning Users (Engagement team)
│ ├── D7 retention
│ └── Feature adoption rate
└── Resurrected Users (Lifecycle team)
├── Reactivation email CTR
└── Winback conversion rate
Template: See metrics-dashboard
3. Financial Modeling
Context: PMs need financial literacy to make business cases, evaluate pricing, and communicate with leadership.
Framework — PM Financial Model:
- Revenue model: How do you make money? (subscription, transaction, ads, marketplace take-rate)
- Unit economics: CAC, LTV, LTV/CAC ratio, payback period, gross margin
- Cohort projections: Revenue by signup cohort over time
- Scenario analysis: Best/base/worst case with key variable sensitivities
- TAM/SAM/SOM: Top-down market sizing + bottom-up reality check
Key Formulas:
- LTV = ARPU × (1 / Churn Rate)
- CAC Payback = CAC / (ARPU × Gross Margin)
- LTV/CAC > 3x is healthy
- Rule of 40: Growth Rate + Profit Margin > 40% (SaaS benchmark)
Template: See financial-model-spec
For spreadsheet creation: Use the xlsx skill at ../../office/skills/xlsx/SKILL.md for formula construction, formatting standards, and Excel best practices.
4. Data-Driven Decision Making
Context: Data informs decisions; it doesn't make them. Know when to use data and when to use judgment.
Framework — Data-Decision Spectrum:
| Signal Strength | Approach |
|---|
| Strong data (A/B test, large sample) | Let data decide |
| Moderate data (analytics, surveys) | Data-informed, judgment calls on ties |
| Weak data (anecdotes, small sample) | Use as input, decide on principles |
| No data (new market, novel product) | Conviction + fast iteration |
Data Review Cadence:
- Daily: Core metrics dashboard (anomaly detection)
- Weekly: Team metrics review (progress against OKRs)
- Monthly: Business review (revenue, growth, retention cohorts)
- Quarterly: Strategy review (are we working on the right things?)
5. Technical Roadmaps
Context: PMs must balance feature work with technical investment. Ignoring tech debt compounds until it blocks everything.
Framework — Tech Investment Portfolio:
- Features (60-70%): User-facing capabilities that drive metrics
- Tech debt (15-20%): Performance, reliability, maintainability improvements
- Platform (10-15%): Shared infrastructure that accelerates future feature work
- Exploration (5-10%): Prototypes, spikes, research
Tech Debt Prioritization:
- Prioritize debt that slows down the highest-priority feature work
- Measure in "developer time tax" — how many hours per week does this cost?
- Create a tech debt backlog with estimated ROI (hours saved / hours to fix)
6. Managing Tech Debt
Context: Tech debt is a business decision, not an engineering failure. Manage it like financial debt — take it on deliberately, pay it down strategically.
Framework:
- Categorize: Is it deliberate (speed trade-off) or accidental (unknown at the time)?
- Quantify: How much does it cost per sprint in velocity? In incidents?
- Prioritize: Address debt that blocks upcoming feature work first
- Allocate: Reserve 15-20% of sprint capacity for debt reduction
- Track: Maintain a debt register with interest rate (growing cost over time)
7. Platform & Infrastructure
Context: When 3+ teams need the same capability, it's time to invest in platform.
Framework — Platform Decision Matrix:
- Build platform when: multiple teams blocked, shared pattern emerging, total cost of separate implementations > platform cost
- Don't build platform when: only one team needs it, requirements are too different, premature abstraction
8. Design Systems
Context: Design systems are a product, not a project. They reduce per-feature cost and improve consistency.
Framework:
- Start with an audit of existing patterns (buttons, forms, typography, colors)
- Define tokens: spacing, color palette, typography scale
- Build components: start with the 10 most-used components
- Document: usage guidelines, do/don't examples
- Maintain: designate an owner, accept contributions via PR review
9. AI Evaluation (Evals)
Context: AI products require different measurement. Traditional A/B testing is necessary but not sufficient.
Framework — Eval Design for AI Products:
- Define quality dimensions: Accuracy, relevance, safety, latency, cost
- Build eval sets: Curated input/output pairs with human-labeled quality scores
- Automate measurement: Run evals on every model change (CI for models)
- Track regression: Alert when quality drops below threshold
- Human-in-the-loop: Sample outputs for human review at regular intervals
Module Checklist
Related Modules
- For metric goal-setting: pm-strategy
- For growth metrics: pm-growth
- For financial spreadsheet execution: xlsx skill at
../../office/skills/xlsx/SKILL.md
