TODO — make this yours. This is a generic starting template. Edit it to fit your own product operation: your PRD template and requirements bar, your prioritization framework, your roadmap format and cadence, and your metrics/OKR stack. Delete what you don't use.

Product Management Skill

Feature Specs & PRDs

PRD Structure

• Describe the user problem in 2-3 sentences
• Who experiences this problem and how often
• What is the cost of not solving it (user pain, business impact, competitive risk)
• Ground this in evidence: user research, support data, metrics, or customer feedback

• 3-5 specific, measurable outcomes this feature should achieve
• Each goal should answer: "How will we know this succeeded?"
• Distinguish between user goals (what users get) and business goals (what the company gets)
• Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")

• 3-5 things this feature explicitly will NOT do
• Adjacent capabilities that are out of scope for this version
• For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
• Non-goals prevent scope creep during implementation and set expectations with stakeholders

• The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
• The capability should describe what they want to accomplish, not how
• The benefit should explain the "why" — what value does this deliver
• Include edge cases: error states, empty states, boundary conditions
• Include different user types if the feature serves multiple personas
• Order by priority — most important stories first

• "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
• "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
• "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"

• Must-Have (P0): The feature cannot ship without these — the minimum viable version. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.
• Nice-to-Have (P1): Significantly improves the experience but the core use case works without them. Often become fast follow-ups after launch.
• Future Considerations (P2): Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.

• Questions that need answers before or during implementation
• Tag each with who should answer (engineering, design, legal, data, stakeholder)
• Distinguish blocking questions (must answer before starting) from non-blocking (can resolve during implementation)

• Hard deadlines (contractual commitments, events, compliance dates)
• Dependencies on other teams' work or releases
• Suggested phasing if the feature is too large for one release

User Story Writing

• Too vague: "As a user, I want the product to be faster" — what specifically should be faster?
• Solution-prescriptive: "As a user, I want a dropdown menu" — describe the need, not the UI widget
• No benefit: "As a user, I want to click a button" — why? What does it accomplish?
• Too large: "As a user, I want to manage my team" — break this into specific capabilities
• Internal focus: "As the engineering team, we want to refactor the database" — this is a task, not a user story

Requirements Categorization — MoSCoW

• Must have: Without these, the feature is not viable. Non-negotiable.
• Should have: Important but not critical for launch. High-priority fast follows.
• Could have: Desirable if time permits. Will not delay delivery if cut.
• Won't have (this time): Explicitly out of scope. May revisit in future versions.

Acceptance Criteria

• Given [precondition or context]
• When [action the user takes]
• Then [expected outcome]

• Admin can enter SSO provider URL in organization settings
• Team members see "Log in with SSO" button on login page
• SSO login creates a new account if one does not exist
• SSO login links to existing account if email matches
• Failed SSO attempts show a clear error message

Scope Management

• Write explicit non-goals in every spec
• Require that any scope addition comes with a scope removal or timeline extension
• Separate "v1" from "v2" clearly in the spec
• Review the spec against the original problem statement — does everything serve it?
• Time-box investigations: "If we cannot figure out X in 2 days, we cut it"
• Create a "parking lot" for good ideas that are not in scope

Roadmap Planning & Prioritization

Roadmap Formats

• Now (current sprint/month): Committed work, high confidence in scope and timeline.
• Next (next 1-3 months): Planned, scoped, and prioritized but not yet started.
• Later (3-6+ months): Directional strategic bets; scope and timing are flexible. Use for most teams, most of the time — especially external/leadership communication, since it avoids false precision on dates.

Prioritization Frameworks

• Reach: concrete number of users/customers affected in a period (e.g., "500 users/quarter")
• Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
• Confidence: 100% = high (data-backed), 80% = medium (some evidence), 50% = low (gut feel)
• Effort: person-months across engineering, design, and other functions Use for quantitative, defensible prioritization across a large backlog; less good for strategic bets where impact is hard to estimate.

