Why No Product Roadmaps

I don't believe in product roadmaps.

Everywhere I've worked and consulted that built roadmaps months and years out, the story ends the same way. The dates start slipping within the first few weeks, a month or two if you're lucky. Somewhere along the way the roadmap itself gets quietly shelved, nobody opens the file anymore, and the teams just work on whatever is actually in front of them. The document dies, but the promises made off it don't. When review season comes around, that shelved list is exactly what everyone gets measured against, and people end up answering for dates that stopped being real a year ago.

Before we argue, let's agree on the document. By roadmap I mean a list of features with 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, and not delivery dates, because those will always exist. The specific document is the problem.

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 my coworkers sucked at their jobs. 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 believed their job was to hand over something 100% correct before anyone else touched it, so they'd spend months and months on concept work getting every detail right. Then they'd hand it to design, and design would come back with the things design always finds. A lot of it didn't work, parts of it made no sense, and whole pieces weren't in the best interest of the user. So the concept went back to the business team, who now judged themselves to be at 60% instead of done, and the grind back toward 100% correct started all over again. Nobody ever stopped to ask whether 100% correct was a real thing. A year, a year and a half, just on designs.

After a year or more of that, development would finally see the designs, for the first time, and they'd say the thing they could have said in week one. These designs won't work with our back-end systems. The screens assumed data the legacy systems didn't have and behavior they couldn't deliver. Nobody had asked, because in waterfall nobody asks the next unit anything until the handoff. So the whole thing went back for a redesign, and the punting started again.

And my favorite part was that more than once we'd make it through all of it, the concept grind, the design loop, the redesign, all the way to testing with working software nearly ready to ship, and the project would just get canceled. The reasons never had anything to do with the software. Somewhere in those two years the world had moved, so the project now cost too much or a competitor had already launched theirs. Two years of work, gone.

They even tried to build MVPs (minimum viable products). 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, what they ended up scoping was still a fully functioning, feature-full app rather than 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 we cut "done" down to answering those two questions, instead of finishing a feature list somebody had committed to a date.

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. The roadmap didn't cause the punting, but it's what turned every slip into a broken promise.

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.

None of it matters once the document leaves your hands, because 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, the belief that once you ship the thing, the 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, and the listed item is the finished feature, so they pour effort into making it handle huge numbers of users and getting it just right before anyone has cheaply tested whether people even want it. 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.

For the record, I have seen a roadmap work once. Across every company I've worked at and consulted for, exactly one delivered real things on time off that document, and they earned it by scoping each piece of work so small it could be delivered with real accuracy. Nothing was bundled into big quarterly releases, and everything was pulled just in time, small piece by small piece. The exception proves the point, because what made their roadmap trustworthy was that they stopped using it the way everyone else does. There's a whole page on that way of working in Just-in-Time Development, once you get to Delivery.

"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, and what sits 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. And this is exactly how companies die.

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, and only after enough of the cheap up-front testing (product people call it discovery) that you actually know you can hit it. A high-integrity commitment is a different animal from a roadmap that, by default, commits to forty dates set a year or more in advance.

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. Finding one is the product team's discovery work, testing in cheap ways to build confidence in a solution before it ever touches the product backlog, the build queue this part's opportunity backlog feeds once a solution has earned that confidence. Engineering's job becomes speed of delivery, shipping in small slices, fast, so each shipped slice hands discovery 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 isn't 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, customers kept. 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, a small yes that sets up the bigger one 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%. Those are the odds you're betting on, and they're worse than they look, because on-time only means they hit the date, not that what shipped was worth shipping. A better roadmap won't fix those odds. Committing to outcomes and letting evidence pick the solutions will.

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.