We’re going on a road trip. It’s day one. We’re standing next to the car, backpacks on, with a sense of adventure and anticipation. “Hey, did we decide where we’re going?”
This, friends, is a common problem in software development. Often, our stakeholders either:
a) Are motivated to do something but aren’t sure what or why.
b) Are having trouble articulating what their true goal is.
c) Jump straight to telling you what they think the solution should be, which is probably just a symptom of a or b.
Whether you’re an internal product manager or an external consultant, your first job is the same: find out the why. Once you know that, you can help the stakeholder articulate their vision, and get your team aligned around bringing it to life. That’s hard stuff. But you can do it because it’s what you do.
If you haven’t figured out the vision yet, do that before reading on. But assuming you know the why, how do you then make sure everyone understands it and is brought into the vision? How do you get agreement on where you’re going?
You need a map!
A product roadmap is a communication tool
A product roadmap has a really simple purpose. To quote Andrea Saez of ProdPad, “it’s a visual representation of the problems you’re going to solve”. Andrea writes a lot of good stuff about product roadmaps, which makes sense since ProdPad is a tool for creating them!
I love spreadsheets. I do. My wife can attest to this: I use them when normal people would use a pen and paper. But sometimes even I admit they aren’t the right thing to use. And when you’re trying to get busy people to buy-into your product vision, that’s one of those times. You need something to get you out of the details.
A roadmap is that thing.
If you do it right, it’ll look really simple. Yet the analysis that goes it into it will likely be anything but simple. More on that later.
Should I create a product roadmap for my agile development team?
This speaks to one of my pet peeves when it comes to some perceptions of Agile software development. Agile is not chaos. Agile doesn’t mean we just show up and work on whatever feels right today. It doesn’t mean we don’t make plans. It just means we’re less worried about sticking to them if we learn something new. It’s right there in the agile manifesto!
So, yes, we can create an Agile product roadmap. I’m going to illustrate this with a quote from a guy who I guarantee knows nothing about software development: Prussian military commander Helmuth van Moltke.
The guy who coined the term “no battle plan survives first contact”.
Oh, that guy.
Ever seen a large-scale Waterfall project that didn’t involve a bunch of change orders? Me neither. It doesn’t matter what project management methodology you follow; change is inevitable. The only difference is how you manage the change.
But wait, if we know everything is probably going to change, what’s the point of a product roadmap?
It’s your battle plan. That’s it. Simple, right? Yes, but pretty important.
That’s not a knife, THIS is a knife! (what a product roadmap isn’t)
I’m not suggesting you play Knifey-Spooney with your team, although it could be an interesting team building exercise! But before we talk about how to build a great roadmap, let’s talk for a minute about what a roadmap isn’t.
It’s not a project plan. This is often a source of confusion - especially when some organizations use the term “project roadmap”. Can we not, please? So when they’re very obviously related and could easily be created using the same software and even by the same person, what’s the difference? In short, the roadmap is about your priorities, the project plan is about how you will execute. They’re both important. They’re just not the same.
A quick aside. The use of specific dates on a product roadmap generates some intense discussion. The level of detail in your roadmap will probably depend on your specific set of circumstances. If you have other teams or partners depending on your release, you may need to be more specific about timeframes. But beware of false precision. I like to divide my roadmaps into “this quarter, next quarter, beyond”. I find that smaller timeboxes risk the roadmap becoming too much like a project plan.
It’s not a commitment. I repeat, it is not a commitment! If you try to make it one, you’ll never get anything done! Think I’m kidding? Create a product roadmap - let’s say for the next 12 months - then show it to your development team, and ask them if they can commit to it. Then duck, quickly.
It’s not a laundry list of features. Your product roadmap is not just a regurgitation of your product backlog. I’m not saying you can’t include features on your roadmap. Features are ultimately what you’re going to build. But if you’re going to roadmap your solutions, it’s important to know the problems those solutions are going to solve, and how they fit into the overall strategy. If you can’t tie a feature to a broader theme or goal, it’s likely it doesn’t belong on your roadmap. There’s more than one way to do this, so it’s up to you exactly how you weave the story together. But it’s important that you do or you’ll likely end up with feature creep.
To illustrate how this works, back to our little road trip:
See how the features are grouped into themes that all tie back to the vision? The one exception is eating tacos. You can (and I’d argue that you should) eat tacos on your road trip. But it doesn’t support your vision, so it doesn’t need to be on your roadmap.
And the project plan is the third piece of the puzzle. All of those questions are important, but you need your vision and your roadmap before you can execute the plan.
Build Your Dream Product Roadmap
To learn more on how to structure your product roadmap, check out Roman Pichler’s guide to goal-oriented roadmapping and this Janna Bastow article about theme-based roadmapping. I also highly recommend the book Product Roadmaps Relaunched . There are some differences between these approaches but the larger theme (see what I did there?) is the same - to tell a coherent story about where your product is going. The roadmap is, after all, a communication tool.
One other tip: just like a healthy product backlog, it’s ok if your roadmap gets less granular as the time horizons get longer.
Here’s a simple template to get you started.
The concept is simple: establish goals, and then tie the work to those goals. This level of organization prevents from getting too precise, but still allows you to be specific about what you’re going to build.
Set Your Destination, But Enjoy The Journey
Now, don’t forget - your roadmap is going to change. No battle plan survives first contact, right? Good, you’ve been paying attention.
And it should change! As you release code into the world and let users get to know your product, you learn more. You know more today than you did yesterday and you will know more tomorrow than you know today.
So on your road trip, always keep your eye on the goal, but remember that product development, like life, is a journey. Maybe you get feedback that causes you to prioritize a stop at the Grand Canyon for a delighter moment. Or (if you’re lucky) you get stuck in the Maine woods and need to adjust your timeline.
Is your organization ready for goal-oriented product roadmapping? If you’re not sure if this is the right approach or want to share your opinion, drop me a line! Sharing is caring!