• High value / Low effort: Quick wins — do these first.
• High value / High effort: Big bets — plan carefully, worth the investment.
• Low value / Low effort: Fill-ins — do when there's spare capacity.
• Low value / High effort: Money pits — do not do these. Good for visual prioritization in team planning sessions and building shared understanding of tradeoffs.

Dependency Mapping

Capacity Planning

• 70% planned features — roadmap items advancing strategic goals
• 20% technical health — tech debt, reliability, performance, DX
• 10% unplanned — buffer for urgent issues, quick wins, cross-team requests

Communicating Roadmap Changes

1. Acknowledge the change directly
2. Explain the reason — what new information drove this decision
3. Show the tradeoff — what got deprioritized or is slipping
4. Show the new plan
5. Acknowledge impact — tell affected stakeholders directly, don't let them find out secondhand

Metrics & Tracking

Product Metrics Hierarchy

• Acquisition: new signups/trial starts, signup conversion rate, channel mix, cost per acquisition
• Activation: activation rate, time to activate, setup completion rate, first value moment
• Engagement: DAU/WAU/MAU, DAU/MAU stickiness ratio, core action frequency, session depth, feature adoption
• Retention: D1/D7/D30 retention, cohort retention curves, churn rate, resurrection rate
• Monetization: free-to-paid conversion, MRR/ARR, ARPU/ARPA, expansion revenue, net revenue retention
• Satisfaction: NPS, CSAT, support ticket volume/resolution time, app store ratings/sentiment

Common Product Metrics

Goal Setting — OKRs

Objective: Make our product indispensable for daily workflows

Key Results:
- Increase DAU/MAU ratio from 0.35 to 0.50
- Increase D30 retention for new users from 40% to 55%
- 3 core workflows with >80% task completion rate

Metric Review Cadences

• Weekly (15-30 min, PM + eng lead): North Star WoW change, key L1 movements, active experiments, anomalies, alerts. Investigate anything that looks off.
• Monthly (30-60 min, product team + key stakeholders): full L1 scorecard with MoM trends, progress vs quarterly OKRs, cohort analysis, recent-launch adoption, segment divergence. Identify 1-3 areas to invest in.
• Quarterly Business Review (60-90 min, product/eng/design/leadership): OKR scoring, quarter-long trend analysis, YoY comparisons, competitive context. Set next quarter's OKRs and adjust strategy.

Dashboard Design

Stakeholder Communication

Update Templates by Audience

Status: [Green / Yellow / Red]
TL;DR: [One sentence — the most important thing to know]
Progress:
- [Outcome achieved, tied to goal/OKR]
- [Milestone reached, with impact]
- [Key metric movement]
Risks:
- [Risk]: [Mitigation plan]. [Ask if needed].
Decisions needed:
- [Decision]: [Options with recommendation]. Need by [date].
Next milestones:
- [Milestone] — [Date]

Shipped:
- [Feature/fix] — [Link to PR/ticket]. [Impact if notable].
In progress:
- [Item] — [Owner]. [Expected completion]. [Blockers if any].
Decisions:
- [Decision made]: [Rationale]. [Link to ADR if exists].
- [Decision needed]: [Context]. [Options]. [Recommendation].
Priority changes:
- [What changed and why]
Coming up:
- [Next items] — [Context on why these are next]

