roadmapping

A roadmap is not a project plan. It is not a Gantt chart. It is not a list of features with dates next to them. A roadmap is a communication tool that answers one question: given our strategy, what are we doing and why?

Most PMs get this wrong. They open ProductPlan or Aha!, drop features into swim lanes, assign quarters, and call it a roadmap. Then reality hits. An engineer quits. A competitor launches something unexpected. The CEO comes back from a conference with a new obsession. Half the roadmap is irrelevant by week six.

The problem is not that plans change. Plans always change. The problem is that most roadmaps are built to resist change instead of absorbing it. They communicate false certainty — specific features on specific dates — and then the PM spends the rest of the quarter explaining why things slipped.

This page teaches you how to build roadmaps that survive contact with reality. Not by being vague, but by being honest about what you know, when you know it, and how confident you are.

The roadmap sits below strategy

Before you open any tool, understand where a roadmap fits in the product stack. Your product vision and strategy define where you are going and what choices you are making to get there. Your prioritization framework determines what matters most. The roadmap sequences those priorities over time.

If your roadmap cannot trace every item back to a strategic choice, you have a feature list, not a roadmap. And if your strategy says “we are going upmarket to enterprise” but your roadmap is full of consumer engagement features, one of them is lying.

A PM at CarDekho put it well: “Roadmap essentially tells you how you will implement the strategy over the next twelve months, six months, three months.” The time horizon varies. The connection to strategy does not.

Three horizons: the structure that scales

The most durable roadmap structure I have seen across Indian startups and larger companies is the three-horizon model. Not because it is clever, but because it matches how certainty actually works in product development.

Horizon 1 (Now — this quarter): High confidence. You know the problem, you have validated the solution, engineering has scoped it. These are commitments. You can put names and rough timelines here because the work is well-understood.

Horizon 2 (Next — next quarter): Medium confidence. You know the problem space, you have some validation, but the solution is not fully scoped. These are directional bets. You communicate themes and expected outcomes, not specific features.

Horizon 3 (Later — two-plus quarters out): Low confidence. These are strategic bets informed by where the market is heading. You are tracking signals — competitor moves, regulatory changes, technology shifts — but you are not committing resources. These items will move into H2 as you learn more.

The key insight: the further out you go, the less specific you should be. H1 items can be features. H2 items should be problems or outcomes. H3 items should be themes or strategic questions.

At a startup doing monthly releases, your horizons compress: H1 might be two weeks, H2 might be the rest of the month, H3 might be next quarter. At a large enterprise with nine-month release cycles, H1 could span six months. The principle stays the same: match your specificity to your certainty.

Now/Next/Later: the format that kills Gantt charts

The Now/Next/Later roadmap is the three-horizon model stripped to its essence. No dates. No swim lanes. No dependencies drawn with arrows. Just three columns.

Now — what we are actively building. In progress, resourced, expected to ship this cycle.

Next — what we will pick up after the current work ships. Validated, roughly scoped, waiting for capacity.

Later — what we believe is important but have not validated or scoped. Will revisit as we learn.

This format works because it communicates priority without communicating dates. When a sales head asks “when is the Salesforce integration shipping?”, the answer is not “Q3” — it is “it is in our Next column, which means it follows the current work.” That is honest. “Q3” is a guess dressed up as a commitment.

I have seen this format work at companies from five-person teams to hundred-person product orgs. The resistance always comes from the same place: leadership wants dates. We will address how to handle that pressure shortly.

When Now/Next/Later is not enough

Some organizations genuinely need date-based roadmaps. Regulatory deadlines — RBI compliance for a payments company, for instance — are real. Hardware coordination, marketing campaigns tied to events, contractual commitments to enterprise clients. In these cases, pin the date-driven items on the roadmap explicitly and keep everything else in Now/Next/Later. A hybrid is fine. The sin is not having dates; the sin is having fake dates.

Outcome-based vs feature-based roadmaps

The traditional roadmap lists features: “Build Salesforce integration,” “Launch mobile app v2,” “Add bulk export.” An outcome-based roadmap lists problems or results: “Reduce merchant onboarding time from 3 days to 4 hours,” “Increase monthly active power users by 20%,” “Enable self-serve for accounts under 50 employees.”

The difference matters because features can be wrong. You might build the Salesforce integration and discover nobody uses it. The outcome — “reduce merchant onboarding time” — lets your team explore multiple solutions. Maybe the answer is a Salesforce integration. Maybe it is a better API. Maybe it is a simpler onboarding form that eliminates the need for CRM sync entirely.

Outcome-based roadmaps give engineering room to solve problems creatively. Feature-based roadmaps tell engineering what to build and cross their fingers that it works.

In practice, your H1 items will be more feature-specific (you have already validated the solution), and your H2/H3 items should be outcome-oriented (you are still exploring).

Communicating the roadmap without over-promising

This is where most PMs lose credibility. Not in building the roadmap, but in presenting it. Three rules:

Rule 1: Never present a roadmap without the assumptions behind it.

Every roadmap has assumptions. We assume the team stays at current headcount. We assume the API partner delivers on time. We assume customer demand for feature X holds. State these upfront. When an assumption breaks, the roadmap change is expected, not a surprise.

Rule 2: Show what you are saying no to.

