What's Your Roadmap?
Roadmaps get a bad rap. Is it because we’re not using them effectively, are they inherently broken? Is it them, or is it us?
Today’s buzzword in product management is “Agile Development,” and it has a manifesto that espouses four main principles: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
The last step, responding to change, should align with the lean start-up mentality of build-measure-learn, but what happens in practice is we just build-build-build, and ship-ship-ship. Too often, software developers build the wrong thing or build the right thing wrong. We push out the door what our roadmaps have dictated, but often we are shipping less than ideal products. How can that be? Are our product roadmaps somehow to blame?
In this seminar, C. Todd Lombardo suggests that to understand why people have mixed relationships with roadmaps, all we have to do is look at our own archives. For sure, you’ll find roadmaps with oversimplified arrows and tick marks, vague milestones, and inconsistent coordination across those who will ultimately partner with and support the work process. And, if you ask around, you’ll find designers, developers, PMs, and others who chide the roadmap as ineffective and counterproductive, or simply “¯\_(ツ)_/¯?”.
So, in answering “WTF is a roadmap?” we should address what it isn’t. It’s not a release plan. It’s not a project plan. (Those are two different things!) It’s not a list of features with a bunch of dates. There isn’t one template for a good roadmap. There isn’t a silver bullet to do this well or to do this right. (Wishful thinking!)
Okay, so what it is it? (drumroll, please…..) It’s a strategic communication tool. It’s not about the tactics; it’s about the strategy and a prototype of our strategy at that. Our roadmap is a statement of intention and direction. To oversimplify it, it’s like plotting a road trip. You know where you’re starting and where you want to go, but you also know that you may have to make detours, stop, or change the course.
In practice, that means the roadmap helps you realize your product vision. The roadmap and release plan work together; the roadmap manages the outcomes, and the release plan manages the outputs. Teams should be challenged not just to come up with a solution, but to understand what problem it solves. The freedom to ask “Why?” over and over, until you’re getting to the root of the problem, gives designers, engineers, and those who are brilliant at finding solutions the license to do it.
Everyone—the designer, the developer, the candlestick maker—can all ask the tough question of “what do we get when we have that feature?”
Why roadmaps don’t work
- When roadmaps are too prescriptive and rigid, we attempt to work in conditions that are counter to the real world, which is continually changing.
- If everything is prioritized than nothing is prioritized. Lombardo shares the simple equation of value/effort = priority to plan when (or if) things get done.
- Even in build-measure-learn organizations, if teams aren’t measuring the right thing, they can’t learn what they need to learn.
What happens when roadmaps do work
- You’ve identified the product/program mission and vision and can state clearly what your product/program will accomplish, and a theme for what you’re solving.
- Teams agree to a timeframe that provides guidance on timing and broad flexibility perhaps with quarterly breakdowns or now/next/later planning.
- You’re realistic and have a disclaimer, like any good forward-looking document, that acknowledges that change is possible and even likely.
How to navigate the path with others
- Don’t drive this alone. Have one on one meetings with your engineers, developers, sales teams, etc. to get their unfiltered feedback, fears, and plans. Understand their challenges.
- Lean on your collaborators to tell you how they envision the path forward, and then ask “how?”.
- Get to a committed “yes” by giving your partners the ownership to say “no” to all the diversions and distractions that can get piled on and derail the roadmap.
TL;DR: You, too, can do a roadmap in 30 seconds or less! Assuming you have a product vision and have collected inputs, pull together all the ideas, problems, feedback from the various teams and organize them into themes and prioritize them by the value and effort to plan what’s now, next, and in the future.