How to create Roadmaps?

Roadmaps are a very important part of the Software Development Lifecycle (SDLC). This is supposed to be a short guide of how to write roadmaps and what, over the years, I have personally found to be useful and what to avoid.

Northstar

Your team needs to know what the direction is. Where are we all headed? And why?

Having your team know what’s coming, and why, and ideally having them be excited about it, is absolute key for delivering good software or a good product. And you will only ever get them to 100% if you do that well.

One of the classical tools for achieving that is a roadmap. It’s NOT a detailed execution plan, it’s a northstar. Where do we go, why, and why is it amazing?

Ideally you want a short term roadmap, which is just for the next sprint, a mid term one for up to a year, and a long term one for ~ 3 years.

Now/Next/Later

I recommend a very common agile type of roadmaps: Now/Next/Later.

This format divides your roadmap into three time-based buckets:

• NOW: What you’re actively working on (current sprint or next 4-6 weeks). These are committed items with clear scope and owners.
• NEXT: What’s coming up (1-3 months). These items are prioritized and roughly scoped, but details may still evolve.
• LATER: The backlog and future vision (3+ months). These are ideas, experiments, and strategic bets that may or may not happen.

The beauty of this approach is that it acknowledges uncertainty. The further out you look, the less specific you can be, and that’s okay. It prevents teams from over-committing to features that might not make sense by the time you get to them.

Why Now/Next/Later

The reason this format works so well is rooted in the pyramid of knowledge:

1. What you know: Your current sprint, active work, and immediate priorities
2. What you know you don’t know: Upcoming features that need research, design, or technical spikes
3. What you don’t know you don’t know: Future unknowns, market changes, and evolving customer needs

The traditional waterfall model forced teams to pretend they could predict everything months or years in advance. Creating roadmaps with specific dates for specific features is an outdated way of planning and should not be practiced. Decades of empirical evidence in the IT industry have shown that these estimates are barely ever correct. If you planned linearly on them, you will have to trash your entire plan and create a new one whenever reality diverges from your predictions.

This is why “agile” is so common. The Now/Next/Later format embraces that.

Alternatives

While Now/Next/Later is my preferred approach, there are other common roadmap formats:

• Theme-Based Roadmaps: Organize work around strategic themes (e.g., “Performance,” “Security,” “User Experience”) rather than time buckets
• Release-Based Roadmaps: Tied to specific version releases (v2.0, v2.1, etc.)
• Outcome-Based Roadmaps: Focus on desired outcomes and metrics rather than features
• Gantt Charts: Traditional timeline-based visualization with dependencies (useful for infrastructure projects with hard dependencies)

Format for Different Time Horizons

Which format you use can vary based on your audience and timeframe:

• Short and mid-term: Now/Next/Later or Theme-Based roadmaps work well for quarterly planning
• Long-term: Often outcome-Based or Theme-Based roadmaps are best, as specifics will change

The Process Behind the Roadmap

A roadmap isn’t created in a vacuum. It’s the output of several processes:

1. Requirements Engineering: Gathering and prioritizing stakeholder needs
2. Stakeholder Involvement: Regular sync-ups with product, engineering, sales, and customer success
3. Prioritization Frameworks: Using methods like RICE (Reach, Impact, Confidence, Effort) or MoSCoW (Must, Should, Could, Won’t)
4. Presentation Format: PowerPoints or slides for executive reviews, living documents (Confluence, Notion) for teams, visual tools (Jira Roadmaps, ProductBoard) for day-to-day tracking

The key is keeping the roadmap a living document. Review it regularly (monthly or quarterly), adjust based on learnings, and communicate changes transparently to all stakeholders.

Example: Employee Onboarding Portal

Here’s a real-world example of a Now/Next/Later roadmap:

Product Roadmap: Employee Onboarding Portal (Internal)

Last Updated: November 20, 2025
Product Owner: Sarah Jenkins (HR Systems)
Tech Lead: David Chen
Theme: Stability, IT Automation, and New Hire Experience

NOW (Current Focus)

Timeline: Sprint 12–13 (Next 4 Weeks)
Strategic Goal: System stability and resolving critical IT provisioning bottlenecks.

NEXT (Up Next)

Timeline: Sprint 14–16 (Months 2–3)
Strategic Goal: Improving the “Day 1” experience for the new employee.

LATER (Backlog / Discovery)

Timeline: Q2 2026+
Strategic Goal: Full automation and scaling for other departments.