A roadmap that only shows what you are building tells half the story. The other half — what you explicitly chose not to build — is what makes the roadmap credible. When a stakeholder sees that their pet feature is in the “Later” column with a clear rationale, they may not be happy, but they know you considered it.

Rule 3: Version your roadmap.

Date every version. When the roadmap changes — and it will — you can show what changed and why. This builds trust over time. “We moved X from Next to Now because customer churn data showed it was more urgent than we thought” is a story of a team that learns and adapts. “We changed the roadmap again” is a story of chaos.

The roadmap review cadence

A roadmap is not a document you build once and forget. It needs a regular cadence of review — not to add more features, but to update your confidence levels and adjust based on what you have learned.

Weekly: Check H1 items against sprint progress. Is anything at risk? Surface blockers early.

Monthly: Review H2 items. Has anything changed — new customer data, competitor moves, internal capacity shifts — that should promote or demote items?

Quarterly: Full roadmap refresh. Update all three horizons. Present to leadership with an explicit “what changed and why” section. This is also when H2 items graduate to H1 (with scoping) or get pushed to H3 (with a rationale).

The monthly review is the one most teams skip, and it is the most important. Without it, your H2 column becomes a graveyard of good intentions that never gets revisited until the quarterly panic.

Different audiences, different roadmaps

Your engineering team, your leadership, your sales team, and your customers all need to see a roadmap. They should not all see the same roadmap.

Engineering roadmap: Feature-level, with dependencies and technical constraints. This is where you can have detailed scope and sprint-level timelines for H1 work.

Leadership roadmap: Outcome-level, tied to business metrics and strategic bets. They care about “will this move the revenue number?” not “will this use REST or GraphQL?”

Sales/customer roadmap: Theme-level, focused on problems being solved. No dates unless you are very confident. The moment you tell a customer “Q3,” they will write it into their contract.

Public roadmap: If you maintain one, keep it to themes only. “We are investing in better integrations” — not “Salesforce integration shipping August.”

The common mistake is building one roadmap and showing it to everyone. Engineering sees strategic fluff they cannot act on. Leadership sees technical details they do not care about. Sales sees dates they should not promise. Maintain one source of truth internally, but present it differently to different audiences.

Roadmap anti-patterns

The feature factory roadmap. Every item is a feature. No outcomes, no metrics, no connection to strategy. The team ships constantly and nothing moves the needle because nobody asked why they were building any of it.

The stakeholder appeasement roadmap. Every powerful stakeholder gets one item on the roadmap. Sales gets their integration. Marketing gets their campaign tool. The CEO gets their AI feature. The roadmap is a political artifact, not a strategic one. Nothing compounds because nothing is connected.

The aspirational roadmap. Every horizon is packed with ambitious items. The team is staffed for 30% of what is on the roadmap, but removing items feels like giving up. Six months later, the team has shipped 20% of H1, nothing from H2, and morale is low because the roadmap made them feel like they were always behind.

The immutable roadmap. Built once per quarter, presented as a commitment, never updated. When reality diverges — and it always does — the PM either hides the divergence or waits until the next quarterly review to acknowledge it. By then, trust is already damaged.

The fix for all four is the same: a roadmap connected to strategy, honest about certainty, reviewed regularly, and presented as a living document that adapts to what you learn.

Roadmapping in the Indian context

A few things that are specific to building roadmaps in India:

Regulatory timelines are real constraints. RBI guidelines, SEBI compliance deadlines, GST changes, data localization requirements — these are not negotiable and they do not care about your sprint velocity. Pin them on your roadmap first, then plan around them. I have seen fintech PMs at Razorpay and similar companies build their entire H1 around regulatory deadlines and fit product innovation into the remaining capacity.

Festival-driven usage spikes shape sequencing. If you are in e-commerce, payments, or consumer tech, Diwali season is your Super Bowl. Your roadmap needs a “stability freeze” period before major festivals where you ship nothing new and focus on performance and reliability. Plan backwards from October.

Distributed teams across time zones need clearer H1 definitions. If your engineering team is split between Bangalore and a US office, ambiguity in H1 items creates more damage than it would in a co-located team. Over-invest in scoping for H1. Write it down in more detail than you think is necessary.

“Jugaad” culture can undermine roadmap discipline. The Indian instinct to find workarounds and ship fast is a genuine strength — until it means the roadmap becomes fiction because everyone is building off-roadmap solutions to unblock sales. If jugaad fixes are consuming more than 10% of engineering capacity, they belong on the roadmap, not in the shadows.

A roadmap is a promise about direction, not about delivery dates. Build it from your strategy, structure it by certainty, communicate it honestly, and update it as you learn. The PMs who earn the most trust are not the ones with the most detailed Gantt charts. They are the ones whose teams and stakeholders always know where the product is going — and believe the PM when they say it.

Where to go next

• Decide what makes the cut: Prioritization Frameworks — RICE, MoSCoW, opportunity scoring, and structured judgment
• Communicate the plan to leadership: Presenting to Leadership — how to present a roadmap to executives without over-promising
• Keep stakeholders aligned: Stakeholder Management — the ROAD update format for weekly roadmap communication
• Connect roadmap to strategy: Product Vision & Strategy — the strategy that makes the roadmap coherent