Product Roadmap: What Goes on It, How to Prioritise, and What AI Changes

Somewhere in your company there’s probably a document with 140 items on it, last edited six weeks ago, that nobody opens anymore. And somewhere else there’s a two-column sheet the team actually argues about every fortnight. Only one of those is a product roadmap. The other is a wishlist wearing formatting.

A product roadmap is a shared, living plan for what a team intends to work on, in what order, and why, expressed at the level of problems and outcomes rather than detailed specs. It’s a communication artefact about uncertainty. Not a delivery schedule, whatever your leadership deck implies.

This covers what a roadmap is and isn’t, the five formats worth knowing, how items earn a place on it (arithmetic worked through, because nobody else bothers), a template you can copy, presenting one roadmap to four different audiences, what changes when you’re roadmapping an AI feature, and, honestly, what usually goes wrong.

What Is a Product Roadmap?

A product roadmap is a shared, living plan that shows what a product team intends to work on, in what order, and why, expressed at the level of problems, outcomes or themes rather than detailed specifications. It communicates direction and trade-offs to everyone who depends on the product.

Three words in that definition are doing all the work. Shared, because its value comes from being read by others, not from being correct. Living, because a roadmap that hasn’t changed in a quarter is a document, not a plan. And theme-level, the altitude question, which trips up almost every first-time PM.

Its job was never to predict the future accurately. It’s to make the team’s current thinking inspectable, so other people can plan around it, and disagree with it productively. That shift, from feature-and-date roadmaps toward outcome and horizon-based ones, is a real, documented movement in product practice, credit to people like Janna Bastow and Teresa Torres for pushing it.

Roadmap vs Backlog vs PRD vs Project Plan: The Altitude Question

The roadmap says “we’re going to make invoicing faster this quarter.” A PRD says “the invoice form must autofill GSTIN from a saved customer record and validate it against the government API in under 800ms.” Same work, wildly different altitude, and confusing the two is exactly why roadmaps quietly turn into spec documents nobody can actually read.

A roadmap listing Jira epics with dates isn’t a roadmap. It’s a project plan wearing a roadmap’s clothes, accurate for about a week and useless after. Owning this artefact is a core part of what a product manager’s career path actually looks like, worth knowing if you’re still deciding whether product is the job for you.

What a Roadmap Is Actually For, and Who Owns It

A roadmap does four jobs. Alignment, so everyone plans around the same assumptions. Sequencing, because order is where the real strategy lives. Saying no, arguably its single most valuable output. And accountability, a record of what the team believed and when, which is what makes a proper retro possible.

Here’s a genuinely useful test: if your roadmap has never been the reason you said no to something, you don’t have a roadmap. You have a status report with better formatting.

The PM owns it, meaning accountable for its existence and currency, not deciding it alone. Engineering weighs in on feasibility, design on discovery, sales and support on demand signal, leadership on constraints. If you’re a founder or engineering lead who inherited this because the PM left (very normal, this happens constantly at early-stage companies), the failure mode isn’t your inexperience, it’s having no single named owner. A roadmap owned by committee gets updated by nobody. For more on how ownership shifts as an org grows, how product-based companies are actually structured is worth a look.

The Five Types of Product Roadmap

Timeline roadmaps are what leadership usually recognises, bars against quarters. Honest about date-bound work, dishonest about everything else. Now-Next-Later, originated by Janna Bastow at ProdPad, groups work by confidence instead of date, “Now” holds committed solutions, “Next” holds problems without a chosen solution, “Later” holds directional outcomes only. It’s the cheapest format to keep current, which is why it survives past week two when everything else quietly dies.

Theme-based roadmaps group work under named themes, good for resisting feature creep since a request that doesn’t fit a theme has a natural home: nowhere. Outcome-based roadmaps use rows like “reduce median time-to-first-invoice from 6 minutes to 90 seconds” instead of feature names, the most honest format and the hardest to sell internally, because sales genuinely cannot plan a campaign around a metric. And release plans, version-anchored, what ships in 4.2, aren’t really roadmaps at all, but you’ll meet plenty of people who call them that.