What's coming:
- [Feature/launch] — [Date]. [What this means for your team].
What we need from you:
- [Specific ask] — [Context]. By [date].
Decisions made:
- [Decision] — [How it affects your team].
Open for input:
- [Topic we'd love feedback on] — [How to provide it].

What's new:
- [Feature] — [Benefit in customer terms]. [How to use it / link].
Coming soon:
- [Feature] — [Expected timing]. [Why it matters to you].
Known issues:
- [Issue] — [Status]. [Workaround if available].
Feedback:
- [How to share feedback or request features]

Status Reporting — Green / Yellow / Red

• Green (On Track): progressing as planned, no significant risks/blockers, on track for commitments. Use only when genuinely true, not as a default.
• Yellow (At Risk): slower than planned or a risk has materialized; mitigation underway but outcome uncertain; may miss commitments without intervention. Flag proactively — the earlier, the more options you have.
• Red (Off Track): significantly behind, major blocker without clear mitigation, will miss commitments without significant intervention. Use when you genuinely need help — don't wait until it's too late.

Risk Communication — ROAM

• Resolved: no longer a concern — document how.
• Owned: acknowledged, someone actively managing it — state owner and mitigation plan.
• Accepted: known, proceeding without mitigation — document the rationale.
• Mitigated: actions have reduced it to an acceptable level — document what was done.

Decision Documentation (ADRs)

# [Decision Title]

## Status
[Proposed / Accepted / Deprecated / Superseded by ADR-XXX]

## Context
What is the situation that requires a decision? What forces are at play?

## Decision
What did we decide? State the decision clearly and directly.

## Consequences
What are the implications of this decision?
- Positive consequences
- Negative consequences or tradeoffs accepted
- What this enables or prevents in the future

## Alternatives Considered
What other options were evaluated?
For each: what was it, why was it rejected?

Meeting Facilitation

User Research Synthesis

Research Synthesis Methodology

1. Familiarization — read through all data before coding
2. Initial coding — tag observations/quotes with descriptive codes; be generous, easier to merge than split later
3. Theme development — group related codes into candidate themes
4. Theme review — check each theme has sufficient evidence, themes are distinct, and together tell a coherent story
5. Theme refinement — define and name each theme with a 1-2 sentence description
6. Report — write up themes as findings with supporting evidence

1. Capture each distinct observation/quote/data point as a separate note
2. Cluster related notes by similarity — let categories emerge, don't pre-define them
3. Label each cluster with a descriptive name
4. Organize clusters into higher-level groups if patterns emerge
5. Identify themes from the clusters and their relationships

• Methodological: same question, different methods (interviews + survey + analytics)
• Source: same method, different participants/segments
• Temporal: same observation at different points in time

Interview Note Analysis

• Observations: what the participant described doing, experiencing, feeling. Distinguish behaviors from attitudes; note context (when/where/with whom/how often); flag workarounds — these are unmet needs in disguise.
• Direct quotes: specific, vivid verbatim statements. Attribute to participant type, not name ("Enterprise admin, 200-person team", not "Sarah"). A quote is evidence, not a finding — the finding is your interpretation.
• Behaviors vs stated preferences: what people DO often differs from what they SAY. Behavioral observations are stronger evidence. Note contradictions between stated wants and actual workflow.
• Signals of intensity: emotional language, frequency of the issue, effort spent on workarounds, consequence when things go wrong.

Survey Data Interpretation

Combining Qualitative and Quantitative

Persona Development

1. Identify behavioral patterns — clusters of similar behaviors, goals, contexts
2. Define distinguishing variables (company size, technical skill, usage frequency, primary use case)
3. Create a profile per cluster (see template below)
4. Validate — can you size each persona segment with quantitative data?

[Persona Name] — [One-line description]

Who they are:
- Role, company type/size, experience level
- How they found/started using the product

What they are trying to accomplish:
- Primary goals and jobs to be done
- How they measure success

How they use the product:
- Frequency and depth of usage
- Key workflows and features used
- Tools they use alongside this product

Key pain points:
- Top 3 frustrations or unmet needs
- Workarounds they have developed

What they value:
- What matters most in a solution
- What would make them switch or churn

Representative quotes:
- 2-3 verbatim quotes that capture this persona's perspective

Opportunity Sizing

• Impact = (Users affected) x (Frequency) x (Severity)
• Evidence strength (multiple sources > single source, behavioral data > stated preferences)
• Strategic alignment with company vision
• Feasibility (technical, resource, time to impact)