analytics-insights
Deep dive into product analytics — investigate a question, surface insights, build a data narrative. Use when you need to go beyond dashboards to understand…
Define an epic with strategic context, feature breakdown, milestones, and success metrics. Use when scoping a large body of work for planning and tracking.
$ npx -y skills add mrthames/lean-pm-skills --skill epic-definition --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/epic-definitionContext preview
The summary Claude sees to decide when to auto-load this skill.
Define an epic with strategic context, feature breakdown, milestones, and success metrics. Use when scoping a large body of work for planning and tracking.
name: epic-definition description: Define an epic with strategic context, feature breakdown, milestones, and success metrics. Use when scoping a large body of work for planning and tracking.
Structure a well-defined epic in about an hour — strategic context, feature decomposition, milestones, dependencies, and success metrics. Claude handles the structuring and completeness checks. You provide the strategic intent and make the scoping calls.
| Step | Time | Claude Does | You Do | |---|---|---|---| | Strategic framing | 10 min | Structure the objective, key result, and theme | Confirm alignment to company goals | | Feature decomposition | 20 min | Break the epic into features with descriptions and owners | Validate completeness, cut scope | | Success metrics | 10 min | Propose outcome metrics and guardrails | Confirm baselines and targets | | Dependencies & risks | 10 min | Map cross-team dependencies and risk profile | Add political and organizational context | | Timeline & milestones | 10 min | Propose phased milestones with feature groupings | Validate with engineering leads |
Every epic exists to serve a goal. If you can't connect the epic to a company objective, question whether it belongs on the roadmap.
I need to define an epic for [body of work]. Strategic context: - Objective: [what this epic achieves — tied to a company or product goal] - Key result it drives: [measurable outcome — e.g., "Reduce onboarding drop-off from 40% to 25%"] - Theme: [product pillar — e.g., Growth, Retention, Platform, Compliance] Problem it addresses: - [The user or business problem, grounded in evidence] Evidence: - [Data point 1 — source, date] - [Data point 2] Help me frame this as a tight epic description — one paragraph that any stakeholder could read and understand why we're investing in this.
Break the epic into independently deliverable features. Each feature should be meaningful on its own — not just a task.
Break this epic into features: For each feature: - Name and one-line description - Why it's included (what problem it solves within the epic) - Status: Not Started | In Design | In Development | Complete - Owner: [name or team] - Rough size: S / M / L - Can it ship independently? (yes = good feature boundary) Then: - What's explicitly out of scope for this epic? - Are any features dependent on each other? (must Feature A ship before Feature B?) - Which feature delivers the most value fastest? (candidate for first delivery)
Define success metrics for this epic: | Metric | Target | Baseline | Measurement Method | |---|---|---|---| | [Primary outcome metric] | [target] | [current] | [how measured] | | [Secondary metric] | [target] | [current] | [how measured] | | [Guardrail — must not degrade] | [threshold] | [current] | [how measured] | How do we know this epic succeeded vs. just shipped? What's our evaluation timeline after the last feature ships?
Map dependencies and risks for this epic: Dependencies: | Dependency | Team/System | Status | Needed By | |---|---|---|---| | [What we need] | [from whom] | [resolved/pending] | [date] | Risks: | Risk | Likelihood | Impact | Mitigation | |---|---|---|---| | [What could go wrong] | [H/M/L] | [H/M/L] | [What we'd do] | Flag any dependency that is unresolved and could block the first milestone.
Propose a phased timeline for this epic: | Milestone | Target Date | Features Included | What's Demoable | |---|---|---|---| | [e.g., "Design complete"] | [Date] | [Features 1-2] | [What stakeholders can see] | | [e.g., "Beta launch"] | [Date] | [Feature 1] | [What users can do] | | [e.g., "GA launch"] | [Date] | [All features] | [Full experience] | For each milestone: what's the minimum viable deliverable? Which milestone de-risks the most uncertainty?
1. **Epics without outcomes.** "Build notification system" is an output. "Reduce notification-driven churn by 15%" is an outcome. Tie the epic to a measurable result. 2. **Features that can't ship alone.** If a feature only makes sense when combined with three other features, it's not a feature — it's a task. Redraw the boundaries. 3. **No explicit scope boundary.** An epic without an out-of-scope section will grow until it collapses under its own weight. Define the edges early. 4. **Missing the first deliverable.** If the first milestone is 8 weeks away, the epic is too big or the milestones aren't granular enough. Aim for something demoable within 2 weeks. 5. **Orphan epics.** An epic that doesn't connect to an OKR or company goal will lose priority the moment something urgent arrives. Anchor it.
AI-native product management skills that move at the speed your team needs. Traditional PM frameworks were built for a world without AI — multi-week discovery sprints, day-long planning offsites, months of analysis before a decision.
Deep dive into product analytics — investigate a question, surface insights, build a data narrative. Use when you need to go beyond dashboards to understand…
Evaluate whether to build in-house, buy a vendor solution, or partner. Use when facing a make-or-buy decision for a capability.
Build a complete business case for a product investment — strategic rationale, financial model, risk assessment, and recommendation. Use when you need…
Assess and respond to a competitor move within 24-48 hours. Use when a competitor launches, changes pricing, or makes a strategic shift.
Run a compressed 5-day product discovery cycle. Use when validating whether a problem is worth solving before committing engineering resources.
Design and run lean experiments — hypothesis, cheapest test, success criteria, decision. Use when you need to validate before you build.