Why No Product Roadmaps

I don't believe in product roadmaps.

I've seen exactly one company deliver real things on time off a roadmap. One. Everywhere else, the dates slipped and the roadmap got quietly shelved, except for the part where everyone was still held accountable for what was in it. Good or bad. Rarely good.

The one company that did well with the roadmap built scoped work to such a small size it made it possible to deliver with reasonable accuracy. The work wasn't bundled into large quarterly releases, it was all managed in a JIT (just in time) manner. Before we argue, let's agree on the document. By roadmap I mean a list of features, dates attached, the word "roadmap" at the top, shown to leadership and customers as the plan. That artifact is what this page is against. Not planning. Not delivery dates. Those will always exist. That specific document.

Three years, one product

I worked at a very large insurance company for almost three years. In those three years, I shipped one product.

One.

Not because the people were bad. Because the process was waterfall (each business unit would finish its assigned work before handing it to the next), and waterfall plus a roadmap is a machine for burning years. The business team wanted everything 100% correct before anyone else touched it, so they'd spend months and months on concept work. Then they'd hand it to design, and design would say a lot of this doesn't work, doesn't make sense, or isn't in the best interest of the user, and punt it back. The business would say "we're 60% there," grind back toward 100%, and send it over again. A year, a year and a half, just on designs.

Then development would finally get it and say these designs won't work with our back-end systems. Redesign. Punt it back again.

And my favorite part: more than once we'd make it all the way to testing, ready to ship, and the project would just get canceled. Costing too much. Competitors already there. Two years of work, gone.

They even tried to build MVPs. They'd ask the right question, what's the least we can build to get something out, and it still took a year and a half to two years to ship it or watch it die. When the teams discussed MVPs they ultimately were a still fully functioning feature full app. Not a true MVP.

The one product I did ship got out the door precisely because we broke that pattern. It was a telematics app for auto insurance: the kind that sets your premium based on how you actually drive. Instead of building the whole thing and bolting it onto the existing product, we shipped a true MVP. A standalone app, rolled out to a single state, cut down to the few things we needed to answer two questions: do the technical pieces actually work, and do customers actually want this? One state, one stripped-down app, real answers before real money. It shipped because it was the one project that refused to sit and wait for a roadmap to tell it what done looked like.

The insurer isn't an outlier. I've been on projects that ran two and a half, three years, and what they finally deployed wasn't what the customers wanted anymore. By the time they got to deployment, the technology had changed, the users' needs had changed, and they'd overbuilt something people only needed a tenth of.

More roadmap wouldn't have fixed any of this. Every one of those projects already had one. It sat on top of the whole thing, promising dates the process could never hit, and everyone still got held to them.

Dates plus a title equals a commitment

Listing ideas was never the problem. If a roadmap were just a list of ideas, there wouldn't be much harm in it. The problem is the dates, the title, and how it gets portrayed. Any time you put dates on that list and the word roadmap at the top, you've created a commitment, regardless of disclaimers.

You can caveat the document to death. Subject to change. Directional only. Not a promise. Doesn't matter. The moment it leaves your hands, leadership plans around it, sales sells against it, and customers wait on it. You've committed to building something, even if it doesn't solve the underlying problem.

And that commitment goes bad for two reasons.

At least half of your ideas aren't going to work. Marty Cagan calls this the first inconvenient truth about product, almost word for word, in his book INSPIRED, and my own track record agrees with him. Half the items on that confident, dated document are features nobody will use, no matter how sure everyone felt in the planning meeting.

The ones that do work take several iterations to pay off. Even when an idea clears every gate (people want it, you can build it, the business works), it usually takes several rounds of iteration before the implementation delivers real business value. Think of it as time to money. A roadmap shows you the ship date. It says nothing about the gap between shipping and the thing actually paying for itself, and that gap is where the money lives.

So the roadmap hands the whole company a false sense of security: ship the thing, money follows. In reality, iteration isn't a phase you finish. It's a constant for as long as the business exists.

There's a second-order effect, and it's worse. A roadmap tells teams the job is to deliver the listed item, so they pour effort into making it handle huge numbers of users and getting it just right before anyone has validated the thing in a lean way. And the fastest way to fill a roadmap with unvalidated items is to copy them off a competitor's product: the perils of feature parity, the trap you already walked through back in Part 02.

When the unvalidated feature lands flat, the finger-pointing starts. Product blames engineering for the pace, engineering blames product for the spec, leadership blames both for the date. That blame loop isn't a people problem. It's what you get when you measure teams on delivering requested items instead of on whether the customer's problem actually got solved.

