Working with a Project Manager

Do You Even Need a PM?

When You DON'T Need a PM

• Small team (1-2 developers)
  • You can manage directly
  • Communication overhead is low
• Very clear scope
  • Fixed features, no iteration
  • Developers know exactly what to build
• Budget under $30K
  • PM cost (10-15%) doesn't make sense
  • Better to spend on development

When You NEED a PM

• Team of 3+ developers
  • Coordination overhead increases exponentially
  • Someone needs to manage dependencies
• Evolving requirements
  • Scope changes based on feedback
  • Need someone to manage priorities
• You're non-technical
  • PM translates between you and developers
  • Prevents miscommunication
• Long-term project (6+ months)
  • Momentum management is critical
  • Someone needs to keep the big picture

Rule of thumb: If you're spending >10 hours/week on project coordination, you need a PM.

What Your PM Should Actually Be Doing

Core Responsibilities

1. Sprint Planning (2-Week Cycles)

• Before sprint starts:
  • Define sprint goals with you
  • Break down features into tasks
  • Estimate task complexity with developers
  • Prioritize backlog
• During sprint:
  • Track progress daily
  • Remove blockers
  • Manage scope (no mid-sprint changes)
• End of sprint:
  • Demo completed work
  • Retrospective (what worked/didn't)
  • Plan next sprint

2. Communication Hub

• To developers: Clear requirements, priorities, answers to questions
• To you: Progress updates, blockers, timeline changes
• To designers: Coordination on handoffs, feedback
• To QA: Test cases, bug priorities

3. Requirements Management

• Translate your vision into developer-ready specs
• Write user stories with acceptance criteria
• Clarify edge cases and corner scenarios
• Prevent scope creep

4. Risk & Timeline Management

• Identify potential delays early
• Escalate blockers to you quickly
• Maintain realistic timeline
• Adjust priorities when needed

What PM Should NOT Be Doing

• ❌ Writing code (that's a developer)
• ❌ Making product decisions alone (that's your job)
• ❌ Passive note-taking (they should actively manage)
• ❌ Just running meetings (that's not enough value)

The 2-Week Sprint Process

Why 2 Weeks?

• Long enough to accomplish meaningful work
• Short enough to adapt quickly
• Industry standard (easy to compare velocity)

Sprint Structure

Monday Week 1: Sprint Planning (2 hours)

• Review last sprint: What shipped? What didn't?
• Set sprint goal: "Ship user authentication" (not a list, ONE goal)
• Pick tasks: Developers pull from prioritized backlog
• Estimate: Size tasks (small/medium/large or points)
• Commit: Team agrees on what's achievable

Daily Standups (15 min, async OK)

• Each developer shares:
  • Yesterday: What I completed
  • Today: What I'm working on
  • Blockers: Anything stopping me
• PM's job: Note blockers, follow up to resolve

Friday Week 2: Sprint Demo (1 hour)

• Developers demo completed work (show, don't tell)
• You provide feedback (accept or request changes)
• Review metrics: Did we hit the sprint goal?

Friday Week 2: Retrospective (30 min)

• What went well?
• What didn't?
• What should we change?
• PM documents and implements improvements

Sprint Demo Expectations

What a Good Demo Looks Like

• ✅ Working software (not slides or descriptions)
• ✅ On staging environment (you can click through it)
• ✅ Completed features (not 80% done)
• ✅ Meets acceptance criteria from sprint planning

Red Flags in Demo

• 🚩 "It's done but not deployed yet" (it's not done)
• 🚩 "We're 90% complete" (translation: barely started)
• 🚩 Constant apologies for bugs (should be tested before demo)
• 🚩 Can't demo because of "environment issues"
• 🚩 Nothing to show multiple sprints in a row

Your Role in Demos

• Accept or reject work based on acceptance criteria
• Provide feedback (UX tweaks, missed edge cases)
• Ask questions: "What happens if...?"
• Celebrate wins (team morale matters)

Definition of Done: Feature is coded, tested, reviewed, deployed to staging, and demoed. Anything less = not done.

Red Flags Your PM Isn't Working

Communication Red Flags

• 🚩 You hear about problems late
  • Blockers sit for days before escalation
  • Surprises at sprint demo
• 🚩 PM just relays information
  • "Developer says it's hard" (no solutions offered)
  • Doesn't translate technical → business
• 🚩 Developers bypass PM to ask you directly
  • Sign PM isn't adding value

Process Red Flags

• 🚩 No clear sprint goals
  • Just a list of random tasks
  • No coherent focus
• 🚩 Constantly changing priorities mid-sprint
  • Developers can't finish anything
  • No push-back on scope creep
• 🚩 Meetings run long or have no agenda
  • Wasting team time

Delivery Red Flags

• 🚩 Consistent sprint overcommitment
  • Plan 10 tasks, complete 3 (every sprint)
  • PM isn't learning from past velocity
• 🚩 No retrospective improvements
  • Same problems every sprint
  • No action items from retros
• 🚩 Timeline constantly slips
  • "One more week" becomes a pattern
  • No adjustments to scope or resources

PM Evaluation Checklist

Weekly Check (Quick)

• ☐ Did I get proactive updates (not reactive)?
• ☐ Are blockers being resolved quickly?
• ☐ Is sprint progress visible (board, reports)?
• ☐ Do developers seem productive and unblocked?

Monthly Review (Deeper)

• ☐ Are we hitting sprint goals?
• ☐ Is velocity consistent or improving?
• ☐ Are demos showing real progress?
• ☐ Is communication clear and timely?
• ☐ Are retrospective action items being implemented?
• ☐ Do I trust the timeline estimates?

Decision-Making Protocol

Who Decides What

When PM Should Escalate to You

• Timeline at risk (will miss major milestone)
• Budget overrun (need more hours/resources)
• Technical blocker can't be resolved internally
• Developer performance issues
• Scope needs to change significantly

When PM Should Decide Independently

• Daily task assignments
• Meeting schedules
• Minor bug priorities
• Process tweaks (standup format, board structure)
• Developer questions with clear answers

Metrics Your PM Should Track

Sprint Metrics

• Velocity: Points/tasks completed per sprint
  • Should stabilize after 3-4 sprints
  • Use to predict future capacity
• Sprint Goal Success Rate: Did we hit the goal?
  • Target: 80%+ of sprints
• Carryover: Tasks incomplete and moved to next sprint
  • Red flag if >30% regularly

Quality Metrics

• Bug Rate: New bugs per sprint
  • Should decrease over time as code stabilizes
• Escaped Bugs: Bugs found in production (not staging)
  • Indicates testing gaps

Health Metrics

• Blocker Time: How long blockers sit unresolved
  • Target: <24 hours
• Team Morale: Subjective but important
  • Check in retrospectives
  • Watch for burnout signs

PM should send you a weekly summary with these metrics. If you have to ask for them, that's a red flag.

When to Replace Your PM

Give Them a Chance First

Have a direct conversation:

• Point out specific issues (use your checklist)
• Set clear expectations for improvement
• Give 2-4 weeks to demonstrate change

Time to Replace If...

• No improvement after feedback
• Team is more productive without them
• You're doing PM's job for them
• Developers complain about PM consistently
• Timeline confidence is low

Replacing Mid-Project

• Get new PM overlapping 1 week for handoff
• Export all documentation before old PM leaves
• Have developers brief new PM on current state
• Reset expectations (new PM may find issues)

PM Cost Structure

Typical PM Rates

• Junior PM (1-3 years): $30-50/hour
  • Good for straightforward projects
  • Needs some guidance from you
• Mid-Level PM (4-7 years): $50-80/hour
  • Sweet spot for most MVPs
  • Can run independently
• Senior PM (8+ years): $80-150/hour
  • Complex products, large teams
  • Overkill for simple MVPs

Time Commitment

• Small team (2-3 devs): 10-15 hours/week
• Medium team (4-6 devs): 20-30 hours/week
• Large team (7+ devs): Full-time (40 hours/week)

Budget Impact

PM typically adds 10-15% to total project cost

• Example: $50K development + $7K PM = $57K total
• Worth it if they prevent delays and scope creep

Working With vs Without a PM

Without PM (You Manage Directly)

Pros:

• Lower cost
• Direct communication with developers
• Faster decisions

Cons:

• Takes 10-20 hours/week of your time
• You need to learn sprint processes
• Easy to miss project management details

With PM

Pros:

• Professional process management
• Frees up your time (5-10 hours/week)
• Better communication clarity
• Earlier risk detection

Cons:

• Added cost (10-15%)
• Another person to manage
• Can slow down small decisions