If this is your first roadmap: start with Now-Next-Later, write outcomes into “Later,” and keep a small, separately labelled list of the two or three dates you’ve genuinely committed to. It’s cheap to maintain, honest by construction, and presentable to leadership without a rebuild. Most functioning teams eventually run one roadmap and generate two or three views of it, more on that later.

How Items Actually Get Onto the Roadmap

Prioritisation frameworks don’t tell you what to build. They make your reasoning explicit, turning “the loudest stakeholder wins” into “here’s why this beat that, and here’s the assumption worth challenging.” A score is the start of an argument, not the end of one.

RICE: The One to Learn First

Developed at Intercom, RICE scores a candidate on four inputs: Reach (users affected in a defined period, pick one and never mix periods), Impact (3 / 2 / 1 / 0.5 / 0.25 for massive to minimal), Confidence (100% / 80% / 50%, and be willing to actually use 50%), and Effort (total person-months across every function, not just engineering).

RICE = (Reach × Impact × Confidence) ÷ Effort. Here’s a real quarter’s planning at a fictional GST invoicing app for Indian SMBs, worked all the way through so you can copy the method, not just admire it:

A = (40,000 × 2 × 0.8) ÷ 3 ≈ 21,333. B = (18,000 × 1 × 0.5) ÷ 4 = 2,250. C = (55,000 × 0.5 × 0.8) ÷ 2 = 11,000.

B scored last mostly because nobody knows much about it yet, that 0.5 confidence halved its score, which is the framework working as designed. The right response to low confidence is usually research, not rejection: two weeks of user research raising confidence to 0.8 and revealing Impact is actually 2 gives B = (18,000 × 2 × 0.8) ÷ 4 = 7,200, still below C, but now it’s an informed decision instead of an arbitrary one.

Two traps worth naming. Units silently break RICE, mix a monthly Reach with a quarterly one and the comparison looks rigorous while being meaningless. And RICE structurally favours cheap, wide, incremental work, a foundational data migration scores terribly and may still be the right call. Never let a spreadsheet make a strategic bet for you.

The Rest of the Toolkit

Quick, useful detail on Kano: a decade ago, instant UPI payment was a genuine delight feature in a consumer app. Today its absence is a defect. Delight decays, that’s the whole model in one sentence. And on Ulwick’s opportunity scoring, survey users on importance and satisfaction per job-to-be-done, opportunity roughly equals importance plus whatever gap exists between importance and satisfaction. High importance, low satisfaction, that’s where the value is hiding.

Default advice: RICE for general ranking, MoSCoW when scoping a committed release, Kano when arguing about quality bars. Most teams need exactly one, used consistently, plus the discipline to override it in writing when they do.

How to Build a Product Roadmap, Step by Step

1.   Start from the strategy, or admit you don’t have one. If you can’t state in one sentence who this is for and what you’re trying to change for them this year, stop, a roadmap built on absent strategy becomes a request queue.

2.   Gather inputs from everywhere, and record where each came from. Sales calls, churn interviews, analytics, tech-debt lists, leadership’s bets. Provenance matters later when someone asks why an item exists at all.

3.   Convert requests into problems. “Add a bulk-upload button” becomes “accountants spend 40 minutes re-keying month-end data.” This single habit prevents more feature-landfill than any process rule ever will.

4.   Prioritise using one framework, consistently. Score in a group, out loud. Write down every override.

5.   Choose a format and an honest horizon. Default Now-Next-Later. Most teams can’t actually see past two quarters and should stop pretending otherwise.

6.   Assign outcomes, owners and confidence to every item. No metric, it’s a feature request. No named owner, it’s nobody’s. No stated confidence, it’s a silent promise.

7.   Set the review cadence before you publish it. A fortnightly 30-minute review, same attendees, on the calendar. This is the step almost everyone skips, and the single strongest predictor of whether the thing is still alive in six weeks.

Your first roadmap will be wrong. That’s fine, its job is to be wrong visibly, so people correct it in the open instead of quietly ignoring it.

A Product Roadmap Template You Can Actually Use

The fields worth putting on every row, and why each one earns its place:

