Every roadmap argument comes down to two questions. Should the "what" be features or goals? Should the "when" be dates or loose horizons? The ten approaches below are different answers to those two questions, one per section, with its strengths, its weaknesses, and a link to the person who introduced it.
I'm not going to pick a winner. A 2003 Dutch study of 78 sector-level roadmapping initiatives concluded that "no single format is suitable for all situations." A 2023 vendor taxonomy of nine roadmap types concludes that "there's no right roadmap." Twenty sources sit behind this piece, mostly the originators' own texts. They describe the approaches. None of them compares outcomes.
The technology roadmap (1970s)
Engineering companies used the word before software did. Clive Kerr and Robert Phaal of Cambridge traced the practice to NASA in the early 1960s. Boeing, GE, Lockheed, the US Air Force, and the US Department of Energy followed. Motorola formalized it in the 1970s. Its first published roadmap was for car radios and looked ten years ahead. The semiconductor industry published the first sector-wide roadmap in 1992.
The format is a chart with several layers on one time axis. Market drivers sit at the top, products in the middle, technologies at the bottom. Phaal frames the job as weighing "market pull" against "technology push." Motorola also required a "minority report" with each roadmap, so ideas without consensus still reached senior management.
Phaal and the Motorola authors list roughly the same benefits.
- Communication across functions. The roadmap is built in workshops, and the consensus is the product.
- The value sits mainly in the discipline of the process, not necessarily in the finished document.
The full method creates two costs for many software teams.
- It was built for hardware programs with multi-year lead times. Phaal notes that work is needed before, between, and after the workshops, and a facilitator helps.
- As I read the history, software kept the time axis and dropped the market and technology layers.
Read the full argument in Robert Phaal's Roadmapping for strategy and innovation.
The feature timeline
Features on a Gantt chart, each with a start, an end, and a release date, a year or more ahead. This is still the most common format in Stefan Trieflinger's interview study of German software companies. Janna Bastow, who built a roadmap tool on it before abandoning it, describes it as "essentially Gantt charts."
It does two things well.
- Everyone can see what is being built and when. Savio's taxonomy lists that as its main strength.
- Launches, marketing campaigns, and sales teams often need dates, and a timeline provides them.
Its problems show up in changing markets. Trieflinger is explicit that it works in predictable, stable ones.
- In uncertain markets, estimates for work a year out are guesses. Melissa Perri described a team crunching for weeks on leftover features from last year's roadmap that had been written into customer contracts.
- Dates get read as promises. Trieflinger found that stakeholders treat a dated feature as a commitment. Non-delivery becomes a "broken promise."
- A fully allocated roadmap leaves little room for learning. Perri notes that companies revisit it two to four times a year, too slowly to act on feedback.
- Features outlive the problems that justified them. By the time the epic starts, Perri writes, the original problem has faded to a rumor.
Read the full argument in Stefan Trieflinger's Why Feature-Driven Product Roadmaps Fail in the Digital World.
Impact mapping (2012)
Gojko Adzic published Impact Mapping in October 2012. His argument was that traditional plans are "shopping lists of features, without any context why such things are important."
An impact map is a mind map with four levels. The goal in the center answers why. The actors around it answer who can produce or block the effect. The impacts answer how those actors' behavior needs to change. The deliverables come last. Prioritization runs backward from the goal.
Adzic makes two claims for it.
- Every deliverable is chained to a goal through a behavior change. A deliverable that supports no impact has no reason to exist.
- The chain exposes two assumptions that can be measured after shipping. Did the deliverable change behavior? Did the behavior move the goal? If not, work moves to a different branch.
The sources I found were written by proponents rather than critics, so the following limitations are mine.
- It needs a measurable goal at the center. Many teams do not have one, and the map cannot supply it.
- It covers why and what, but not when. Anyone who needs dates still needs a second document.
Read the full argument in Gojko Adzic's Impact Mapping.
Now-Next-Later (2012)
Late in 2012, Bastow's ProdPad co-founder Simon Cast sketched three columns on a napkin: Current, Near term, and Future. They had learned from their own product that nobody was delivering against a timeline roadmap. They kept calling the new format a roadmap. Bastow says that, more by accident than by design, this gave product people permission to step away from the timeline.
In its current form, Now holds work that is specified and in progress. Next holds the problems the team expects to pick up after that, with less detail. Later holds big, hazy problems kept on the radar without commitment.
Bastow gives two reasons it stuck.
- Certainty is portioned out over time instead of being faked for everything.
- Commitment lives elsewhere. The roadmap shows the plan, and the OKRs carry the commitment.
She also says where it goes wrong.
- "The format was always the easy part. The hard part was helping people get comfortable trading dates for horizons."
- Teams must define what each column means. Otherwise, in her words, "a horizon with no shared definition just becomes a vaguer timeline."
- Savio's taxonomy adds the usual critique of dateless formats. Developers and executives often want more specifics than three columns offer.
The same shape appears under other names. In October 2015, Paul Adams at Intercom proposed planning over the next 6 years, 6 months, and 6 weeks, with the six-month plan expected to be only 50-75% right. Teresa Torres refers to a Now/Next/Future roadmap. Ash Maurya uses 90 days, 6 months, and 18 months. SAFe commits one planning interval and forecasts the next one or two.
Read the full argument in Janna Bastow's Why I Invented the Now-Next-Later Roadmap.
Goals, themes, and problems instead of features (2013-2014)
Within about eighteen months of the napkin, three descriptions of a related idea were published. Each kept some structure but replaced features with intent. Pichler says his format existed before he packaged it, so these are publication dates, not birthdays.
Roman Pichler's GO (goal-oriented) roadmap came out in November 2013. Each column has five rows. The first three are a date or time frame, a release name, and a goal such as "acquire new users." Then come the features, ideally three and never more than five, and the metrics that show whether the goal was met. Pichler keeps dates for internal roadmaps because some goals are date-bound. A game that must ship before Christmas is his example.
Bastow credits theme-based roadmaps to Bruce McCarthy in 2013. In C. Todd Lombardo's version, a roadmap has a vision, business objectives, broad time frames, a disclaimer, and themes at the center. A theme is a problem plus an objective plus a few candidate ideas. Features move to a separate release plan.
Melissa Perri's problem roadmap from May 2014 goes one step further. Each cross-functional team gets a prioritized customer problem and a KPI for a time box, a quarter in her example. The team validates the problem, then ships minimal solutions with frequent releases. James Dumay's 2018 version adds one rule. A problem stays on the roadmap until a shipped solution is validated in the field.
All three aim at the same problem.
- The roadmap states the goal instead of the feature. Pichler's complaint was that feature roadmaps make agreement hard and duplicate the backlog.
- Teams get room to choose the solution, because the roadmap no longer names it.
They also share the same costs.
- Savio's taxonomy notes that goal and outcome roadmaps lack granularity for developers and often for executives. Outcomes are also harder to define and measure.
- Cagan's objection is that an outcome on its own is not enough context. Teams also need the product vision, or the goals float.
Read the full arguments in Roman Pichler's The GO Product Roadmap and Melissa Perri's Rethinking the Product Roadmap.
Vision plus OKRs instead of a roadmap (2015)
Marty Cagan published "The Alternative to Roadmaps" in September 2015. His diagnosis is that roadmaps come from a "centralized command-and-control model." Stakeholders meet, usually each quarter, and hand teams a list of features. The list says what to do, not what problem it solves. If "integrate PayPal" is on the roadmap, is it about customers who cannot pay, about fees, or about a competitor?
He admits that the two needs a roadmap serves do not go away. Management wants the highest-value work done first, and a business sometimes has to commit to a date. His replacement has three parts: a product vision for context, a prioritized set of business objectives per team managed as OKRs, and "high-integrity commitments" for the few real dates. His FAQ adds that some companies track those commitments in a Plan of Record. Typically only the CTO or VP of Engineering can add to it.
The example objective is cutting new-customer onboarding from 30 days to under 3 hours. The team is free to find its own way there.
He says teams behave differently under this model.
- Teams that are free to solve the problem are more motivated.
- A team is not done when the feature ships. It is done when the key result moves.
Two weeks later, his FAQ listed the frictions.
- Organizations attached to the quarterly roadmap take time to move. He advises keeping the old process for 6 to 12 months while attaching every feature to its outcome and reporting the result after launch.
- The Plan of Record is, as far as I can tell, a small roadmap by another name.
Read the full argument in Marty Cagan's The Alternative to Roadmaps and his follow-up, Roadmap Alternative FAQ.
The opportunity solution tree (2016)
Teresa Torres introduced the opportunity solution tree in 2016. It is less a roadmap than the thing that feeds one. A desired outcome sits at the root. Below it sits the opportunity space: the customer needs, pain points, and desires heard in interviews. Below the chosen opportunity sit candidate solutions, three in her recommended process. Below those sit the assumption tests that decide between them.
Torres is strict about inputs. Before the first tree, a team needs a theory of its target customer and value proposition, a defined outcome, and three or four story-based customer interviews. She recommends interviewing continuously and revising the tree every three or four interviews. In her words, the trees "are nearly impossible to create when you don't have good inputs." She recommends one outcome per team and advises against a company-wide tree because "it never turns out well."
Her guide is explicit about how the tree meets the roadmap.
- With a date-based roadmap, the document shows the solutions already vetted on the tree. The tree holds the reasoning, and the roadmap is what gets shown.
- With an outcome-oriented roadmap of the Now/Next/Future kind, opportunities, solutions, and upcoming outcomes from the tree can all appear on it.
She names most of the limits herself.
- The prerequisites are heavy. Continuous interviewing, typically weekly, is the intended input. A tree drawn from opinions defeats its own purpose.
- It is scoped to one team and one outcome. It is not a company plan, and she recommends a KPI tree for that job.
Read the full argument in Teresa Torres's Opportunity Solution Trees.
Shape Up (2019)
Basecamp's answer, written up by Ryan Singer in 2019, is not to write a roadmap down. Work runs in six-week cycles followed by a two-week cool-down. A small senior group "shapes" a project before it is scheduled. Instead of asking how long the work would take, they set an "appetite," which is how much time the idea is worth.
During cool-down, a betting table picks which shaped pitches get the next cycle. At Basecamp, the four people at that table are the CEO, the CTO, a senior programmer, and a product strategist. There is no backlog and no grooming. If a project overruns, it gets no extension by default. Singer calls that the circuit breaker.
Only one cycle is bet at a time. His line on the longer view is that "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."
Singer's case is about getting things shipped.
- Two-week sprints, in Basecamp's experience, were too short to finish anything and too costly in planning overhead. Six weeks is long enough to finish something and short enough to feel the deadline.
- The circuit breaker stops runaway projects and forces a rethink instead of granting more time.
The book is also frank about what it does not do.
- Shape Up targets the risk of not shipping, not the risk of building the wrong thing. Singer says so directly.
- It works because the people at the table have final authority. There is "no step two." Companies where product decisions need sign-off from elsewhere do not have that table.
- Anyone who needs to know what is coming beyond six weeks, such as a sales team or a customer with a contract, gets a conversation rather than a document. I take that from the "in our heads" line.
Read the full argument in Ryan Singer's Shape Up.
The SAFe roadmap
Large organizations kept the dated roadmap and split it. The Scaled Agile Framework defines the roadmap as "a schedule of events and milestones that forecasts and communicates planned solution deliverables over a time horizon." That is closer to Motorola than to any of the reformers. This section follows the SAFe 6.0 text from May 2024, the last version that was fully public.
SAFe has three roadmaps. The planning-interval roadmap covers the committed current interval plus one or two forecast intervals. The solution roadmap runs several years, planned in quarters, then half-years, then years. The portfolio roadmap spans value streams.
The central rule is the line between committed and forecast. Only the current interval is a commitment, made at planning. Everything later is a forecast. Product management generally leaves capacity unfilled, because a fully loaded roadmap becomes a queue. SAFe's own arithmetic is that five fully committed ten-week intervals push the wait for any new feature past 50 weeks. Its text also says that "every long-term commitment decreases the agility of the enterprise."
SAFe argues for dates in terms the reformers rarely address.
- Customers and partners need lead time to plan their own changes. Regulators publish deadlines.
- Markets have rhythms. A toy maker or a retailer that misses the holiday season may deliver zero value that year, whatever the outcome metric said.
It keeps several risks of a dated roadmap and adds scale.
- Trieflinger's critique of feature-driven roadmaps applies to the forecast intervals as soon as someone reads them as promises.
- Three roadmap levels are a lot to keep aligned. Savio's note on portfolio roadmaps is that they get complex and lose the detail teams need.
Read the full 6.0 text in the archived Roadmap page. The current page lists PI, product and solution, and portfolio roadmaps, and sits behind a login past its introduction.
The traction roadmap (2026)
The newest entry rejects the conventional product roadmap but keeps the roadmap label for its replacement. In February 2026, Ash Maurya wrote that founders love product roadmaps because they "give you a false sense of control over the next 18-24 months." Roadmaps assume you already know what to build. They drag a startup back into waterfall planning, where deviation looks like weakness. His replacement measures one thing: the rate at which the business produces happy, paying customers.
A traction roadmap starts three years out with a Minimum Success Criteria, the smallest result that would count as success, and works backward in 10X steps. His worked example is $1M ARR in year three, or roughly 830 customers at $100 a month. Working backward, that means about 83 customers in year two, about 8 in year one, and a 90-day goal after that.
The team defines one traction metric and breaks it into a funnel: acquisition, activation, revenue, retention, and referral. It measures the funnel weekly and puts 80% of its effort into the biggest constraint. The rollout uses Now, Next, and Later horizons of 90 days, 6 months, and 18 months.
I can see why this appeals to founders.
- Maurya's point is that a product roadmap can be "on track" while the team builds something nobody wants. A traction number cannot hide that.
- Working backward from a floor forces a concrete next milestone.
Beyond founders, it covers less.
- It is written for early-stage companies. The source says nothing about a team maintaining a mature product with existing customers and contracts.
- It tells you what to measure. It does not tell you what to build. I think a team still needs something like a tree or a problem list to choose the next experiment.
Read the full argument in Ash Maurya's Say no to product roadmaps.
What changed, and what did not
Read in order, the ten formats tell a fairly simple story. The roadmap started as a multi-layer strategy chart for hardware. Software kept the time axis and filled it with features. Around 2012, two reactions to that were published within a couple of years of each other. My reading is that they answered the same frustration, but the sources show the timing, not the cause.
Some teams removed the dates. That is Now-Next-Later and its cousins. Some replaced features with goals or problems. That is the GO roadmap, themes, problem roadmaps, OKRs, and opportunity trees. A third reaction came later. Shape Up dropped the written roadmap and bet one cycle at a time. Maurya took a different route. He kept the Now-Next-Later shape but replaced delivery milestones with traction milestones. Large organizations kept the dated roadmap and drew a line between committed and forecast.
What strikes me most is how often the same shape gets rediscovered. The three-column layout shows up five times on this list under five names. The disagreement is about what goes in the columns (features or problems) and who is allowed to make a promise.
I didn't find much about the pandemic in these sources. The only remote-work note is Basecamp's, and it predates 2020. Their team had gone fully remote by 2015, and the loss of hallway intuition is one reason they wrote their process down. My own guess is that remote work pushed teams toward more explicit artifacts rather than fewer.
AI appears in three of the sources, but only one connects it to how a roadmap should handle uncertainty. Bastow's retrospective, updated since 2022, argues that with shipping velocity climbing, "dated roadmaps fail even harder than they used to, because the timeline is obsolete within weeks," and that horizons absorb the change.
Torres licenses AI services to a tool vendor that generates opportunity trees from customer interviews. Maurya's newsletter ends with a plug for a tool that generates a traction roadmap from a Lean Canvas. None of the three argues for giving up planning altogether. My reading is that if building is cheaper, the document that says why you are building matters more.
So do we still need roadmaps? John Cutler's answer from 2016 is the one I keep coming back to. Ask what job you are hiring the roadmap for, and whether it is the best tool for that job. He lists the needs a roadmap usually serves, from "the board keeps asking us for our roadmap" to "we need to coordinate with marketing, training, and support."
Cagan says two of those needs never go away. SAFe adds regulators and holiday seasons. Basecamp, as I read it, meets the need with a conversation. So the needs a roadmap serves are still there. What has changed is how many of them one document is expected to carry.
I'm curious how your roadmap looks today compared with five years ago. Did the dates go, did the features go, or did the document go entirely, and what replaced it?
Thanks for reading!
Sources
- University of Cambridge repository (Technological Forecasting & Social Change), "Technology roadmapping: Industrial roots, forgotten history and unknown origins" (Clive Kerr, Robert Phaal), February 2020.
- Institute for Manufacturing, University of Cambridge, "Roadmapping for strategy and innovation" (Robert Phaal), March 2015.
- ProdPad, "The Birth of the Modern Roadmap" (Janna Bastow), December 2019.
- ProdPad, "Why I Invented the Now-Next-Later Roadmap" (Janna Bastow), October 2022, updated since; accessed September 2026.
- Jeff Patton & Associates, "The New User Story Backlog is a Map" (Jeff Patton), October 2008.
- impactmapping.org, "Impact Mapping" (Gojko Adzic), October 2012.
- Roman Pichler, "The GO Product Roadmap" (Roman Pichler), November 2013, updated January 2026.
- Melissa Perri, "Rethinking the Product Roadmap" (Melissa Perri), May 2014.
- Intercom, "The 666 roadmap" (Paul Adams), October 2015.
- SVPG, "The Alternative to Roadmaps" (Marty Cagan), September 2015.
- SVPG, "Roadmap Alternative FAQ" (Marty Cagan), September 2015.
- Medium, "Stop Setting Up Product Roadmaps To Fail" (John Cutler), April 2016.
- Medium, "The Product Roadmap Is Dead: Welcome to the Age of Problem Roadmaps" (James Dumay), April 2018.
- Mind the Product, "Roadmaps are dead! Long live roadmaps!" (C. Todd Lombardo, written up by Emily Tate), August 2018.
- Basecamp, "Shape Up: Stop Running in Circles and Ship Work that Matters" (Ryan Singer), 2019.
- Savio, "9 Types of Product Roadmaps: Pros, Cons, and When to Choose Each One" (Kareem Mayan), May 2023.
- Product Talk, "Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes" (Teresa Torres), December 2023, living guide; accessed September 2026.
- Medium, "Why Feature-Driven Product Roadmaps Fail in the Digital World" (Stefan Trieflinger), January 2024.
- Scaled Agile, "Roadmap" (SAFe 6.0 text, Wayback Machine snapshot of June 2024), May 2024. The live page was revised in February 2025 and is gated behind a login past its introduction.
- Ash Maurya, "Say no to product roadmaps." (Ash Maurya), February 2026; accessed September 2026.