When priorities compete for the roadmap, /product-manager scores and sequences work, so you can ship what matters first. — Claude Skill

---

title: Section Organization

1. Roadmap Strategy (roadmap)

Impact: CRITICAL Description: Creating, maintaining, and communicating roadmaps at all levels. Foundation of product planning that aligns teams and stakeholders.

2. Prioritization Frameworks (prioritization)

Impact: CRITICAL Description: RICE, ICE, MoSCoW, and other frameworks for making data-informed decisions about what to build next.

3. Stakeholder Management (stakeholder)

Impact: HIGH Description: Managing expectations, communicating effectively, and building alignment across executives, engineering, sales, and customers.

4. Sprint & Backlog (sprint)

Impact: HIGH Description: Sprint planning, backlog grooming, estimation, and agile ceremonies that keep teams productive.

5. Feature Scoping (scoping)

Impact: HIGH Description: Defining MVP, making trade-offs, writing specs, and managing scope creep.

6. Release Planning (release)

Impact: MEDIUM-HIGH Description: Coordinating releases, managing dependencies, and communicating timelines.

7. Metrics & OKRs (metrics)

Impact: CRITICAL Description: Defining success metrics, setting OKRs, and measuring outcomes over outputs.

8. Technical Debt (debt)

Impact: MEDIUM-HIGH Description: Balancing feature work with technical health, prioritizing debt reduction, and communicating value.

---

title: Cross-Functional Collaboration impact: HIGH tags: collaboration, teamwork, design, engineering, communication

Cross-Functional Collaboration

Impact: HIGH

PMs don't build products — teams do. Your job is to create the conditions for teams to do their best work together.

The Product Trio Model

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│                      ┌─────────────┐                            │
│                      │   PRODUCT   │                            │
│                      │   MANAGER   │                            │
│                      └──────┬──────┘                            │
│                             │                                   │
│              Discovery ─────┼───── Delivery                     │
│                             │                                   │
│             ┌───────────────┴───────────────┐                   │
│             │                               │                   │
│      ┌──────┴──────┐                 ┌──────┴──────┐            │
│      │   PRODUCT   │                 │ ENGINEERING │            │
│      │   DESIGNER  │◄───────────────▶│    LEAD     │            │
│      └─────────────┘                 └─────────────┘            │
│                                                                 │
│                     Shared ownership of                         │
│                   problems AND solutions                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

RACI for Common Activities

Legend: R=Responsible, A=Accountable, C=Consulted, I=Informed

Working with Engineering

What engineers need from PMs:

What PMs need from engineers:

Working with Design

What designers need from PMs:

What PMs need from designers:

Product Trio Rituals

Healthy vs Unhealthy Team Dynamics

Managing Conflict Productively

Conflict Resolution Framework:

1. ACKNOWLEDGE
   "I see we have different views on this."

2. UNDERSTAND
   "Help me understand your perspective better."

3. FIND COMMON GROUND
   "We both want [shared goal]. Let's start there."

4. GENERATE OPTIONS
   "What are all the ways we could approach this?"

5. DECIDE TOGETHER
   "Given our constraints, I propose... What do you think?"

6. COMMIT
   "Let's all support this decision once made."

Cross-Functional Meeting Templates

Discovery Kickoff:

## Discovery Kickoff: [Problem Area]

### Attendees
Product Trio + [other relevant stakeholders]

### Agenda

1. Problem framing (10 min)
   - What problem are we solving?
   - Who has this problem?
   - Why does it matter now?

2. What we know (15 min)
   - Existing research
   - Quantitative data
   - Competitive landscape

3. What we don't know (10 min)
   - Open questions
   - Assumptions to validate

4. Discovery plan (20 min)
   - Research activities
   - Timeline
   - Owners

5. Success criteria (5 min)
   - How do we know we're ready to build?

Design Review:

## Design Review: [Feature]

### Attendees
Product Trio

### Agenda

1. Context refresh (5 min)
   - Problem we're solving
   - Constraints reminder

2. Design walkthrough (20 min)
   - Walk through solution
   - Explain rationale
   - Show alternatives considered

3. Feedback (20 min)
   - Questions for clarification
   - Constructive critique
   - Engineering feasibility check

4. Next steps (5 min)
   - Changes to make
   - Timeline for next review

Collaboration Patterns by Company Stage

Anti-Patterns

• Ticket tosser — PM writes specs, throws over wall
• Designer dictator — PM makes UX decisions
• Tech micromanager — PM specifies implementation
• Absent PM — Never available for questions
• Meeting multiplier — Everything needs a meeting
• Information hoarder — Context stays with PM
• Blame shifter — Points fingers when things fail
• Process zealot — Process over outcomes

---

title: Go-to-Market Coordination impact: MEDIUM-HIGH tags: gtm, launch, marketing, sales, coordination

Go-to-Market Coordination

Impact: MEDIUM-HIGH

Great products fail without great go-to-market. PMs must bridge product development with how features reach customers.

PM's Role in GTM

┌─────────────────────────────────────────────────────────────────┐
│                    PM GTM RESPONSIBILITIES                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   PRODUCT SIDE                     GTM SIDE                     │
│   ────────────                     ────────                     │
│   • What we're building            • Why it matters to users    │
│   • When it ships                  • How to position it         │
│   • Technical capabilities         • Target segments            │
│   • Known limitations              • Success metrics            │
│                                                                 │
│                      PM BRIDGES BOTH                            │
│                     (translates and aligns)                     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

GTM Planning by Launch Tier

GTM Launch Checklist by Tier

Tier 1 - Major Launch:

## Tier 1 GTM Checklist: [Feature Name]