A quick filled example, same fictional GST invoicing app, so you can see the habit rather than just read about it: a “Now” item names a solution and an owner (“UPI payment link on every invoice, days-to-payment 26→≤18, Owner: Rahul, In build”). A “Next” item stays a problem on purpose (“Accountants re-key our data into Tally every month-end, dependency on partner API access unresolved, Confidence Low”). A “Later” item is a direction with zero implied feature (“Become the default place an SMB checks its cash position”). Nothing anywhere carries a date.

Add a Parking Lot tab too, most templates skip it and every team needs it, columns for the request, who asked, the date, why not now, and a review date. “No” is a lot easier to say when it means “recorded, and we’ll look again on the 15th,” not “ignored forever.”

On tools: the tool matters far less than the habit. A well-maintained Google Sheet reviewed fortnightly beats an abandoned Productboard instance every single time. Dedicated tools earn their cost once you’ve got multiple squads and real volume to triage, not before. Pick whatever your team already opens daily, since a roadmap in a tool nobody visits is a roadmap that goes stale by default.

Roadmapping for AI Products: When You Can’t Promise It’ll Work

A normal roadmap row implicitly promises: this feature will exist and work by roughly this time. For deterministic software, that’s a fair promise, build it correctly and it works. For an AI feature, building it is not the same thing as it working. You can ship every ticket on schedule and still end up with a feature that resolves 62% of queries when the business needed 85%. There’s no equivalent failure mode in conventional software, and no conventional roadmap format has a column for it.

Three reasons this breaks the usual promise. Capability gets discovered, not specified, you find out what the system can reliably do by building evaluations and testing real cases, so discovery keeps going well into the build phase. Progress isn’t linear, teams building AI features consistently report that going from roughly 70% to 90% task success takes far longer than zero to 70%, so an item that looks “80% done” tells you almost nothing about remaining time. And “done” is a distribution, not a state, launch day gives you a spread of outcomes that keeps moving afterward, because it depends on a model version you don’t fully control.

Plan in Capability Gates, Not Features

The reframe worth stealing: an AI roadmap commits to learning something by a date, not to something working by a date. Replace the feature row with a sequence of gates, each with a pass criterion and an explicit kill option. Worked example, automatic expense categorisation from uploaded bills:

What goes on the roadmap is the gate, not the feature: “Expense categorisation, reach G2 this quarter,” never “ships in June.” It’s more honest with stakeholders, not less, it tells them exactly what they’ll actually know and when. Worth adding a G5 too, cost per successfully categorised bill versus the manual cost it replaces, since a feature that works but costs more per inference than the labour it saves is a business failure dressed up as a technical success. Almost nobody writing about roadmaps mentions inference cost as a planning constraint. It should be one.

Your roadmap now has a supplier you don’t own: the model provider. Versions get upgraded and deprecated without a line of your code changing. Treat re-validating evaluations on model change as scheduled maintenance, with a named owner, the same way you’d treat a framework upgrade. And if the feature learns from customer data, consent architecture is a roadmap item with a legal deadline attached under the Digital Personal Data Protection Act, 2023, not a “we’ll handle it near launch” afterthought. It changes what you can even put in G0. This shift is showing up across how Indian teams are actually adopting AI at work, AI features are quickly becoming routine roadmap items, not a special case reserved for a research team.

How AI Is Changing the Way Roadmaps Get Built

Separate point from everything above: this is about AI as a planning tool, not AI inside the product. Prototyping that used to take two weeks now often takes a day, which raises the bar for entering “Now”, nothing should get committed without either a prototype someone outside the team has used, or a written reason that wasn’t possible.

If validating an idea costs a fraction of what it used to, the correct number of ideas to test goes up while engineering capacity stays flat, so a healthy roadmap should show a visibly higher kill rate, items entering “Next,” getting tested, and getting dropped is the process working. And your effort estimates are quietly going stale: AI-assisted development has changed the cost profile of boilerplate, test scaffolding and integrations far more than distributed-systems design or genuinely novel algorithm work. If your RICE Effort column is still calibrated on a 2023 baseline, what’s actually changing about engineering work is worth reading before you re-baseline it, because your prioritisation is now systematically wrong in one direction, under-ranking exactly the work that got cheap.

