The roadmap I shipped vs the roadmap I planned

In Q3 2024, I committed to a quarterly roadmap with seven initiatives. By the end of the quarter, two had shipped. Three were "in progress but slipping." One was killed mid-quarter because customer feedback shifted. One never started — a hardware certification got blocked and it cascaded.

Every PM has a version of this story. The roadmap you ship and the roadmap you planned are different documents. The question isn't whether they'll diverge. It's how you manage the divergence honestly.

This guide is what I've learned in three years of running roadmaps for a hardware/software company across South Africa, Zambia, and Malawi — and the past 18 months building a roadmap tool because none of the existing ones fit. It's not theory. It's what works on Monday morning when stakeholders are in your inbox and engineering is asking what to build next.

Screenshot: assets/screenshots/blog/roadmap-q3-vs-actual.png — A "planned vs actual" view of a real quarterly roadmap, with shipped initiatives in green, slipped in amber, killed in red.

What a roadmap is for (and what it isn't)

Before tools, frameworks, or formats — get clear on the job a roadmap does.

A roadmap is for:

Aligning the team on priority order. Not all initiatives are equal, and the roadmap is the canonical answer to "what's most important right now."
Communicating direction to stakeholders. Sales wants to know what they can pitch. Engineering wants to know what's coming. The board wants confidence the bets are right.
Holding yourself accountable. A public commitment is a forcing function. Without one, drift wins.

A roadmap is NOT for:

Promising delivery dates. Dates on a roadmap are intent, not contract. If your CEO treats them as contracts, that's an organizational problem dressed up as a tooling problem.
Replacing your project plan. A roadmap says what and roughly when. A project plan says how and exactly when. Different artifacts. Don't conflate them.
Replacing customer conversations. No roadmap survives contact with users. Stay close to the people you're building for.

The most common failure mode I see in newer PMs: they treat the roadmap as a gantt chart that has to be defended. It's not. The roadmap is a hypothesis about how to allocate your team's finite time. Hypotheses get updated.

Three roadmap formats — and when each works

Most PM tools push one format. The honest answer is that different formats serve different purposes. Use them all, switch between them depending on the audience.

1. Timeline / Gantt (when you need date intuition)

The classic. Bars on a calendar. Each bar is an initiative; length is the planned date range.

Use it for: quarterly board reviews, dependency visualization, capacity check-ins. Don't use it for: customer-facing communication ("we'll ship on March 14" is a promise; you'll regret making it).

Screenshot: assets/screenshots/blog/roadmap-gantt-quarterly.png — Quarterly Gantt view with sections (Mobile, Core, Growth) and color-coded statuses.

2. Now / Next / Later (when you don't want to over-commit)

Three buckets. "Now" is what's actively being built. "Next" is the queue. "Later" is the maybe-pile.

Use it for: customer-facing roadmap pages, public communication, anything where dates would create false promises. Don't use it for: internal capacity planning. The bucket-based view hides the dependency graph.

3. Kanban (when you need flow visibility)

Initiatives as cards moving through status columns: Strategy → In Progress → Released → At Risk / Delayed.

Use it for: weekly team syncs, identifying stuck initiatives, status updates. Don't use it for: quarterly planning. Kanban shows you where things are now, not where they should be in three months.

Screenshot: assets/screenshots/blog/roadmap-kanban-statuses.png — Kanban with status columns and 21 initiative cards distributed across them.

The PM tool I use (Roadmap OS) lets you toggle between Gantt and Kanban for the same data without switching tools or losing structure. That's a small thing that compounds. When you can answer "what's slipping?" in 5 seconds during a board call, you stop preparing for board calls.

Prioritization: pick the right framework for the decision

Most teams pick one framework (usually RICE) and use it forever. That's a mistake. Different decisions need different lenses.

RICE (Reach × Impact × Confidence ÷ Effort)

Best for: early-stage product, when you have rough estimates of reach and impact. Weakness: confidence multiplier hides bias.

ICE (Impact × Confidence × Ease)

Best for: rapid-fire prioritization where you don't have data — hackathons, brainstorms. Weakness: less rigorous than RICE; fine for triage, not for committing.

MoSCoW (Must / Should / Could / Won't)

Best for: stakeholder alignment, especially when you need explicit "won't" decisions. Weakness: not really prioritization — it's bucketing. Doesn't tell you order within a bucket.

Kano (Basic / Performance / Delighter)

Best for: balancing must-have features against differentiating ones. Weakness: requires user research to score correctly; not a desk exercise.

Cost of Delay

Best for: date-sensitive opportunities. When delaying an initiative has measurable revenue/risk cost. Weakness: requires reasonable estimates of revenue impact, which most teams don't have.

Value vs Effort matrix

Best for: visual review with stakeholders. Quick triage of 20+ initiatives. Weakness: oversimplifies. A 2x2 hides nuance.

The interesting analysis isn't the score. It's where frameworks disagree.

If you score the same initiative across RICE and Cost of Delay and you get wildly different rankings, that's a signal. It means your assumptions about either reach/impact or revenue impact are weak. Investigate before committing.

Screenshot: assets/screenshots/blog/prioritization-framework-comparison.png — Side-by-side scores for the same initiative across RICE, MoSCoW, Cost of Delay. Shows divergence highlighted in amber.

Capacity: the missing half of every roadmap

Here's a pattern I see in 80% of PM teams: roadmap planning happens in one tool, capacity planning (if it happens at all) happens in a spreadsheet. The two are reconciled manually, badly, by the PM the night before a quarterly review.

I missed a hardware certification deadline once because of this. The initiative was on the roadmap. The certification engineer was already at 110% utilization on existing work. Nobody had checked.

Three rules for capacity-aware roadmapping:

Capacity check happens BEFORE commitment, not after. When you add a new initiative to the roadmap, you should be able to see who's available to work on it. If your tool doesn't show this, your tool is hiding the most expensive question you can ask.

Track utilization at multiple time horizons. Daily/weekly view shows you firefighting capacity. Monthly/quarterly shows you strategic capacity. They tell different stories. Both matter.

80% is the sustainable utilization target. If your team is consistently at 95-100%, you have no buffer for the inevitable surprises. Plan for 80%, not 100%.

Screenshot: assets/screenshots/blog/capacity-utilization-dashboard.png — Team utilization dashboard with 6 team members, two flagged at >100% in red.

The reason CapacityIQ is built into Roadmap OS (not a separate add-on) is exactly this: capacity isn't a "nice to have" feature. It's the constraint that determines what's actually possible. A roadmap divorced from capacity is fiction.

The roadmap anti-patterns that quietly kill product teams

After three years and ~200 customers' worth of roadmap reviews, the same mistakes show up:

1. The dump-everything roadmap

The PM lists every idea, request, and "wouldn't it be cool if" item on the roadmap. The roadmap becomes 60+ items long. Nobody reads it. The team can't tell what's actually a priority.

Fix: Cap your active roadmap at 10-15 initiatives per quarter for a small team, 20-30 for a larger one. Anything beyond that goes to a separate "later" or "icebox" view.

2. The PR-driven roadmap

Every initiative looks important and customer-facing because the roadmap is shared publicly and the PM optimizes for "looks good." Internal infrastructure work, technical debt, and platform investments disappear.

Fix: Have an internal roadmap and a customer-facing roadmap. They should overlap, but don't have to be identical. Internal roadmap lists everything; customer-facing one focuses on the value-delivering work.

3. The dates-as-contracts roadmap

The PM commits to "we'll ship X by March 14." Engineering treats this as a deadline. Sales sells against it. Then March 14 arrives and X isn't ready, and trust degrades.

Fix: Use date ranges, not single dates. "Late Q1" or "weeks 10-12." Make the uncertainty visible. Stakeholders prefer honest ranges over false precision.

4. The set-and-forget roadmap

The PM publishes the quarterly roadmap on day 1, then doesn't update it for 13 weeks. By week 7 it's fiction. By week 13 it's an embarrassment.

Fix: Roadmap is a living artifact. Update it weekly during your team sync. Mark slips as they happen. The roadmap should match reality at the end of every week, not just on quarter boundaries.

5. The siloed roadmap

The PM owns the roadmap. Engineering doesn't trust it. Design doesn't see it. Sales builds their own version.

Fix: Co-own the roadmap. Engineering should be able to flag effort estimates that look wrong. Design should be flagging dependency on user research. Sales should be flagging customer asks. The roadmap is the team's artifact, not the PM's.

Screenshot: assets/screenshots/blog/roadmap-collaboration-comments.png — A roadmap initiative card with inline comments from engineering, design, and the PM.

Choosing a roadmap tool: the honest checklist

I've used or trialed every major PM tool — Jira (Advanced Roadmaps), Productboard, Aha!, airfocus, Linear, Asana Goals, Monday, Notion DIY, ClickUp.

Here's the checklist I'd give my younger self:

Must-haves:

Multiple views for the same data (Gantt + Kanban + List). You'll need each for different audiences.
Sections / categories that survive sorting. If you sort by priority and lose your section structure, the tool is fighting you.
Capacity visibility next to the roadmap. Not in another tool.
Stakeholder access without per-user pricing. If your tool punishes you for adding stakeholders, you'll gatekeep, and the roadmap will become a private artifact.

Strong nice-to-haves:

Integrations with your delivery tool (Jira, Linear, GitHub).
A feedback collection mechanism so you stop losing stakeholder asks in Slack.
Multiple prioritization frameworks built-in (you'll outgrow whatever you start with).
Export to PDF/PPT for board reviews.
Audit log of changes.

Don't-need-to-haves (for most teams):

AI features (most are gimmicks today; useful in 2-3 years; not a deciding factor).
Custom dashboards (you'll spend hours configuring; ship-faster wins).
50+ integrations (you'll use 3).

Screenshot: assets/screenshots/blog/tool-comparison-checklist.png — A checklist comparison of Roadmap OS vs Productboard vs Aha! vs airfocus across the must-haves above.

A working roadmap workflow (the one I actually use)

For the curious, here's the cadence I run on a real roadmap (the one I use to manage Roadmap OS itself, eating my own dog food):

Monday morning (60 minutes): Status sweep. Look at every "in progress" initiative. Update status, slip dates if needed, flag risks. Total honesty — if it's slipping, slip it.
Wednesday morning (45 minutes): Stakeholder feedback review. Open the feedback portal, triage new items, vote-rank them, link the ones that matter to the roadmap.
Friday afternoon (30 minutes): Capacity check. Look at next-week capacity for every team member. Flag anyone at >100% utilization.
Monthly (90 minutes): Re-prioritize. Run RICE on top 20 initiatives. Re-order the roadmap if needed.
Quarterly (half day): Strategy review. Are the bets still right? What did we learn this quarter? Update next quarter's roadmap.

That's six hours a month on roadmap maintenance. The trade is that I don't lose initiatives in tool gaps anymore.

The bottom line

A roadmap is a hypothesis about how to allocate your team's finite time. Treat it as a living document, update it honestly, and pick tools that get out of the way.

Most PM tools fail because they optimize for the wrong thing — pretty visualizations, AI features, or per-user revenue. The tools that work optimize for the boring stuff: making capacity visible, surviving sorting, and keeping stakeholders aligned without ten meetings a week.

If you want to try a roadmap tool that combines roadmap + capacity + prioritization + plans + feedback in one workspace (and is built by a PM who uses it daily), try Roadmap OS free. No credit card. Full Roadmap on the free tier.

Either way — go run your roadmap. Honestly. Update it weekly. And don't promise dates as contracts.

SEO Schema (paste into )

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "The Honest Guide to Product Roadmapping (2026 Edition)",
  "description": "What roadmapping actually looks like for working PMs — frameworks, anti-patterns, capacity, prioritization, and the tools that get out of the way.",
  "author": {
    "@type": "Person",
    "name": "Sabelo Velas",
    "url": "https://roadmapos.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Roadmap OS",
    "logo": {
      "@type": "ImageObject",
      "url": "https://roadmapos.com/logo.png"
    }
  },
  "datePublished": "2026-05-01",
  "image": "https://roadmapos.com/blog/hero-roadmap-overview.png"
}
</script>

The Honest Guide to Product Roadmapping (2026 Edition)