| name | pm-execution |
| description | Build-and-ship workflow - shipping products, managing timelines, decisions, meetings, retros, and cross-functional collaboration |
| triggers | ["shipping","launch","timeline","cross-functional","collaboration","decision","meeting","retro","retrospective","post-mortem","trade-offs","design review"] |
PM Execution: Ship with Quality and Speed
Execution is where strategy meets reality. This module covers the full build-to-launch cycle: decisions, coordination, delivery, and learning from the outcome.
When to Use This Module
- Kicking off a new project with eng and design
- Managing delivery timelines and dependencies
- Making go/no-go decisions
- Running meetings, retros, or post-mortems
- Resolving cross-functional conflicts
Workflow Overview
Kickoff → Build (decisions + coordination) → QA → Launch → Retro → Learn
Skills
1. Shipping Products
Context: The #1 job of a PM is to ship. Shipping is a muscle — the more you do it, the better you get.
Framework — Ship Cadence:
- Define "done" before starting (launch criteria, not feature list)
- Break into milestones: 1-2 week chunks with demoable output
- Daily standups: 15 min, blockers only — not status updates
- Weekly demo: Show working software to stakeholders
- Launch readiness review: 1 week before launch, run the launch checklist
Anti-patterns:
- "Almost done" for 3 weeks
- No launch criteria defined upfront
- Launching on Friday
2. Managing Timelines
Context: Timelines slip. Good PMs plan for it.
Framework — Timeline Management:
- Get engineering estimates, then add 30% buffer (first-time features: 50%)
- Track to milestones, not to final date — early slip detection
- When behind: cut scope first, extend timeline second, add people never
- Communicate timeline changes immediately — no surprises
- Use a shared tracker visible to all stakeholders
3. Cross-functional Collaboration
Context: PMs don't build anything. They align people who do.
Framework — RACI for Every Project:
- Responsible: Who does the work?
- Accountable: Who makes the final call? (only one person)
- Consulted: Who provides input before the decision?
- Informed: Who needs to know after the decision?
Collaboration Rules:
- Establish RACI at kickoff — ambiguity causes conflict later
- Over-communicate at boundaries (PM↔eng, eng↔design, product↔marketing)
- Write things down — verbal agreements evaporate
- Resolve conflicts by going back to the user problem and data
4. Running Decision Processes
Context: The speed and quality of decisions determines the speed and quality of everything else.
Framework — Decision Velocity:
- Type 1 decisions (irreversible): Deliberate, get input, document reasoning
- Type 2 decisions (reversible): Decide fast, course-correct later
- Most decisions are Type 2 — default to speed
- For Type 1: Use decision-doc template
- Set a decision deadline. No deadline = no decision.
Decision Meeting Protocol:
- Send context doc 24h before (never present the problem for the first time in the meeting)
- In the meeting: clarify questions (10 min) → debate options (20 min) → decide (5 min)
- Document: what was decided, who's responsible, by when
- Send write-up within 1 hour
5. Evaluating Trade-offs
Context: Every product decision is a trade-off. Make them explicit.
Framework — Trade-off Matrix:
- List the options (usually 2-3)
- Define criteria (user impact, eng effort, risk, strategic alignment)
- Weight criteria by importance
- Score each option
- Discuss the highest-scored option — does it feel right? If not, examine which criterion is wrong.
Common PM Trade-offs:
- Speed vs quality (default: ship smaller with quality)
- Revenue vs user experience (default: UX, unless existential)
- Platform vs product (default: product, unless 3+ teams blocked)
- Build vs buy (default: buy, unless core differentiator)
6. Running Effective Meetings
Context: Meetings are expensive. A 1-hour meeting with 8 people costs 8 hours of productivity.
Framework — Meeting Hygiene:
- Every meeting has an owner, an agenda, and a desired outcome
- Default to 25 minutes (not 30) or 50 minutes (not 60) — give people buffer
- Start with the decision or question, not background (people read faster than you present)
- End every meeting with: decisions made, action items, owners, deadlines
- If no agenda → cancel. If no decision needed → make it an email.
Meeting Types:
| Type | Purpose | Frequency | Duration |
|---|
| Standup | Unblock | Daily | 15 min |
| Sprint planning | Align on work | Biweekly | 60 min |
| Design review | Evaluate solutions | As needed | 30 min |
| Decision meeting | Make a call | As needed | 25 min |
| Demo | Show progress | Weekly | 30 min |
| Retro | Learn | End of cycle | 60 min |
7. Post-mortems & Retrospectives
Context: Retros turn failures into institutional knowledge. Skip them and you repeat mistakes.
Framework — Blameless Post-mortem:
- Timeline: What happened, in chronological order (facts only)
- Impact: Who was affected and how much?
- Root cause: 5 Whys analysis until you find the systemic issue
- Action items: Specific, owned, with deadlines — max 3 (more = none get done)
- Follow-up: Review action item completion in 2 weeks
Template: See retro-template
Anti-patterns:
- Blaming individuals (blame the system, not the person)
- Action items without owners
- Never reviewing whether action items were completed
8. Planning Under Uncertainty
Context: You don't have perfect information. Plan anyway.
Framework — Scenario Planning:
- Identify the 2-3 biggest unknowns
- Define best case, base case, worst case for each
- Build plans that work across scenarios (robust) vs plans optimized for one scenario (fragile)
- Set tripwires: "If X happens by date Y, we switch to plan B"
- Revisit scenarios monthly — update as you learn
9. Running Design Reviews
Context: Design reviews align product, design, and engineering on the solution before building.
Framework:
- Designer presents the problem (not the solution) first — 2 min
- Walk through the user flow — 10 min
- Feedback round: each reviewer gives feedback on stickies/comments, then discuss — 15 min
- Distinguish "must fix" from "nice to have" from "personal preference"
- Decision: ship as-is, iterate, or rethink
10. Design Engineering
Context: The intersection of design and engineering — where polish and performance meet.
Principles:
- Design and engineering should review together, not in sequence
- Prototype in code early — static mocks miss interaction details
- Define the experience budget: load time, animation FPS, interaction latency
- Invest in design systems to reduce per-feature design cost
Module Checklist
Related Modules
