The Birth of the Modern Roadmap

As a new decade starts, I want to reflect on the advent and growth of something truly important in our industry: the lean roadmap for product managers.

This is the story of how it was invented in a cafe in south London.

Years ago, when I started as a junior product manager, I fell into the role by accident, as many others did. With little training or guidance, I learned a lot by doing or Googling.

One of the first things I came across was the concept of the roadmap. All of the examples online were of timeline roadmaps – essentially Gantt charts. This felt pretty intuitive to me, having had a little bit of training in project management. After all, who doesn’t like the sense of control that a Gantt chart gives you?

Creating a roadmap

I set off on creating my own roadmaps – at first, on paper and whiteboards; soon, digitized in various incarnations: PowerPoint, Excel, and even Microsoft Project played a part in my early misguided product management efforts. 

I didn’t realize my efforts were misguided; my bosses certainly didn’t give me any guidance otherwise. As a matter of fact, they essentially gave me a pat on the head for my colorful, visual timelines of the upcoming product plans, and sent me on my way to go deliver. I don’t think they knew any better either.

Many of you reading along probably know what happened next (as product managers): Deadlines whooshed passed and timelines slipped. Turns out that delivery is hard, especially when you’re hanging your assumptions on made-up estimates! 

At that stage in my career, I didn’t feel comfortable speaking up as a product manager. So I course corrected by adding more buffer and covering for the slipped work. Don’t tell me you haven’t done this too – we all have.

The net result: The added buffer meant that delivery timelines slowly stretched out. We all know that work expands to fill the time given to it. So, the scope would creep, and work would slow down just enough to cause further slipping. I’d have to add more buffer or have to explain to my bosses again why we weren’t delivering on time. It was an insidious, vicious cycle.

And I was sure I was the only product manager who was so bad at her job that she couldn’t deliver a roadmap. I mean, wasn’t everyone else simply making roadmaps, building the features, launching like a boss, and killing it out there?

That’s what it felt like in 2009, and no one was talking about failure in a real way yet.

What changed?

In early 2010, I met Simon Cast, a fellow product manager, at a light-hearted social charity event in London. It was a rarity to run into another product person in those days. We relished the chance to chat and share some stories of our experiences. 

I pointed out that there was a lack of places for product people to meet. This led me to suggest that we work together on running the first ProductCamp in Europe. We went on to run ProductCamp London along with some other product people, just a few months later. This was how we connected with Martin Eriksson. He was just formulating the idea of ProductTank at that time, and we went on to co-found Mind the Product together.

In the meantime, I’d been harboring an idea for software to help me streamline my job as a product manager. This included the roadmapping aspect and the even more tedious spec-writing aspect. I’d even gone so far as mocking up some prototypes and giving the software some names. 

Embarrassingly, I’d gone with Spec-ify for the spec-writing tool and Map-ify for the roadmapping tool.

Simon gave me feedback and advice on the software concept. He helped shape it into a single tool that did both idea backlog management and roadmap management. He brought his skillset in back-end development, combined with my experience with front-end (though my abilities with JQuery are and remain dubious!), and we began building the first version of what was to become ProdPad! 

Simon and I both held roles heading product at different startups in London, and we built ProdPad in our spare time and on our own laptops. We used it to help us do our jobs more effectively.

We had a lot to learn, as this was still a timeline roadmap.

It wasn’t until we started taking our slightly more-market-ready version of ProdPad out to the product people we knew in our circles that we spotted our fundamental error.

You see, we still thought that we were the only product people who weren’t delivering on roadmaps. However, when we released an early version of ProdPad, our eyes opened when we got early feedback: About a month in, our most popular request was to be able to shift multiple items on the roadmap at the same time. 

Had we simply listened to our customers at face value, we might have enhanced the functionality of the roadmap with a multi-select drag-and-drop function so that they could do just that.

But instead, we asked a bunch of why’s

When we got to the bottom of it, it became clear that no one was delivering on the roadmap. The request to move and manipulate multiple items on the roadmap at the same time came from the desire to adjust around slipping timelines and missed deadlines. 

So we asked ourselves: If no one is delivering to a timeline roadmap, what’s the point of the roadmap for a product manager?

I’ll admit that we held on to the timeline format for a few extra months longer than we should have. Sunk cost fallacy, you see. We’d invested a lot of our time building this thing, an all-singing, all-dancing JQuery behemoth that allowed you to add features to a timeline roadmap, stretch and shrink them to the appropriate dates, and drag them into swimlanes. It was incredibly hard to admit that we had been doing our product management jobs wrong for years and that we’d built a useless, misguided tool, and wasted months of work in the process, even as the customer feedback stacked up.

But the feedback was in, and the timeline had to go.

We got together at a cafe that was about halfway between our homes, in south London. Wandsworth, to be precise. (This was long before we had an actual office, after all!) It was nearing the end of 2012. 

We talked about what a roadmap was and what it wasn’t.

A roadmap is a communication tool. It’s strategic. It aims to keep the team aligned and informed about the steps that are needed to reach the product vision. The roadmap needs to show some concept of upcoming initiatives. It should show how it’s connected to the problems the team is meant to solve, and the objectives they are meant to hit. 

A roadmap isn’t a list of features and bugs and work in progress down to the day and week and month. That’s a release planner. 