### Positioning (PM + Marketing)
- [ ] Value proposition defined
- [ ] Target segments identified
- [ ] Competitive differentiation clear
- [ ] Messaging hierarchy approved

### Marketing Activities
- [ ] Launch blog post
- [ ] Email announcement (segmented)
- [ ] Social media campaign
- [ ] Press/analyst outreach
- [ ] Video/demo content
- [ ] Paid promotion (if applicable)

### Sales Enablement
- [ ] Sales deck updated
- [ ] Demo script created
- [ ] Competitive battle card
- [ ] FAQ document
- [ ] Training session completed
- [ ] Pricing/packaging confirmed

### Customer Success
- [ ] Existing customer communication
- [ ] Onboarding materials updated
- [ ] Success metrics defined
- [ ] Escalation path ready

### Product
- [ ] Help documentation
- [ ] In-app announcement
- [ ] Feature flags configured
- [ ] Analytics tracking live

### Timeline
| Milestone | Date | Owner |
|-----------|------|-------|
| Messaging approved | T-3w | Marketing |
| Sales training | T-2w | PM + Sales |
| Content ready | T-1w | Marketing |
| Launch | T | All |

Tier 2/3 - Standard Launch:

## Tier 2/3 GTM Checklist: [Feature Name]

### Required
- [ ] Changelog entry
- [ ] Help docs updated
- [ ] In-app notification (if applicable)
- [ ] Support team informed

### Optional (Tier 2 only)
- [ ] Blog post
- [ ] Email to relevant segment
- [ ] Sales enablement brief

Launch Brief Template

## Launch Brief: [Feature Name]

### Overview
| Field | Detail |
|-------|--------|
| Launch Date | [Date] |
| Launch Tier | [1/2/3/4] |
| PM Owner | [Name] |
| Marketing Owner | [Name] |

### What We're Launching
[2-3 sentences describing the feature]

### Why It Matters
**For users:** [Problem solved, value delivered]
**For business:** [Revenue, retention, expansion impact]

### Target Audience
**Primary:** [Segment, persona]
**Secondary:** [Segment, persona]

### Key Messages
1. [Main message/headline]
2. [Supporting point 1]
3. [Supporting point 2]

### Competitive Context
[How this positions us vs competitors]