Dave Martin, a product leadership coach, has a whole piece on exactly this, titled "How Product Roadmaps Kill Outcomes." He's right.

Underneath all of it sits an uncomfortable fact: humans are horrible planners. We believe almost everything will take much less time than it actually does. Daniel Kahneman and Amos Tversky named this the planning fallacy decades ago, and every slipped quarter you've ever lived through is that fallacy in action. A dated roadmap is a rocking chair: it gives the whole org something to do and gets you nowhere. If you've seen Van Wilder, you already knew that.

"But leadership needs a plan"

I know. And they're not wrong to ask. You can't walk into an executive meeting with "trust me, we'll figure it out." Businesses have contracts, seasons, and regulators, and some dates are real.

The answer is two swaps: outcomes instead of solutions, and time horizons instead of dates.

An outcome-based roadmap is still a document you can put on a wall. But every item on it is tied to a goal, written as the outcome you're driving, not as "X is being delivered." Instead of Q3: launch the billing portal, it reads more like reduce the time customers spend paying us. Instead of ship dates, the items sit in time horizons: what you're driving at now, what comes after that, what's further out. The whole company can still see where product is headed and talk about it. What they can't do is lock product and engineering into one specific solution a year before anyone has validated it.

It's still a commitment. That's the part people miss. You're committing to solving a problem and moving a number, which is a harder commitment to fake than shipping a feature. As I've said for years: it is a lot easier to deliver output than it is to deliver outcomes. Outcome is measuring how well you're solving the customer's problem. Output is measuring how much stuff you put out the door. A feature can ship exactly on its roadmap date and deliver nothing.

When a date is genuinely real, you still commit to it. Marty Cagan calls this a high-integrity commitment: you make it deliberately and rarely, after enough discovery work that you actually know you can hit it. That's a different animal from a roadmap that commits to forty dates a year or more out by default.

And when an executive presses you for timing anyway, give a range. This will take eight to twelve weeks. Never "exactly eight." They know you're going to be wrong. You know you're going to be wrong. The range is honest, and it sets you up to under-promise and over-deliver instead of the reverse.

This format pairs naturally with OKRs (objectives and key results, the goal-setting format many companies run on), because both run on the same fuel: a measurable outcome instead of a list of deliverables.

The format also clarifies who does what. Once the roadmap stops dictating a solution, somebody has to go find one. That's the product team's discovery work: testing in cheap ways to build confidence in a solution before it ever touches the product backlog. Engineering's job becomes speed of delivery: shipping in small slices, fast, so discovery gets real-world results to learn from. Uber's engineering team has written publicly about the experimentation platform they built to run exactly this loop at their size: a system that lets teams test a change on a small slice of users and feed the results straight back into what gets built next. (Uber Engineering, Building an Intelligent Experimentation Platform.)

You'll have to sell it

An outcome-based roadmap is not what people are used to seeing. The first time you put one in front of a leadership team raised on Gantt charts (the bar-by-bar timeline view of who ships what by when), somebody will ask where the dates went. Count on it. Lead with the numbers. Executives run on return on investment, so tie every outcome on the document to money: revenue protected, cost removed, churn avoided. The format actually helps you here. "Reduce time-to-pay" is already written in the language of business results. "Launch the billing portal" isn't.

Give ranges, not dates. When they ask where the dates went, this is your answer: anything close enough to estimate gets a range, and everything else sits in a time horizon. Executives have been burned by enough exact dates to know a range is the more honest offer.

Don't sell two changes in one meeting. Asking leadership to buy a new roadmap format is already one buy-in conversation. Don't stack a methodology overhaul on top of it. Work within whatever delivery process the company already follows and change the document first. The futurist Jim Carroll has a line for this: think big, start small, scale fast. One team, one outcome-based roadmap, one planning cycle. Let the results sell the rest.

Make the ask easy to say yes to. Don't ask them to abolish roadmaps. Ask them to try this format alongside the old one for a quarter. Small yes now, bigger yes later.

Poll the companies that run off roadmaps and you'd be hard-pressed to find many that deliver Gantt-chart-style and do it on time. The data backs the gut check: across tens of thousands of software projects, the Standish Group's long-running CHAOS research has pegged on-time delivery at around 40%. And on-time only means they hit the date, not that what shipped was worth shipping. Those are the odds you're betting on, and they're worse than they look. The fix isn't a better roadmap. It's committing to outcomes and letting evidence pick the solutions.

How an outcome earns its place on that roadmap is the loop you just walked through, Steps 1 through 6. The destination those outcomes serve is your vision and strategy, back in Parts 02 and 03. And next, we'll run one problem through the entire loop, start to finish, so you can watch the whole thing work.