Product Manager Toolkit

Q3 Product Roadmap — HR SaaS

Format: Now / Next / Later (rolling 3-quarter view)

Now (Q3 — July–September)

Next (Q4 — preview)

• Payroll: Direct deposit enhancements
• Core HR: Performance review cycles
• Analytics: Custom report builder

Later (Q1 next year)

• Mobile app (iOS/Android)
• API for third-party integrations
• AI-powered anomaly detection in payroll

How to present to each audience:

• CEO: Lead with business outcomes. "SSO unblocks 3 enterprise deals worth $280K ARR."
• Engineering: Show initiatives with team ownership, estimated SP, and dependencies highlighted
• Sales: Frame as customer commitments with expected ship dates (use quarters, not months)

Tool recommendation: Productboard or Linear Roadmaps for live version. Export to PDF for board/sales. Want me to draft the CEO one-pager narrative for this roadmap?

The argument you just had is a measurement architecture problem, not a communication problem. Product, sales, and engineering are each measuring something different and calling it "success" — which means you never agreed on what success meant before you shipped. Here's how to fix that structurally.

The North Star + Input Metrics Framework

Every feature needs one north star metric — a single number that reflects whether the feature delivered its intended outcome. Not a proxy, not a process metric, not a vanity count. An outcome.

For a project management tool, "tasks completed via the new feature" is a north star metric. "Feature page views" is not — it measures attention, not value delivered.

The north star metric stops the argument because everyone agreed on it before shipping. Product doesn't get to declare victory on usage if the north star is revenue impact. Sales doesn't get to declare failure if the north star is activation rate.

Input metrics are the leading indicators that predict whether the north star will move:

• If your north star is 30-day retention, your input metrics might be: day-1 activation rate, number of core actions completed in first session, return visits in week 1
• Input metrics give you something to act on within days of launch; north star metrics take weeks to weeks to validate

Writing a Metrics Plan Before Shipping

The pre-launch metrics plan is a single document written during the design or spec phase — not retrospectively. It answers:

1. What is the north star metric for this feature? Example: % of active users who complete a task using the new AI suggestion within 30 days of activation

2. What are the leading indicators (input metrics)? Example: Day-7 adoption rate (% of users who tried the feature at least once), average AI suggestions accepted per user per week

3. What does success look like at 30 / 60 / 90 days? 30 days: 20% adoption rate among eligible users 60 days: 35% of adopters using it weekly 90 days: measurable lift in task completion rate vs. control cohort

4. What are the guardrail metrics?

Guardrail Metrics

Guardrail metrics define what must not get worse while you're optimizing the north star. They exist because local optimization often produces global damage.

For the feature you shipped, guardrail metrics might include:

• Overall user session length (must not decrease by more than 5%)
• Support ticket volume (must not increase more than 10%)
• Existing feature usage rates (AI suggestion feature must not cannibalize manual task creation)
• Page load performance (P95 response time must not exceed current baseline)

Engineering's concern about tech debt is legitimate — but it belongs in the guardrail metrics discussion, not the success declaration. If the feature shipped with known tech debt, the pre-launch plan should include: "we accept this debt at current scale; it becomes a blocker at X threshold."

Vanity vs. Outcome Metrics

The most common measurement mistake is confusing engagement with value.

Your product team calling usage a success and sales calling it a failure are both partially right — because they're measuring different things. Product may be tracking vanity metrics that look healthy. Sales is tracking revenue impact, which is a lagging indicator. Neither is wrong; the problem is they were never reconciled into a single agreed framework.

The Pre-Launch Metrics Alignment Conversation

Run this meeting during the spec or design phase, 2–4 weeks before shipping. 45 minutes. Attendees: PM, engineering lead, sales lead (or head of revenue), and optionally a CS lead.

Agenda:

1. PM presents proposed north star metric (10 min)
2. Team challenges: is this the right outcome to measure? Is it measurable? (10 min)
3. Team agrees on input metrics and 30/60/90 targets (10 min)
4. Each team proposes their guardrail metric (10 min)
5. Document and distribute (5 min)

The document is 1 page. It goes into the feature spec. It's referenced at the 30-day and 60-day retrospectives.

The forcing question: "If this metric looks good at 60 days, would every person in this room agree the feature succeeded?" If the answer is no, you don't have the right metric yet.

Running this conversation before shipping doesn't prevent disagreement — it surfaces it early, when changing course is cheap. The argument you had after shipping costs time, trust, and potentially a product decision reversal. The same conversation 4 weeks earlier costs 45 minutes.