{"id":7243,"date":"2019-12-31T11:31:30","date_gmt":"2019-12-31T11:31:30","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=7243"},"modified":"2025-01-13T16:27:00","modified_gmt":"2025-01-13T16:27:00","slug":"the-birth-of-the-modern-roadmap","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/the-birth-of-the-modern-roadmap\/","title":{"rendered":"The Birth of the Modern Roadmap"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

This is the story of how it was invented in a cafe in south London.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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

Creating a roadmap<\/h2>\n\n\n\n

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. <\/p>\n\n\n\n

I didn’t realize my efforts were misguided; my bosses certainly didn\u2019t 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\u2019t think they knew any better either.<\/p>\n\n\n\n

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\u2019re hanging your assumptions on made-up estimates! <\/p>\n\n\n\n

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\u2019t tell me you haven\u2019t done this too – we all have.<\/p>\n\n\n\n

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\u2019d have to add more buffer or have to explain to my bosses again why we weren\u2019t delivering on time. It was an insidious, vicious cycle.<\/p>\n\n\n\n

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

That\u2019s what it felt like in 2009, and no one was talking about failure in a real way yet.<\/p>\n\n\n\n

What changed?<\/h2>\n\n\n\n

In early 2010, I met Simon Cast, a fellow product manager, at a light-hearted social charity event in London<\/a>. 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. <\/p>\n\n\n\n

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<\/a> along with some other product people, just a few months later. This was how we connected with Martin Eriksson<\/a>. He was just formulating the idea of ProductTank<\/a> at that time, and we went on to co-found Mind the Product<\/a> together.<\/p>\n\n\n\n

In the meantime, I\u2019d 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\u2019d even gone so far as mocking up some prototypes and giving the software some names. <\/p>\n\n\n\n

Embarrassingly, I\u2019d gone with Spec-ify for the spec-writing tool and Map-ify for the roadmapping tool.<\/p>\n\n\n\n

\"ProdPad
Initial concepts for Map-ify and Spec-ify that inspired ProdPad<\/em><\/figcaption><\/figure>\n\n\n\n
\"Early
Early prototype of Map-ify<\/em><\/figcaption><\/figure>\n\n\n\n

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! <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

We had a lot to learn, as this was still a timeline roadmap.<\/p>\n\n\n\n

\"Early
One of the early versions of ProdPad\u2019s first roadmap feature<\/em><\/figcaption><\/figure>\n\n\n\n

It wasn\u2019t 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.<\/p>\n\n\n\n

You see, we still thought that we were the only product people who weren\u2019t 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. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

But instead, we asked a bunch of why\u2019s<\/em><\/h2>\n\n\n\n

When we got to the bottom of it, it became clear that no one<\/em> 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. <\/p>\n\n\n\n

So we asked ourselves: If no one is delivering to a timeline roadmap, what\u2019s the point of the roadmap for a product manager?<\/p>\n\n\n\n

I\u2019ll admit that we held on to the timeline format for a few extra months longer than we should have. Sunk cost fal<\/a>lacy, you see. We\u2019d 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\u2019d built a useless, misguided tool, and wasted months of work in the process, even as the customer feedback stacked up.<\/strong><\/p>\n\n\n\n

But the feedback was in, and the timeline had to go.<\/a><\/p>\n\n\n\n

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<\/a>, after all!) It was nearing the end of 2012. <\/p>\n\n\n\n

We talked about what a roadmap was and what it wasn\u2019t.<\/p>\n\n\n\n

A roadmap is a communication tool. It\u2019s 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\u2019s connected to the problems the team is meant to solve, and the objectives they are meant to hit. <\/p>\n\n\n\n

A roadmap isn\u2019t a list of features and bugs and work in progress down to the day and week and month. That\u2019s a release planner. <\/p>\n\n\n\n

Simon turned over his napkin, and sketched out three columns:
Current | Near term | Future<\/strong><\/p>\n\n\n\n

He talked me through a concept of time horizons, and three \u2018buckets\u2019 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.<\/p>\n\n\n\n

\"Early
Early sketches of timeline-less roadmaps, using time horizons and \u2018certainty\u2019 as axes<\/em><\/figcaption><\/figure>\n\n\n\n
\"An
An early wireframe of the Now-Next-Later format of the roadmap<\/em><\/figcaption><\/figure>\n\n\n\n

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 \u2018be\u2019 a roadmap.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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

One piece that we didn\u2019t talk about was whether we would still call<\/em> it a roadmap. We didn\u2019t 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\u2019t know where to begin. After all, our website said we had roadmap software, and it did technically <\/em>meet the criteria. Our new roadmap format was just\u2026 different.<\/p>\n\n\n\n

Somewhere along the line, the napkin was lost. I wish I\u2019d framed it now.<\/p>\n\n\n\n

\"Homer<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

And they actually liked it! <\/p>\n\n\n\n

\"A
ProdPad\u2019s first Now-Next-Later roadmap<\/em><\/figcaption><\/figure>\n\n\n\n

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\u2019t know how big they\u2019ll be in a year\u2019s time, let alone how fast they\u2019ll be able to deliver! <\/p>\n\n\n\n

Our first version was very<\/em> MVP. It was simply some boxes you could add to one of three columns pragmatically named \u2018Current\u2019, \u2018Near Term\u2019, and \u2018Future\u2019. Frankly, you could have done it in Trello. The basic format grew into a much richer form of lean roadmapping.<\/p>\n\n\n\n

It was right to keep the name \u2018Roadmap\u2019 for this new format, even if it didn\u2019t look like the other roadmaps. From feedback, we realized that we were implicitly giving product people permission<\/em> to step away from the timeline roadmap format<\/a>. After all, they were <\/em>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! <\/p>\n\n\n\n

By subverting the format and terminology we changed the way that roadmapping was done. Which we appreciated sometime later. It\u2019s a roadmap. But it\u2019s not a usual format roadmap.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

The Modern Roadmap Evolves<\/h2>\n\n\n\n

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. <\/p>\n\n\n\n

Since then, over the years, the roadmap has evolved.<\/p>\n\n\n\n