What AI still doesn’t do: cluster ten thousand support tickets into themes, genuinely useful. Decide a trade-off, or carry the political cost of telling a large customer no, not a chance. The roadmap is a set of decisions about what not to do, and decisions need someone accountable. That part stays entirely human, which increasingly is what product roles in AI-driven businesses actually consist of.

The Same Roadmap, Four Audiences

The underlying facts don’t change by audience. The altitude, vocabulary and commitment language do. If you find yourself telling leadership something you wouldn’t tell engineering, that’s not tailoring, that’s a problem.

An internal timeline gets shared in an all-hands. A screenshot lands in a sales deck. An AE, closing a big deal, promises the Q3 bar. Procurement writes it into the contract. Six months later, a low-confidence exploratory item is now a contractual obligation with a penalty clause, and nobody involved did anything unreasonable at any single step. That’s the leak, and it’s exactly the kind of stakeholder-mapping problem business analysts formally specialise in solving.

Five defences: never put dates on a slide you don’t control the distribution of. Maintain a separate, dated, sales-facing view rather than letting sales build one off a screenshot. Keep a commitment register, the only place a date is a real promise, requiring explicit product-and-engineering sign-off. Label every dated item with its confidence, everywhere, always. And train sales on the difference between “it’s on our roadmap for later this year” and “we’re actively exploring this, let me connect you with the PM,” same intent, wildly different exposure.

What Goes Wrong With Roadmaps

The feature-request landfill: 140 items, nothing ever removed, because adding an item is the cheapest way to end an awkward conversation politely. Fix it with a hard WIP limit on “Now” (three to five items, no exceptions), the Parking Lot tab, and a quarterly cull where every untouched item gets explicitly killed or re-justified.

Dates that quietly become promises: everyone remembers the date, nobody remembers deciding on it. Fix it with confidence labels on everything and date bands instead of point dates beyond the current quarter.

The roadmap nobody’s opened since week two: last-edited timestamp is six weeks stale, decisions happen in Slack instead. Fix it with a recurring fortnightly review, one named owner, and a visible Last Reviewed column that quietly shames itself into relevance.

The single best diagnostic here: when did your roadmap last cause you to say no to something? Can’t answer that? It isn’t functioning, no matter how good it looks in the deck.

FAQs

What is a product roadmap?

A shared, living plan showing what a product team intends to work on, in what order, and why, expressed as problems or outcomes rather than detailed specs. It communicates direction and trade-offs to everyone who depends on the product.

What should a product roadmap include?

At minimum: the initiative, the problem behind it, a target outcome with a baseline and target, a confidence level, a named owner, dependencies, status, and when it was last reviewed. Detailed requirements belong in a PRD, not here.

What’s the difference between a product roadmap and a backlog?

A roadmap works at theme or outcome level across quarters and is read company-wide. A backlog works at story or task level across days and weeks, mostly read by the delivery team. The roadmap sets direction; the backlog holds the next unit of work.

Should a product roadmap have dates?

Only where you’ve genuinely committed and can be held to it. Dates on exploratory items get read as promises, travel to sales and customers, and eventually become obligations. Use confidence horizons for most items and a separate register for real commitments.

Who owns the product roadmap?

The PM, meaning accountable for its existence and currency, not deciding it solo. Engineering, design, sales and leadership all supply input. In early-stage companies a founder often owns it, which is fine as long as one named person actually does.

How do you build a roadmap for an AI product?

Plan in capability gates rather than features. Since you can’t promise an AI feature will work by a date, commit instead to what you’ll know by that date, evaluation readiness, an accuracy threshold, an acceptable override rate, with an explicit kill option at each gate.

Wrapping Up

A roadmap isn’t a promise about the future. It’s the clearest available statement of what your team currently believes, and what it has deliberately chosen not to do. That’s why format matters less than honesty, why review cadence matters more than the tool, and why AI features force the whole discipline to get more honest, not less.

The roadmap you build this week will be wrong by next month. Update it in public. That’s genuinely the job.

Roadmapping, prioritisation and stakeholder communication are learned by doing them, with feedback, which is hard to arrange on your own. Scaler’s online PGP in Business & AI covers product decision-making, AI-era product thinking, and structured practice with mentor review.