Imagine that one day a friend of yours asks you to organize a major conference for avocado growers.
If you’re like me, you’d start with a list of things that you need to do: book a conference hall to host the event, find several nearby hotels, reach out to potential speakers…
Essentially, you’d create a huge to-do list.
The problem with a to-do list is that it’s overwhelming and doesn’t give you all the information you need — like what should be done when, what items on the list depend on each other, and what your deadlines are. Add all of these details to your to-do list, and your list transforms into a roadmap. Which is useful, because by knowing what to do and when, you’ll be able to clearly see what parts of the plan don’t go expected (which always happens) and make new plans as needed.
When I first started building products, I was using Pivotal Tracker, a great tool for agile project management, to create a backlog of user stories. When you create a backlog of user stories and estimate them, it can tell you how much time it will take to complete a whole set of user stories based on your team’s velocity — the average amount of story points you complete each week. While this was a very nice feature, it lacked one important trait — it didn’t visually show how the work was planned in time. This was especially important for features that depended on each other and for items that had to be done by certain teams or people. That’s why I started creating visual roadmaps.
What Is a Roadmap?
A roadmap is a visual representation of user stories and features you intend to implement for your product over time, helping you make decisions by showing you what you want to build and when.
A roadmap can take on many forms: a Gantt chart, a Kanban board, a flowchart, or something else. The way you decide to visually represent your plans for user stories and features depends on what information managers and stakeholders find important. (Each form is different, so choose the one that makes the most sense for you.)
A roadmap is not a detailed release plan, and it’s not a project plan. Even though milestones and deadlines often have deadlines, it’s not a plan that your team is required to meet. And it’s subject to change. Typically, with every sprint, you revisit your roadmap and update it.
Your first roadmap should represent your ideal plan of action. For example, if you’re organizing a conference for avocado growers, you might want to invite speakers. Thus, you’d include inviting X people and reviewing their presentations to your roadmap. You might also want to show a VR movie describing new technologies in the industry, prepared by a partner who reached out to you. You know that you need a list of speakers two months before the event, and a VR movie should be ready at relatively the same time, so you add that information to the roadmap, too.
The reality is that things never go as planned. At a certain point, you might realize that you can’t get X speakers because there aren’t that many people in the avocado industry, and you have only a week before the deadline for that task, and your VR movie is taking too long to produce — you’re need it in a week, but it’s not ready. What do you do? You update the roadmap, and you take away the movie and leave only the speakers that you found. You can’t move the event and you can’t magically fix these issues, so you just remove the next steps for items that went wrong and try to come up with replacements. For example, you can show a regular movie created by a speaker that still looks promising.
Why Roadmaps Are Important
When building a product, there’s typically only one thing you can control. That’s the scope, or the set of user stories and features that are going to be built.
You can’t control time unless you have a time machine, because especially when you have multiple teams or multiple people working on a product launch, the release date is more or less fixed. You also can’t control the resources you have, unless, again you have a time machine. Then you could just go back in time, trade yourself some prehistoric diamonds for an iPhone, and come back. Or maybe you can’t. Anyway, even if you had all the money in the world, according to the law of diminishing returns, the more developers you have working on the product, the less effective they are.
Can you build a product without a roadmap? Absolutely. But a roadmap makes your life easier. It helps you visualize what you’ve done, where you are and what lies ahead. Can you drive from San Francisco to New York without a map? Sure. But having a map allows you to plan better — you’ll want to stop here after eight hours of driving, get some rest, then go here and here to see some nice views, and so on. You might decide the same things by looking at the freeway exits, but it would be harder to do that while driving than when you are relaxed and just planning. And having a map and a path doesn’t mean that nothing will go wrong. If you’ve ever gone on a road trip before, you’ll understand what I mean. You might run into a road closure, or you might get a flat tire and miss a ferry, or you might end up driving another way because of a last-minute change of plans. Roadmaps allow you to at least have a plan of action and see what your opportunities are.
