planning

Product Planning

Disclaimer

Planning artifacts are living documents. Update them as you learn -- a PRD written before user research is a hypothesis, not a spec.

Roadmapping

A roadmap communicates what you are building, why it matters, and roughly when it will happen. It is not a project plan. It is not a feature list. It is a strategic communication tool that aligns the team around priorities and gives stakeholders enough visibility to do their jobs without micromanaging yours.

The right roadmap format depends on your organization's maturity, planning cadence, and audience. Startups need speed and flexibility. Enterprises need coordination and predictability. Both need clarity.

Startup Mode: Now / Next / Later

For early-stage products (pre-Series B, teams under 30), avoid date-based roadmaps. You do not have enough data to predict timelines accurately, and false precision erodes trust faster than no dates at all. Use a theme-based Now/Next/Later format instead.

How it works: Three columns. No dates. Each column represents commitment level, not a timeline.

• Now -- Actively building. The team is working on these items today. 2-4 items max. These are committed and in progress.
• Next -- Committed to building. Scoped but not yet started. Engineering has reviewed feasibility. Up to 6 items. These are what we will start when a Now item ships.
• Later -- Exploring. We believe these are important, but they need more research, design, or validation before committing. Up to 8 items. These may change significantly or get cut.

Rules:

• Fits on one page. If it does not fit, you have too many items.
• Update weekly. Move items between columns as reality changes.
• Each item is a theme or outcome, not a feature. "Improve onboarding activation" not "Add tooltip to step 3."
• Items in Now should have an owner. Items in Next should have a rough scope. Items in Later can be just a problem statement.

Now / Next / Later Template:

ROADMAP — NOW / NEXT / LATER
==============================
Product: _______________
Last updated: _______________
Owner: _______________

NOW (actively building)          NEXT (committed, up next)         LATER (exploring)
-------------------------------- --------------------------------- ---------------------------------
[ ] Theme: _______________       [ ] Theme: _______________        [ ] Theme: _______________
    Owner: ___________               Rough scope: _________            Problem: ______________
    Key deliverable: ____            Depends on: __________
    Target outcome: _____            Target outcome: _____        [ ] Theme: _______________
                                                                      Problem: ______________
[ ] Theme: _______________       [ ] Theme: _______________
    Owner: ___________               Rough scope: _________        [ ] Theme: _______________
    Key deliverable: ____            Depends on: __________            Problem: ______________
    Target outcome: _____            Target outcome: _____
                                                                  [ ] Theme: _______________
[ ] Theme: _______________       [ ] Theme: _______________            Problem: ______________
    Owner: ___________               Rough scope: _________
    Key deliverable: ____            Target outcome: _____        [ ] Theme: _______________
    Target outcome: _____                                             Problem: ______________
                                 [ ] Theme: _______________
                                     Rough scope: _________        [ ] Theme: _______________
                                     Target outcome: _____             Problem: ______________

                                                                  [ ] Theme: _______________
                                                                      Problem: ______________

                                                                  [ ] Theme: _______________
                                                                      Problem: ______________

RECENTLY SHIPPED:
- [item] — [outcome achieved or pending measurement]
- [item] — [outcome achieved or pending measurement]

Worked example:

NOW (actively building)          NEXT (committed, up next)         LATER (exploring)
-------------------------------- --------------------------------- ---------------------------------
[ ] Reduce onboarding friction   [ ] Self-serve billing portal     [ ] Multi-workspace support
    Owner: Jamie                     Rough scope: Stripe                Problem: Power users want
    Key deliverable: Redesigned      integration, plan changes,         to separate projects but
    first-run experience             invoice history                    share billing
    Target outcome: Day-7            Target outcome: Reduce
    activation from 22% to 35%       billing support tickets by    [ ] AI-assisted prioritization
                                     50%                               Problem: PMs spend 10+
[ ] Search performance                                                 hrs/week on manual
    Owner: Alex                  [ ] Team permissions                   prioritization
    Key deliverable: Sub-200ms       Rough scope: Role-based
    p95 search latency               access, admin controls        [ ] Public API v2
    Target outcome: Reduce           Target outcome: Unblock           Problem: Current API lacks
    search-related churn             3 enterprise deals in              webhooks and bulk
    complaints to near zero          pipeline                           operations

Enterprise Mode: Timeline Roadmap

For organizations with multiple teams, quarterly planning cycles, and cross-team dependencies, a timeline roadmap provides the structure needed to coordinate execution. This does not mean committing to exact ship dates for every feature -- it means establishing quarterly milestones with clear deliverables and dependency relationships.

Timeline Roadmap Structure:

• Swim lanes by team or product area. Each team or product area gets its own horizontal lane. This shows who owns what and where efforts overlap.
• Quarterly milestones. Each quarter has 2-3 major milestones with clear deliverables. A milestone is not "work on X" -- it is "X is shipped and measurable."
• Cross-team dependencies via RACI. For each milestone that involves multiple teams, document: who is Responsible (does the work), Accountable (owns the outcome), Consulted (provides input), Informed (needs to know).
• Milestone gates. For each major milestone, define what must be true to proceed to the next phase. Gates prevent teams from building on an unstable foundation.
• Executive review format. Quarterly review with leadership to confirm priorities, adjust scope, and communicate risks.