Simon turned over his napkin, and sketched out three columns:
Current | Near term | Future

He talked me through a concept of time horizons, and three ‘buckets’ with initiatives that could group together ideas, features, or experiments. His concept was underpinned by the idea that initiatives in the Current column were more certain, while the ones in the Future were less certain and fuzzier in scope.

Simon and I both liked the freedom that this format gave, while still delivering on all the points that a roadmap needed to have, to still ‘be’ a roadmap.

We passed the napkin back and forth and made some notes and agreed on a simplified version. I would knock it together with simple front-end code, so Simon could hook it up on the back-end. 

We shuffled the timeline roadmap code to the side. This was an experiment after all, and we had no idea if it would work.

One piece that we didn’t talk about was whether we would still call it a roadmap. We didn’t think about it at first until we saw the result live on the page – a three-column time-horizon roadmap, meekly standing where a timeline roadmap once stood. We debated renaming it but didn’t know where to begin. After all, our website said we had roadmap software, and it did technically meet the criteria. Our new roadmap format was just… different.

Somewhere along the line, the napkin was lost. I wish I’d framed it now.

We launched with no fanfare, as you do when you have no paying customers and a simple MVP bootstrapped product that you built from your bedroom. But our early testers took note.

And they actually liked it! 

What we discovered in our next rounds of feedback was that the format allowed product people to communicate the bigger picture. After all, most companies don’t know how big they’ll be in a year’s time, let alone how fast they’ll be able to deliver! 

Our first version was very MVP. It was simply some boxes you could add to one of three columns pragmatically named ‘Current’, ‘Near Term’, and ‘Future’. Frankly, you could have done it in Trello. The basic format grew into a much richer form of lean roadmapping.

It was right to keep the name ‘Roadmap’ for this new format, even if it didn’t look like the other roadmaps. From feedback, we realized that we were implicitly giving product people permission to step away from the timeline roadmap format. After all, they were giving their team and their bosses a roadmap. It said so, right there at the top of the page, on a real dot com SaaS product, so it must be legitimate! 

By subverting the format and terminology we changed the way that roadmapping was done. Which we appreciated sometime later. It’s a roadmap. But it’s not a usual format roadmap.

We still had a long way to go to find out if our way was any better. We had a lot of listening and learning and iteration ahead of us. 

The Modern Roadmap Evolves

The basic scaffolding of the new roadmap format worked. New testers gave us positive feedback about the time horizon concept regularly. We set out to figure out what we needed, as the functionality of the roadmap was severely lacking.

Since then, over the years, the roadmap has evolved.

• You can link initiatives to ideas in your backlog, so you can see what experiments your team might run in order to tackle each problem on the roadmap
• We made these ideas sortable and then made the workflow stage visible so you could see if it was in discovery or in Jira or wherever else
• We created colorful labels, so you could associate initiatives with objectives. Later, we gave these labels text fields, and later still, we allowed you to link an initiative to multiple objectives
• A set of filters lets you carve up your roadmap into specific views suitable for the job at hand
• We created options to publish and export your roadmap, so you could create versions for your exec team, your sales team, or anyone in between in a flash
• We introduced the concept of product lines and a portfolio view of your roadmap, allowing ProdPad to scale for use in much larger enterprises

These and many more iterations have allowed us to evolve and improve the roadmap in line with today’s best practices. We’ve learned a lot, and continue to learn as the discipline of product management grows and develops. As we move into a new decade, we’re excited to see what comes next! We do not rush to follow the crowd. Through measured, and considered steps forward, we build the right solution, even if it’s not what is expected.

What’s in a name?

Along with evolving the roadmap functionality itself, we’ve seen a lot of change over the decade in how we talk about this new form of roadmapping.

We didn’t know what to call it when we first launched the new roadmap. We just kept the name as is, simply calling it the Roadmap. Internally, we were calling it the ‘time horizon roadmap’, and in conversations with potential customers we would talk about our ‘dateless roadmap’, but none of these ever had a ring to them.

Later on, as the concept caught on, we started hearing about other terms that rang true to our purpose. In 2013, Bruce McCarthy started talking about the idea of using themes on the roadmap. He launched that term into popular consensus: through conversations, he had with Jared Spool, an MTPcon talk, and an article. Problem-focused roadmaps had been simmering under the surface for some time. We all knew there was something inherently wrong with the feature-based roadmap. We were lacking the tools and techniques and vocabulary to do something better.

Theme-based roadmapping was a popular term for a while. We watched it evolve into various other names, including Problem Roadmap, Objective Roadmap, Outcome Roadmap, or as we like to call it, as it derives so heavily from the Lean principles of ongoing learning, the Lean Roadmap. Bruce went on to write the very popular and timely book Product Roadmaps Relaunched, with several other product luminaries. I wrote the foreword, which was an honor. Even more thrilling was seeing the ProdPad Now-Next-Later format roadmap touted as useful in a full-page spread case study. It’s smack in the middle of the book!

It’s been a long journey of discovery. But we’re on the right path, and we’re building the tool that actively helps product people do their job better. I can’t wait to see what we learn in the next decade!

Are you a product manager? If you have any burning questions or want to talk all-things-product, then get in touch. Or, give ProdPad a try by signing up for a free trial.

Looking for more PM advice? Try our product management blog for more top tips.