What a Product Roadmap Is, and 3 Kinds That Fail

Artyom Sklyarov··8 min read

A product roadmap is a plan for which problems the product will solve, in what order, and roughly when, written so it gets less certain the further out it looks. That last part is where most roadmaps go wrong. The common version is a list of features with a date next to each, and it fails the first time a date slips or a feature turns out not to work, which, by Marty Cagan's count, is at least half the time. Three kinds of roadmap fail in predictable ways: the feature list with dates, the stakeholder wishlist, and the twelve-month Gantt chart. One shape holds: commit to problems and outcomes now, stay likely on what is next, and keep the rest as options. Below: what a roadmap is for, the three that fail and why, the one that works, what the tools cost on 26 September 2026, and how it connects to the product strategy it should come from.

Three roadmaps that fail and one that holds: a feature list with dates breaks when the first date slips, a stakeholder wishlist breaks when two requests conflict, a twelve-month Gantt chart breaks when you learn anything, and a Now, Next, Later roadmap holds because it commits to problems and gets less certain further out
Three roadmaps that fail and one that holds: a feature list with dates breaks when the first date slips, a stakeholder wishlist breaks when two requests conflict, a twelve-month Gantt chart breaks when you learn anything, and a Now, Next, Later roadmap holds because it commits to problems and gets less certain further out

What a roadmap is for

A roadmap does two jobs, and Marty Cagan of Silicon Valley Product Group named both in 2015: making sure the team works on "the highest business value items first," and giving the rest of the company "date-based commitments" it can plan around. Everything that goes wrong with roadmaps is one of those jobs crowding out the other.

It is not the strategy. Our product strategy post draws the line: strategy answers why this sequence and not another; the roadmap is the sequence. A roadmap without a strategy behind it is a list of things people asked for, and nobody can say which item to drop when time runs short.

It is also not a backlog. The backlog is every idea and request the team has ever heard. The roadmap is the few that won the argument, in order.

Three kinds that fail

1. The feature list with dates

SSO on 3 March, Dashboard v2 on 17 March, the Slack integration in April. It is the most common roadmap and the easiest to write, and it makes two promises nobody can keep: that each feature will ship on that date, and that each feature will work.

Cagan's first objection, from 2009, is still the sharpest: "To lock in specific features at the roadmap level is to effectively skip the most important part of your job." His second is the arithmetic. In 2015 he wrote that "at least half the ideas on your roadmap are not going to deliver what you hope," and that the strongest teams assume "at least three quarters of the ideas won't perform like we hope." A list of features with dates commits to shipping ideas before anyone knows which half those are. When the first date slips, every date behind it moves, and the list gives nobody a reason to cut anything.

2. The stakeholder wishlist

Sales wants enterprise SSO. The CEO wants AI summaries. The biggest client wants exports, support wants search fixed, the board wants a mobile app. Line them up, estimate each, and you have a roadmap that records who asked rather than what the product is for.

It fails the first time two requests conflict, because there is no principle to settle it except seniority. The loudest voice wins, then the next loudest, and the product drifts toward whoever is in the room. The fix is not to ignore stakeholders; it is to translate each request into the problem underneath it and rank the problems against the strategy.

3. The twelve-month Gantt chart

Bars across a year, dependencies drawn between them, month nine planned with the same confidence as next week. It looks like the most serious roadmap in the building, and it is the most fragile.

It fails because it treats what you know and what you are guessing identically. Janna Bastow, co-founder of ProdPad, puts it plainly: "Timeline roadmaps insist on deadlines, which means product teams are deprived of the flexibility that allows them to do their best work." Cagan calls the dates at that distance "essentially just your hopes and wishes." The chart is not wrong about month one. It is wrong about claiming to know month nine.

The one that holds: Now, Next, Later

The shape that survives contact with reality has three columns and no dates beyond the first.

Now is what the team is committed to, stated as a problem and an outcome, not a feature: cut onboarding drop-off from 60 to 40 percent. The team chooses how.

Next is what is likely, less specific, still a problem: win teams, not just individual users.

Later is what you are exploring and not yet committed to: a mobile app, if usage says so.