Timeline Roadmap Template:

TIMELINE ROADMAP
=================
Product: _______________  |  Period: FY 20__
Owner: _______________    |  Last updated: _______________

SWIM LANE: [Team / Product Area 1]
---------------------------------------------------------------------
Q1                    Q2                    Q3                    Q4
---------------------------------------------------------------------
M: [Milestone 1]     M: [Milestone 3]     M: [Milestone 5]     M: [Milestone 7]
   Deliverable:          Deliverable:          Deliverable:          Deliverable:
   Success metric:       Success metric:       Success metric:       Success metric:
   Gate: [what must      Gate:                 Gate:                 Gate:
   be true to proceed]

M: [Milestone 2]     M: [Milestone 4]                           M: [Milestone 8]
   Deliverable:          Deliverable:                               Deliverable:
   Success metric:       Success metric:                            Success metric:

SWIM LANE: [Team / Product Area 2]
---------------------------------------------------------------------
Q1                    Q2                    Q3                    Q4
---------------------------------------------------------------------
M: [Milestone A]     M: [Milestone C]     M: [Milestone D]     M: [Milestone E]
   Deliverable:          Deliverable:          Deliverable:          Deliverable:
   Success metric:       Success metric:       Success metric:       Success metric:

DEPENDENCIES:
| Milestone | Depends On | Owning Team | RACI | Handoff Date | Status |
|-----------|------------|-------------|------|--------------|--------|
| M3        | M2 shipped | Team 1      | R: Team 1, A: PM Lead, C: Team 2, I: Exec | Mar 31 | On track |
| M-C       | M1 API     | Team 2      | R: Team 2, A: Eng Lead, C: Team 1, I: Sales | Feb 15 | At risk  |

MILESTONE GATES:
| Milestone | Gate Criteria | Owner | Status |
|-----------|--------------|-------|--------|
| M2 -> M3  | API latency < 200ms p99, zero critical bugs, load test passed | Eng Lead | Pending |
| M-C -> M-D| 80% of beta users activated, NPS > 30 from beta cohort | PM Lead | Not started |

RISKS & MITIGATIONS:
| Risk | Impact (H/M/L) | Probability (H/M/L) | Mitigation | Owner |
|------|----------------|---------------------|------------|-------|
|      |                |                     |            |       |

EXECUTIVE REVIEW CADENCE: [Quarterly — next review: ___]

Roadmap Communication

Different audiences need different views of the same roadmap. Showing engineering details to the board wastes their time and yours. Showing strategic themes to engineers without scope details leaves them unable to plan. Tailor the message.

Audience	What They Care About	Format	Cadence	What to Exclude
Board	Strategy, market positioning, key metrics, major bets	3-5 slides: vision, strategic themes, KPI dashboard, major risks	Quarterly (board meeting)	Feature names, engineering details, sprint-level scope
Executive team	Themes, milestones, resource allocation, cross-team risks	1-page timeline with swim lanes, milestone gates, dependency map	Monthly (leadership sync)	Individual story-level items, technical implementation details
Engineering	Detailed scope, technical requirements, dependencies, sequencing	Full roadmap with PRD links, API contracts, data model changes, story breakdowns	Weekly (planning/standup)	Business justification (they should already know the "why")
Customers	What is coming that solves their problems, general direction	Blog post, changelog preview, or "coming soon" page -- value-oriented, no dates	Quarterly or as features ship	Internal codenames, exact timelines, features that may get cut

Key rule: Never share dates with customers unless you are highly confident (>90%) in delivery. "Coming this quarter" is acceptable. "Shipping March 15" is a commitment you may not be able to keep. Missed external dates damage trust far more than vague timelines.

Roadmap Anti-Patterns

Watch for these failure modes and correct them immediately:

• Feature factory. Teams ship features without connecting them to outcomes. The roadmap is a list of things to build, not a strategy. Fix: every roadmap item must have a target outcome and success metric. If you cannot articulate why you are building it, do not build it.
• Date-driven roadmaps without outcomes. The roadmap says "Ship X by March" but does not say what success looks like. Teams hit the date but miss the impact. Fix: pair every date commitment with a measurable outcome. "Ship X by March; target: 20% increase in activation."
• Roadmap-as-contract. Stakeholders treat roadmap estimates as commitments. When priorities shift, trust breaks down. Fix: explicitly label commitment levels. "Committed" vs. "Planned" vs. "Exploring." Educate stakeholders that only "Committed" items are near-certain.
• Not updating the roadmap. The roadmap was last updated 3 months ago and no longer reflects reality. Teams work off tribal knowledge instead. Fix: set a weekly 15-minute review to update the roadmap. If you cannot maintain it weekly, your roadmap is too detailed.
• Stakeholder-driven roadmap (loudest voice wins). The VP of Sales dictates the roadmap based on the last customer call. Product strategy is reactive, not proactive. Fix: use a prioritization framework (see Prioritization section below). Every request goes through the same scoring process, regardless of who is asking.

---

---

References

For detailed templates, frameworks, and field-level guidance, read:

• references/planning-reference.md — Complete framework details, templates, and examples

Read this file when the task requires:

• PRDs
• Feature Specs
• Prioritization
• Backlog Grooming
• Output Formats