### Limitations / What This Isn't
- [Known limitation 1]
- [Known limitation 2]
- [What we're NOT launching yet]

### Success Metrics
| Metric | Target | Timeframe |
|--------|--------|-----------|
| [Metric 1] | [Target] | 30 days |
| [Metric 2] | [Target] | 90 days |

### Resources
- Product spec: [link]
- Design files: [link]
- Demo recording: [link]
- Help docs: [link]

Coordinating with Marketing

Timing alignment:

Product Development          Marketing Prep
─────────────────────        ──────────────

Feature defined ─────────────► Start messaging work

Development start ───────────► Content planning

Beta launch ─────────────────► Draft content, collect feedback

Code complete ───────────────► Finalize content, prep campaigns

Ship ────────────────────────► Launch campaigns

Coordinating with Sales

Sales enablement session agenda:

## Sales Enablement: [Feature Name]

### Agenda (45 min)

1. Overview (10 min)
   - What we built
   - Why it matters
   - Who it's for

2. Demo (15 min)
   - Live walkthrough
   - Key workflows
   - Wow moments

3. Selling guide (10 min)
   - Ideal customer profile
   - Discovery questions
   - Competitive positioning
   - Pricing and packaging

4. Q&A (10 min)
   - Open questions
   - Objection handling
   - Edge cases

Customer Communication Hierarchy

Handling Launch Delays

## Launch Delay Communication

### Internal (to stakeholders)

Subject: [Feature] launch moving to [New Date]

**What changed:** [Brief explanation]

**Impact:**
- Marketing: [Adjust campaign dates]
- Sales: [Update customer expectations]
- Support: [Shift training]

**New timeline:** [Date]

**What we need:** [Any decisions or actions]

---

### External (if promised to customers)

Subject: Update on [Feature]

We wanted to let you know that [Feature] will launch on
[New Date] instead of [Original Date].

We made this decision to [brief reason that benefits them].

In the meantime, here's what you can do: [workaround or interim solution]

Thank you for your patience. We're excited to deliver this
to you soon.

Post-Launch GTM Activities

Anti-Patterns

• Ship and forget — Launching without GTM plan
• Marketing surprise — "Oh, we're launching tomorrow?"
• Over-promising — Marketing claims beyond capability
• Under-communicating — Internal teams learn from customers
• One-size-fits-all — Same GTM for every feature
• PM as marketer — Writing all the copy yourself
• Sales blindside — Customers know before sales team
• No feedback loop — Not measuring GTM effectiveness

---

title: Product Metrics and OKRs impact: CRITICAL tags: metrics, okrs, kpis, measurement, outcomes

Product Metrics and OKRs

Impact: CRITICAL

What you measure defines what you build. Great PMs obsess over outcomes, not outputs.

Metrics Hierarchy

┌─────────────────────────────────────────────────────────────────┐
│                    NORTH STAR METRIC                            │
│              (One metric that captures value)                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│    │   INPUT      │  │   INPUT      │  │   INPUT      │        │
│    │   METRIC 1   │  │   METRIC 2   │  │   METRIC 3   │        │
│    └──────────────┘  └──────────────┘  └──────────────┘        │
│                                                                 │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│    │   GUARDRAIL  │  │   GUARDRAIL  │  │   GUARDRAIL  │        │
│    │   METRIC 1   │  │   METRIC 2   │  │   METRIC 3   │        │
│    └──────────────┘  └──────────────┘  └──────────────┘        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

North Star Metric Examples

Input vs Output vs Outcome Metrics

Always optimize for outcomes, not outputs.

AARRR Pirate Metrics Framework

Good OKRs Example

## Q1 2024 OKRs - Product Team

### Objective 1: Dramatically improve new user activation
**Why:** 60% of users never experience core value; biggest growth lever

**Key Results:**
- KR1: Increase activation rate from 23% to 35%
  - Measurement: Users completing first workflow within 7 days
  - Current: 23% | Target: 35%

- KR2: Reduce time-to-first-value from 3 days to 1 day
  - Measurement: Median time to first successful workflow
  - Current: 72 hours | Target: 24 hours

- KR3: Achieve 50+ NPS for users in first 30 days
  - Measurement: NPS survey at day 30
  - Current: 32 | Target: 50

**Initiatives:**
- Onboarding flow redesign
- Template library expansion
- In-app guidance system

**Guardrails:**
- Support ticket volume: maintain < 5% increase
- Infrastructure cost: no increase > 10%

Bad OKRs Example

## Q1 OKRs

### Objective 1: Ship new features
**Key Results:**
- Ship dark mode
- Launch mobile app
- Add 10 integrations
- Redesign dashboard

### Objective 2: Make customers happy
**Key Results:**
- Get more feedback
- Fix bugs
- Improve performance

Why this fails:

• Output-focused, not outcome-focused
• No measurable targets
• No baseline or current state
• No connection to business value
• No guardrails

OKR Writing Guidelines

Good Objective:

• Qualitative and inspirational
• Time-bound (quarterly)
• Ambitious but achievable
• Team-aligned

Good Key Results:

• Quantitative and measurable
• Outcome-focused (not output)
• 3-5 per objective
• Include baseline and target
• Challenging but possible (70% confidence)

Metric Definition Template

## Metric: Activation Rate

### Definition
Percentage of new signups who complete their first successful
workflow within 7 days of registration.

### Formula
(Users with completed workflow in first 7 days / Total new signups) × 100

### Data Source
- Numerator: events.workflow_completed WHERE days_since_signup <= 7
- Denominator: users.created_at in period

### Segmentation
- By signup source (organic, paid, referral)
- By plan type (free, trial, paid)
- By company size (SMB, mid-market, enterprise)

### Cadence
- Reported: Weekly
- Reviewed: Monthly

### Owner
Product Manager - Growth

### Targets
| Period | Target | Stretch |
|--------|--------|---------|
| Q1 2024 | 35% | 40% |
| Q2 2024 | 42% | 48% |

### Related Metrics
- Time-to-first-value (leading)
- 30-day retention (lagging)
- Onboarding completion (input)

Metrics Review Meeting Agenda

## Weekly Metrics Review - [Date]

### Attendees
Product, Engineering Lead, Data

### Agenda

#### 1. North Star Check (5 min)
- Current: [value]
- Trend: [up/down/flat]
- vs Target: [ahead/behind/on track]

#### 2. Key Result Progress (15 min)
| KR | Current | Target | Status |
|----|---------|--------|--------|
| Activation rate | 28% | 35% | On track |
| Time-to-value | 2 days | 1 day | At risk |
| NPS (new users) | 41 | 50 | On track |

#### 3. Guardrail Check (5 min)
| Guardrail | Status | Notes |
|-----------|--------|-------|
| Support volume | Green | +2% |
| Error rate | Green | 0.1% |
| Infrastructure cost | Yellow | +8% |

#### 4. Experiment Results (10 min)
- [Experiment A]: +3% activation, shipping
- [Experiment B]: No significant change, not shipping

#### 5. Insights & Actions (10 min)
- Key insight: [Finding]
- Action: [What we're doing about it]

### Decisions Made
- [Decision 1]
- [Decision 2]

### Next Week Focus
- [Priority 1]
- [Priority 2]

Common Metric Pitfalls

Anti-Patterns

• Feature counting — Measuring what you shipped, not impact
• Metric theater — Beautiful dashboards nobody uses
• Annual OKRs — Too long to learn and adapt
• Sandbagging — Setting easy targets to "hit" OKRs
• Set and forget — Not reviewing regularly
• Too many KRs — 10 key results per objective
• No accountability — OKRs without owners
• Input KRs — "Ship 5 features" as a key result

---

title: Prioritization Frameworks impact: CRITICAL tags: prioritization, rice, ice, moscow, decision-making

Prioritization Frameworks

Impact: CRITICAL

Prioritization is the PM's most important job. Use frameworks to make decisions transparent, defensible, and consistent.

Framework Selection Guide

RICE Framework (Detailed)

RICE Score = (Reach × Impact × Confidence) / Effort

RICE Example Calculation:

Winner: Onboarding redesign (highest RICE score)

ICE Framework (Quick Scoring)

ICE Score = Impact × Confidence × Ease

All factors scored 1-10:

• Impact: How much will this move the needle?
• Confidence: How sure are we about impact and effort?
• Ease: How easy is this to implement?

ICE Example:

MoSCoW for Release Scoping

Good MoSCoW Example:

## v2.3 Release Scope

### Must Have (Ship or don't release)
- [ ] Fix critical payment bug (#1234)
- [ ] GDPR delete endpoint compliance
- [ ] Performance fix for dashboard load

### Should Have (Plan for these)
- [ ] Improved error messages
- [ ] Bulk export feature
- [ ] Email notification preferences

### Could Have (Stretch goals)
- [ ] Dark mode toggle
- [ ] Keyboard shortcuts
- [ ] Widget redesign

### Won't Have (Explicitly deferred)
- Mobile app improvements (v2.4)
- API v2 (Q3 initiative)
- Multi-language support (2025)

Value vs Effort Matrix

                    High Value
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   STRATEGIC   │  QUICK WINS   │
         │   (plan for)  │  (do first)   │
         │               │               │
High     │               │               │   Low
Effort───┼───────────────┼───────────────┼───Effort
         │               │               │
         │   MONEY PIT   │   FILL-INS    │
         │  (avoid)      │  (do if time) │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    Low Value

Quadrant Actions:

• Quick Wins: Do immediately, low effort + high value
• Strategic: Plan carefully, worth the investment
• Fill-ins: Good for new team members or slack time
• Money Pit: Explicitly say no

Kano Model

Example by Category:

• Basic: App doesn't crash, data is saved
• Performance: Faster load times, more storage
• Delighter: AI suggestions, proactive insights

Prioritization Meeting Template

## Prioritization Review - [Date]

### Inputs
- Current backlog: [X items]
- Engineering capacity: [Y story points]
- Strategic goals: [List 2-3]

### Scoring Results
| Rank | Item | RICE Score | Owner Notes |
|------|------|------------|-------------|
| 1 | Feature A | 5,333 | Aligned to activation goal |
| 2 | Feature B | 2,500 | Customer request volume |
| 3 | Feature C | 600 | Strategic bet |

### Decisions
- Prioritized: [Items moving forward]
- Deprioritized: [Items deferred]
- Needs research: [Items needing discovery]

### Next Steps
- [ ] Update roadmap
- [ ] Communicate to stakeholders
- [ ] Begin spec work on top items

Anti-Patterns

• HiPPO — Highest Paid Person's Opinion overrides data
• Squeaky wheel — Loudest stakeholder wins
• FIFO — First request in, first built
• Framework worship — Blindly following scores without judgment
• No framework — Pure gut feel without transparency
• Gaming scores — Inflating numbers to justify decisions already made
• Analysis paralysis — Scoring everything, deciding nothing

---

title: Release Planning and Coordination impact: MEDIUM-HIGH tags: release, launch, coordination, communication

Release Planning and Coordination

Impact: MEDIUM-HIGH

Great releases require orchestration across teams. Plan the release as carefully as you plan the feature.

Release Types

Release Planning Timeline

┌─────────────────────────────────────────────────────────────────┐
│                    MAJOR RELEASE TIMELINE                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  T-4 weeks        T-2 weeks        T-1 week        LAUNCH       │
│  ──────────       ──────────       ─────────       ──────       │
│  • Feature        • Code freeze    • Final QA      • Deploy     │
│    complete       • Beta testing   • Launch prep   • Announce   │
│  • Internal       • Docs ready     • Comms ready   • Monitor    │
│    testing        • Training       • Rollback      • Support    │
│  • Stakeholder    • Marketing      • On-call       • Celebrate  │
│    preview          ready            ready                      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Release Checklist Template

## Release Checklist: [Feature Name] v[X.Y]

### Target Date: [Date]
### Release Owner: [PM Name]
### Engineering Lead: [Name]

---

### Pre-Development
- [ ] Requirements documented and approved
- [ ] Success metrics defined
- [ ] Dependencies identified
- [ ] Stakeholders informed of timeline

### Development Complete (T-2 weeks)
- [ ] All code merged to release branch
- [ ] Unit tests passing (>90% coverage)
- [ ] Integration tests passing
- [ ] Performance benchmarks met
- [ ] Security review completed
- [ ] Accessibility audit passed

### Documentation (T-2 weeks)
- [ ] Help docs updated
- [ ] API documentation updated
- [ ] Changelog drafted
- [ ] Release notes drafted
- [ ] Internal FAQ prepared

### Marketing/Comms (T-1 week)
- [ ] Blog post drafted
- [ ] Email announcement drafted
- [ ] Social media posts scheduled
- [ ] In-app announcement configured
- [ ] Press/analyst briefings scheduled (if applicable)

### Sales Enablement (T-1 week)
- [ ] Sales deck updated
- [ ] Demo script prepared
- [ ] Training session completed
- [ ] Competitive positioning updated

### Support Preparation (T-1 week)
- [ ] Support team trained
- [ ] Known issues documented
- [ ] Escalation path defined
- [ ] FAQ for common questions

### Launch Day
- [ ] Deployment successful
- [ ] Smoke tests passing
- [ ] Monitoring dashboards reviewed
- [ ] Announcements published
- [ ] Team on standby for issues

### Post-Launch (T+1 week)
- [ ] Metrics reviewed vs targets
- [ ] User feedback collected
- [ ] Bugs triaged and prioritized
- [ ] Retrospective scheduled
- [ ] Quick fixes deployed if needed

Coordinating Cross-Functional Launch

Release Communication Template

Internal Announcement:

## [Feature Name] Shipping Today

### What's New
Brief description of the feature and why it matters.

### Who It Affects
- Users: [segments affected]
- Teams: [internal teams impacted]

### Key Details
- Available: [date/time, regions]
- Documentation: [link]
- Known issues: [link or "none"]

### What You Need to Do
- **Sales:** Review updated deck [link]
- **Support:** Complete training [link]
- **CS:** Prepare to communicate to [segment]

### Questions?
Reach out to [PM name] in #[channel]

External Announcement:

## Introducing [Feature Name]

We're excited to announce [feature] — [one line value prop].

### What's New
[2-3 bullet points of key capabilities]

### Why We Built This
[1 paragraph on customer problem being solved]

### How to Get Started
[Clear instructions or link]

### Learn More
- Documentation: [link]
- Video walkthrough: [link]
- Webinar signup: [link]

### What's Next
[Tease upcoming enhancements]

Feature Flag Rollout Strategy

## Rollout Plan: Feature X

### Phase 1: Canary (1%)
- Target: Internal employees only
- Duration: 2 days
- Exit criteria: No P0/P1 bugs, <1% error rate

### Phase 2: Beta (10%)
- Target: Power users (>10 sessions/week)
- Duration: 5 days
- Exit criteria: NPS > 30, no major UX issues

### Phase 3: GA Soft (50%)
- Target: All paid users
- Duration: 1 week
- Exit criteria: Adoption > 20%, no support spike

### Phase 4: GA Full (100%)
- Target: All users
- Exit criteria: Metrics meet targets

### Rollback Triggers
- P0 bug affecting >1% users
- Error rate >5%
- NPS drop >20 points
- Support tickets 3x baseline

Managing Launch Risks

Post-Launch Review Template

## Post-Launch Review: [Feature Name]

### Launch Summary
- **Ship date:** [Date]
- **Target audience:** [Segment]
- **Success metrics target:** [Metric + target]

### Results (T+2 weeks)
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Adoption | 25% | 31% | Exceeded |
| NPS | +10 | +8 | Close |
| Support tickets | <100 | 87 | Met |

### What Went Well
- Staged rollout caught bug early
- Sales enablement was effective
- Documentation was comprehensive

### What Could Improve
- Marketing timing was rushed
- Missing edge case in QA
- Stakeholder comms could be earlier

### Action Items
- [ ] Fix bug found in beta (owner: eng)
- [ ] Start earlier on marketing next time (owner: PM)
- [ ] Add edge case to QA checklist (owner: QA)

### Next Steps
- v1.1 planning with feedback incorporated
- Retrospective with full team scheduled

Anti-Patterns

• Big bang releases — Shipping everything at once, no rollout plan
• Surprise launches — Not coordinating with stakeholders
• No rollback plan — Shipping without an escape hatch
• Documentation afterthought — Writing docs after launch
• Ignoring post-launch — Shipping and moving on immediately
• Over-engineering launches — Massive campaigns for small features
• Under-communicating — Teams learn about launch from customers

---

title: Roadmap Creation and Maintenance impact: CRITICAL tags: roadmap, strategy, planning, alignment

Roadmap Creation and Maintenance

Impact: CRITICAL

A roadmap is a communication tool, not a promise. It aligns stakeholders around strategic direction while maintaining flexibility for learning.

Roadmap Types by Audience

The Now-Next-Later Framework

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   NOW              NEXT              LATER                      │
│   (Committed)      (Planned)         (Exploratory)              │
│                                                                 │
│   ┌──────────┐     ┌──────────┐     ┌──────────┐               │
│   │ Feature A│     │ Feature D│     │ Feature G│               │
│   │ Feature B│     │ Feature E│     │ Feature H│               │
│   │ Feature C│     │ Feature F│     │ Theme X  │               │
│   └──────────┘     └──────────┘     └──────────┘               │
│                                                                 │
│   High certainty   Medium certainty  Low certainty              │
│   Detailed specs   General scope     Problem-level              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Good Roadmap: Outcome-Based

## Q1 2024 Roadmap

### Objective: Increase activation rate from 23% to 35%

**Now (January)**
- Onboarding flow redesign (addresses 40% drop-off at step 3)
- In-app guidance for first workflow creation
- Email sequence optimization for day 1-7

**Next (February-March)**
- Template library expansion (top request from churned users)
- Mobile app MVP (30% of signups are mobile-first)
- Integration with top 3 requested tools

**Later (Q2 consideration)**
- AI-powered setup assistant
- Team onboarding flow
- Advanced personalization

### Success Metrics
- Primary: Activation rate (23% → 35%)
- Secondary: Time-to-first-value (3 days → 1 day)
- Guardrail: Support ticket volume (maintain < 5% increase)

Bad Roadmap: Feature Shopping List

## Q1 2024 Roadmap

### January
- Dark mode
- Export to CSV
- User avatars
- Password reset improvements

### February
- Dashboard redesign
- New chart types
- API v2
- Mobile app

### March
- SSO integration
- Webhooks
- Custom domains
- White labeling

Why this fails:

• No strategic context or "why"
• No connection to outcomes
• Encourages date-based commitments
• No prioritization rationale

Roadmap Maintenance Rhythm

Communicating Roadmap Changes

When priorities shift:

## Roadmap Update: March 2024

### What Changed
Mobile app MVP moved from Q1 → Q2

### Why
- User research revealed web activation is the primary bottleneck
- Mobile users who activate on web have 2x retention
- Engineering capacity needed for onboarding improvements

### Impact
- Users requesting mobile: Delayed by ~6 weeks
- Onboarding improvements: Accelerated by 4 weeks
- Expected activation lift: +8% (vs +3% from mobile)

### Next Review
April roadmap review will reassess mobile timeline

Roadmap Review Questions

Before finalizing any roadmap:

1. Strategic alignment — Does this ladder up to company goals?
2. Customer value — What problems does this solve?
3. Measurable outcomes — How will we know it worked?
4. Dependencies — What must happen first?
5. Risks — What could prevent success?
6. Trade-offs — What are we NOT doing?

Anti-Patterns

• Date-driven — "We promised this for March" over strategic fit
• Feature-centric — Lists of features without outcomes
• Stakeholder appeasement — Something for everyone, focus for no one
• Set and forget — Creating once, never updating
• Overly detailed futures — Specifying Q4 at the same level as Q1
• No flexibility — Treating roadmap as contract, not hypothesis

---

title: Feature Scoping and Trade-offs impact: HIGH tags: scoping, mvp, trade-offs, requirements, specs

Feature Scoping and Trade-offs

Impact: HIGH

Great PMs ship value early and often. Master the art of scoping to deliver maximum impact with minimum effort.

The MVP Mindset

                    VALUE DELIVERED
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   Don't       │   MVP         │
         │   Build       │   (Start      │
         │   (waste)     │    here)      │
         │               │               │
Low      │               │               │   High
Learning─┼───────────────┼───────────────┼───Learning
         │               │               │
         │   Avoid       │   Eventually  │
         │   (risky)     │   (grow into) │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    VALUE DELIVERED

Scoping Levels

Good Scoping Example: Notification System

## Feature: Notification System

### Business Context
Users miss important updates, leading to 15% churn within 30 days.
Goal: Reduce "missed update" churn by 50%.

### Scoping Options

#### Skateboard (Week 1-2) — RECOMMENDED START
- Email notifications for critical events only
  - Failed payment
  - Approaching usage limit
  - Team invitation
- Single email template
- No preferences (always on)
- Success metric: Open rate > 40%

#### Scooter (Week 3-4)
- Add 5 more notification types
- Basic email preferences (all/none per category)
- In-app notification bell (unread count only)

#### Bicycle (Month 2)
- Full notification preferences by type/channel
- In-app notification center with history
- Push notifications (web)
- Real-time in-app badges

#### Motorcycle (Q3)
- Mobile push notifications
- Slack/Teams integration
- Notification digests (daily/weekly)
- Smart notification timing

### Recommendation
Start with Skateboard. We can validate email engagement
before building more complex infrastructure.

Bad Scoping Example

## Feature: Notification System

We need to build a full notification system with:
- Email, push, SMS, in-app, and Slack
- User preferences for every notification type
- Real-time delivery
- Notification history
- Analytics dashboard
- A/B testing for templates

Timeline: 2 months

Why this fails:

• All or nothing approach
• No prioritization
• No connection to outcomes
• High risk of delays

Trade-off Framework: The Iron Triangle

                    ┌─────────┐
                    │  SCOPE  │
                    └────┬────┘
                         │
         ┌───────────────┼───────────────┐
         │               │               │
    ┌────┴────┐     ┌────┴────┐     ┌────┴────┐
    │   TIME  │─────│ QUALITY │─────│   COST  │
    └─────────┘     └─────────┘     └─────────┘

    Pick 2. The third flexes.

Trade-off Communication Template

## Trade-off Decision: Feature X

### Situation
We have 3 weeks until launch. Current estimate: 5 weeks.

### Options

#### Option A: Reduce scope (RECOMMENDED)
- Cut: Advanced filtering, bulk actions
- Keep: Core functionality, basic filtering
- Risk: Some power users disappointed
- Benefit: Ships on time, validates core value

#### Option B: Extend timeline
- Cut: Nothing
- Delay: 2 weeks
- Risk: Misses marketing campaign
- Benefit: Full feature set

#### Option C: Add resources
- Add: 2 contractors
- Risk: Onboarding time, coordination overhead
- Benefit: Might recover 1 week

### Recommendation
Option A. We can add cut features in v1.1 based on
user feedback. Launching on time is critical.

### Decision needed by: [Date]

Scope Creep Defense

MoSCoW for Feature Scoping

## Feature X Scope

### Must Have (v1.0 - 2 weeks)
- Core functionality that solves primary use case
- Basic error handling
- Mobile-responsive

### Should Have (v1.1 - +1 week)
- Secondary use case support
- Improved error messages
- Performance optimization

### Could Have (v1.2 - +2 weeks)
- Power user features
- Keyboard shortcuts
- Bulk operations

### Won't Have (Future consideration)
- API access
- White-labeling
- Enterprise features

Questions to Reduce Scope

Ask these to find what can be cut:

1. "What's the smallest thing that would be valuable?"
2. "If we had one week, what would we build?"
3. "What would users forgive being missing?"
4. "Can this be manual before automated?"
5. "Can we use existing infrastructure?"
6. "What can we learn before building?"
7. "Is this a must-have or nice-to-have?"

Scope Negotiation Phrases

Anti-Patterns

• Big bang releases — Building for months before shipping
• Scope fear — Afraid to cut anything
• Spec-driven development — Writing perfect specs for months
• All or nothing — "Either we do it right or not at all"
• User-requested features — Building exactly what users ask for (not their problem)
• Premature optimization — Building for scale before product-market fit
• Ignoring constraints — Pretending resources are unlimited

---

title: Sprint Planning and Backlog Management impact: HIGH tags: sprint, backlog, agile, planning, estimation

Sprint Planning and Backlog Management

Impact: HIGH

Sprint planning transforms strategy into execution. Great backlog management keeps teams focused, predictable, and shipping value consistently.

Sprint Planning Process

┌─────────────────────────────────────────────────────────────────┐
│                     SPRINT PLANNING FLOW                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  BEFORE (PM prep)          DURING (Team)        AFTER (Execute) │
│  ─────────────────         ─────────────        ────────────────│
│  • Groom backlog           • Review capacity    • Daily standups │
│  • Prioritize items        • Commit to work     • Unblock team   │
│  • Write acceptance        • Estimate effort    • Track progress │
│    criteria                • Assign owners      • Manage scope   │
│  • Prepare context         • Flag risks         • Demo + retro   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Backlog Health Checklist

Story Quality Standards

Good User Story:

## As a marketing manager, I want to export campaign data to CSV
   so that I can analyze performance in my preferred spreadsheet tool

### Acceptance Criteria
- [ ] Export button visible on campaign list page
- [ ] CSV includes: campaign name, dates, spend, impressions, clicks, conversions
- [ ] Export completes in < 30 seconds for up to 1000 campaigns
- [ ] User sees progress indicator during export
- [ ] Error message shown if export fails with retry option

### Technical Notes
- Use existing async job infrastructure
- Rate limit: 5 exports per user per hour

### Out of Scope
- Scheduled/automated exports (future enhancement)
- Custom column selection (v2)

### Size: 5 points
### Dependencies: None
### Designer: @jane (mocks attached)

Bad User Story:

## Export feature

Add export to the campaigns page.

Why this fails:

• No user context or "why"
• No acceptance criteria
• No scope boundaries
• No technical context

Estimation Best Practices

Story Point Scale:

Estimation Tips:

• Compare to reference stories team has completed
• Include testing time, not just coding
• Account for unknowns with spikes
• If > 8 points, break down further

Sprint Capacity Planning

## Sprint 23 Capacity

### Team Composition
- 4 engineers × 10 days = 40 person-days
- Minus: PTO (2 days), meetings (20%), support rotation (10%)
- Available: 40 × 0.7 = 28 person-days

### Velocity Reference
- Last 3 sprints: 32, 28, 35 points
- Average: 32 points
- Commitment: 28-32 points (conservative)

### Allocation
- Features: 70% (20-22 points)
- Bugs: 15% (4-5 points)
- Tech debt: 15% (4-5 points)

Backlog Grooming Agenda

Weekly grooming session (1 hour):

## Grooming Session - [Date]

### 1. Review upcoming sprint items (20 min)
- Walk through top 10 backlog items
- Clarify requirements, answer questions
- Identify missing information

### 2. Estimate new items (20 min)
- Planning poker for unestimated stories
- Break down items > 8 points
- Add to "ready for sprint" when complete

### 3. Backlog hygiene (10 min)
- Archive stale items (> 6 months untouched)
- Merge duplicates
- Reprioritize based on new information

### 4. Look ahead (10 min)
- Preview items for sprint+2
- Identify research/spikes needed
- Flag dependencies early

Sprint Ceremonies Quick Reference

Managing Mid-Sprint Changes

Sprint Metrics to Track

Anti-Patterns

• Sprint stuffing — Committing to more than capacity
• No commitment — "We'll see what we get done"
• Infinite grooming — Perfecting stories that may never be built
• Estimation theater — Going through motions without accuracy
• Skipping retros — Missing opportunities to improve
• PM as ticket writer — Writing stories without engineering input
• Velocity as performance metric — Comparing teams, gaming points
• No buffer — Zero slack for unknowns and support

---

title: Stakeholder Management impact: HIGH tags: stakeholder, communication, alignment, influence

Stakeholder Management

Impact: HIGH

PMs don't have authority — they have influence. Master the art of aligning diverse stakeholders around shared outcomes.

Stakeholder Mapping Matrix

                    High Influence
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │    MANAGE     │   PARTNER     │
         │   CLOSELY     │   ACTIVELY    │
         │  (keep happy) │ (collaborate) │
         │               │               │
Low      │               │               │   High
Interest─┼───────────────┼───────────────┼───Interest
         │               │               │
         │    MONITOR    │   KEEP        │
         │   (minimal)   │   INFORMED    │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    Low Influence

Stakeholder Communication Guide

Managing Up: Executive Communication

Good Executive Update:

## Product Update - March 2024

### Headline
Activation rate improved 8% (23% → 31%), on track for Q1 target of 35%

### Key Wins
- Onboarding v2 shipped (March 1)
- Time-to-first-value reduced from 3 days to 1.5 days
- NPS improved 12 points for new users

### Risks & Blockers
- Mobile app delayed 4 weeks (replatforming decision)
  - Mitigation: Web experience prioritized
- Enterprise deal at risk due to SSO timeline
  - Mitigation: Fast-track SSO for Q2

### Next Month Focus
- Complete onboarding v2.1 (remaining 15% of flow)
- Launch template library (addresses top user request)
- Begin mobile app development

### Asks
- Decision needed: Expand engineering team by 2 in Q2?
- Awareness: Competitor X launched similar feature

Bad Executive Update:

## Product Update

We shipped 47 features this month including dark mode,
new icons, dashboard improvements, and various bug fixes.
The team is working hard on the roadmap. We have some
delays but are managing them. Let me know if you have
any questions.

Why this fails:

• No connection to outcomes
• Feature counting vs. impact
• Vague on risks
• No asks or decisions needed

Managing Across: Cross-Functional Alignment

RACI for Feature Launch:

Legend: R=Responsible, A=Accountable, C=Consulted, I=Informed

Handling Conflicting Priorities

Step 1: Acknowledge all perspectives

"I understand Sales needs feature X for the enterprise deal,
and Engineering is concerned about technical debt. Both are
valid and important."

Step 2: Reframe around shared goals

"We all want sustainable revenue growth. Let's figure out
how to balance short-term wins with long-term health."

Step 3: Use data to facilitate

"Here's what the data tells us: Feature X impacts $200K deal,
technical debt is causing 20% velocity reduction. Let's discuss
the trade-off."

Step 4: Make a recommendation

"My recommendation: Ship a scoped version of Feature X in
2 weeks, then dedicate the next sprint to debt reduction."

Saying No Gracefully

Building Trust Template

Weekly stakeholder touchpoint agenda:

## 1:1 with [Stakeholder] - [Date]

### Open with listening (5 min)
- What's on your mind this week?
- Any concerns I should know about?

### Align on priorities (10 min)
- Here's where we are on [their interest]
- Here's what's coming next
- Any questions or concerns?

### Address blockers (10 min)
- Do you need anything from me?
- Here's what I need from you

### Close with commitment (5 min)
- Recap action items
- Confirm next touchpoint

Influence Without Authority

Techniques that work:

Anti-Patterns

• Avoidance — Hoping conflicts resolve themselves
• People pleasing — Saying yes to everyone
• Surprise attacks — Springing decisions without warning
• Email warfare — Fighting battles over email
• Going over heads — Escalating before trying to resolve
• Information hoarding — Not sharing context freely
• Blame games — Pointing fingers when things fail

---

title: Technical Debt Management impact: MEDIUM-HIGH tags: technical-debt, engineering, maintenance, quality

Technical Debt Management

Impact: MEDIUM-HIGH

Technical debt is the hidden tax on velocity. Great PMs understand, prioritize, and advocate for healthy codebases.

What is Technical Debt?

┌─────────────────────────────────────────────────────────────────┐
│                    TECHNICAL DEBT TYPES                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   DELIBERATE                          ACCIDENTAL                │
│   ───────────                         ──────────                │
│   "We know this is a shortcut,        "We didn't know better    │
│    we'll fix it later"                 at the time"             │
│                                                                 │
│   PRUDENT                             RECKLESS                  │
│   ───────                             ────────                  │
│   "Ship now, refactor later           "What's a design          │
│    with learnings"                     pattern?"                │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │            DELIBERATE + PRUDENT = STRATEGIC             │  │
│   │           (Acceptable, plan for repayment)              │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │            RECKLESS + ACCIDENTAL = CRISIS               │  │
│   │             (Emergency, needs immediate fix)            │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Types of Technical Debt

Technical Debt Prioritization Matrix

                    High Business Risk
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   SCHEDULE    │   FIX NOW     │
         │   (plan it)   │   (urgent)    │
         │               │               │
Low      │               │               │   High
Effort───┼───────────────┼───────────────┼───Effort
         │               │               │
         │   ACCEPT      │   SCHEDULE    │
         │   (live with) │   (plan it)   │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    Low Business Risk

Debt Inventory Template

## Technical Debt Inventory

### Critical (Address within 2 sprints)

| ID | Description | Impact | Effort | Owner |
|----|-------------|--------|--------|-------|
| TD-001 | Auth library 2 versions behind (CVE) | Security risk | 2 days | @alice |
| TD-002 | No rate limiting on public API | Stability risk | 3 days | @bob |

### High (Address this quarter)

| ID | Description | Impact | Effort | Owner |
|----|-------------|--------|--------|-------|
| TD-003 | Test coverage at 45% | Bug escape rate | 2 weeks | Team |
| TD-004 | Dashboard query N+1 problem | Performance | 1 week | @carol |

### Medium (Address this half)

| ID | Description | Impact | Effort | Owner |
|----|-------------|--------|--------|-------|
| TD-005 | Outdated monitoring setup | Incident response | 2 weeks | @dave |
| TD-006 | Documentation gaps | Onboarding time | 1 week | Team |

### Low (Backlog)

| ID | Description | Impact | Effort | Owner |
|----|-------------|--------|--------|-------|
| TD-007 | Legacy CSS framework | Dev velocity | 4 weeks | - |
| TD-008 | Inconsistent API responses | Developer experience | 2 weeks | - |

Balancing Features and Debt

Recommended Sprint Allocation:

Communicating Debt to Leadership

Good debt communication:

## Technical Debt Update - Q1 2024

### Summary
Current tech debt is impacting velocity by ~20%. Without
investment, we project 30% impact by Q3.

### Business Impact
| Debt Item | Current Impact | If Unaddressed |
|-----------|----------------|----------------|
| Test coverage (45%) | 2 bugs/week escape to prod | 4+ bugs/week |
| API performance | 3s load time (2x competitors) | Customer churn |
| Legacy auth | 1 day/sprint maintenance | Security incident |

### Recommended Investment
Allocate 20% of Q2 capacity (6 person-weeks) to:
1. Improve test coverage to 70% (2 weeks)
2. Optimize API queries (2 weeks)
3. Auth library upgrade (2 weeks)

### ROI Projection
- Bug escape rate: -50%
- Development velocity: +15%
- Security risk: Significantly reduced

### Decision Needed
Approve 20% debt allocation in Q2?

Bad debt communication:

We have a lot of tech debt. The code is bad and we need to
rewrite it. Engineering is frustrated. Can we stop features
for a quarter?

Why this fails:

• No business impact framing
• No prioritization
• Vague ask
• No ROI case

Making the Case for Debt Work

Tech Debt Sprint Patterns

Pattern 1: Percentage Allocation

• Every sprint: 15-20% capacity for debt
• Pros: Consistent progress
• Cons: May not complete large items

Pattern 2: Debt Sprints

• Every 4th sprint: 100% debt focus
• Pros: Complete larger items
• Cons: Feature pause, coordination

Pattern 3: Boy Scout Rule

• "Leave code better than you found it"
• Pros: Continuous improvement
• Cons: Hard to track, may not address big items

Pattern 4: Hack Weeks

• Quarterly: Full week debt focus
• Pros: Team morale, big wins
• Cons: Infrequent, items pile up

Preventing New Debt

Tech Debt Retrospective Questions

1. What shortcuts did we take this quarter?
2. What's slowing us down the most?
3. What keeps breaking?
4. What would we do differently if starting fresh?
5. What are engineers most frustrated by?
6. What would make onboarding new developers easier?

Anti-Patterns

• Debt denial — "We don't have tech debt"
• Debt hoarding — Tracking but never addressing
• Big bang rewrites — "Let's rewrite everything"
• Invisible debt — Not tracking or communicating
• Feature tunnel vision — Only new work, never maintenance
• Gold plating — Fixing debt that doesn't matter
• Blaming engineers — Debt is a business decision
• No prioritization — All debt is equal (it's not)