The format was popularised by Bastow and Simon Cast, who first used it at ProdPad in 2012 under a different name, "Current, Near Term, Future"; ProdPad's own page credits an early customer with the Now, Next, Later wording, and a reader there points to a Thoughtworks post using similar words the same year. What matters is the logic, in Bastow's words: time horizons "allow you to move forward with a broad plan, yet only make commitments to what lies directly ahead of you."

Cagan arrives at the same place from the other side. His alternative to the feature roadmap is an outcome-based one, "stating the outcome you are trying to achieve rather than the specific feature that may or may not deliver the necessary results," and when a date is genuinely needed, for a launch or a contract, a "high-integrity commitment" made after the team has done enough discovery to know it can keep it.

Basecamp goes further still. In Shape Up it plans one six-week cycle at a time and writes nothing down beyond it: "Even if we have some kind of road map in our heads at the time scale above cycles, we keep it in our heads and in our side-channel discussions." That works for a company that owns its own product and answers to no board calendar. Most startups need to show a Now, Next, Later to investors; Shape Up is the proof that you need less written down than you think.

What the roadmap tools cost

ProdPad's pricing page on 26 September 2026: the Roadmaps module at 44 dollars per seat per month billed annually, with unlimited Now, Next, Later roadmaps
ProdPad's pricing page on 26 September 2026: the Roadmaps module at 44 dollars per seat per month billed annually, with unlimited Now, Next, Later roadmaps

Read from each vendor's own pricing page on 26 September 2026:

ToolFree tierPaid, per editor a monthRoadmap on the plan
ProductboardYes, with limitsPlus $19 billed annually ($25 monthly); Business $59 annually ($75 monthly), with a multi-maker minimumTimeline and column roadmaps on every plan, Free included
Aha! RoadmapsNo, 30-day trialPremium from $59 annually ($74 monthly); Enterprise from $99 ($124)The core product
Jira Product DiscoveryFree for 3 creatorsStandard $10, Premium $25 a creator, monthly billingBoard and timeline views on all plans; cross-project roadmaps on Premium
ProdPadNo, trial of 7 days or moreRoadmaps module $44 a seat annually ($55 monthly)Unlimited Now, Next, Later roadmaps
Strategic Roadmaps (formerly Roadmunk)No, 14-day trialStarter $19, Business $49, Professional $99 an editor, billed annuallyThe core product
LinearYes, 250 issuesBasic $10, Business $16 a user, billed yearlyProjects and initiatives; no separate roadmap product
NotionYesPlus $10, Business $20 a member yearly ($12, $24 monthly)A template or timeline view, not a plan feature
airfocus, ProductPlanNoQuote onlyRoadmaps on every plan

The honest read: for a startup, the tool is the least important decision. A Now, Next, Later roadmap fits on a Notion page or a Linear project view you already pay for. Buy a dedicated tool when several product managers need to share one roadmap across teams and stakeholders need a published view; that is what Productboard, Aha! and ProdPad are built for.

How to write one this week

  1. Start from the strategy. If you cannot say who the product is for and what you will not build, write that first. The roadmap is downstream of it.
  2. Write Now as problems with outcomes. Two or three, each with a number you expect to move. Leave the solution to the team.
  3. Keep Next short and Later honest. Later is a list of options, not a queue. Say so on the page.
  4. Put dates only where they are real. A conference, a contract, a regulatory deadline. Everywhere else, the column is the date.
  5. Review it monthly, not weekly. Basecamp's line applies to everyone: "We don't rethink our roadmap every two weeks." Move items between columns when you learn something, not when someone asks.
  6. Test it. Could someone who joined yesterday read it and say why each item is there, and what would make you drop it? If not, it is a to-do list with a calendar.

Where this comes from

At a startup the founder writes the roadmap, and it becomes a hiring question when the founder can no longer hold direction and ship at the same time. That is the gap the Fractional CPO fills, from $15,000 a month, with direction agreed in writing in the first week. When the direction is set and the next thing is to build, the Product Sprint turns the first Now item into a working product in five days for $9,000. And if you are still deciding what the first item should be, what product strategy actually is is the page to read before this one.

A

Artyom Sklyarov

Founder & Designer at SUUR

More about Artyom →

Have a product idea?

Designed, built, and shipped in about 5 days.

Start a Project