A useful product roadmap tells you where you’re going without pretending that you already know every turn along the way.
A while back, we had a client that wanted to rebuild their entire product in one pass. The client already had a successful platform for providing classroom materials for teachers. But it was showing its age and needed to be rebuilt for modern design and usability expectations. They also wanted to add functionality and create room for growth.
This client had a strong sense of what they wanted, and they wanted to build all of it right away. We recommended a more sequential approach, starting with a minimally viable release and continuing through later phases. They chose to pursue the larger initiative together.
Some of the ideas within that bigger build turned out to be more complicated than necessary. Ultimately we wound up going back and revising some features to streamline them after the initial launch.
This is where a product roadmap earns its keep. It lets you move toward a larger goal without going too far before you stop, evaluate what you’ve built, and adjust what comes next.
What a product roadmap does
A product roadmap is a high-level document that shows what a product will do over time and which pieces you plan to build. It organizes those pieces into phases, sometimes with approximate timing attached.
Some roadmaps stretch across several years. We generally build them around a 6- to 18-month time frame. Within each phase, related features might make up one release or several releases.
For a new product, the first phase might establish a minimally viable product (MVP) with only the features needed to launch and begin gathering feedback. A later phase could add user-facing features that people consider essential or strongly desire. Farther out, the roadmap might include forward-looking features whose implementation is still uncertain, along with features that would be nice to have.
The detail should decrease as you look farther ahead. It may make sense to put dates around the current phase and the next one. The next phase may only need an estimated start date, while later phases may not need dates at all.
Don’t be afraid to make future phase timing fuzzier. Dates placed too far into the future can create false confidence and encourage people to anchor on them. The roadmap should establish direction without turning distant possibilities into firm commitments.
Build in phases so you can learn in phases
A phased roadmap gives you a series of points at which to evaluate your decisions. You implement a group of features, see how they work, gather feedback, and use what you learn to shape the next phase.
You may still need to adjust something you’ve already built. But you’re less likely to go too far without recalibrating, which helps minimize the time spent on rework.
At a minimum, revisit the roadmap after each phase, once you’ve evaluated the results. Look again at every phase that follows. What needs to change based on what you’ve learned?
Revisit it when there’s a significant change in your company, the marketplace, or your understanding of the context in which you’re operating. Sometimes the new information will change your course. Sometimes you’ll evaluate it and decide to stay on course.
A roadmap becomes harmful when a team becomes slavish to it. Following a plan that no longer makes sense isn’t discipline. It’s ignoring what you’ve learned.
How do you know what belongs next?
Your team may already know what it wants to build. Fine. But how do you know?
Is the decision based on your team’s opinions and expertise? Does it also reflect what users have told you, what they’ve asked for, and what you’ve actually seen them need?
Those can lead to very different outcomes. People who spend all day thinking about a product or service often have a different sense of what matters than the people who use it occasionally. It’s difficult to see that difference without speaking to users directly. This isn’t to say that your expert opinion is wrong, but rather that you almost certainly don’t value the same things as your users.
Even when the evidence supports your next feature, ask how that step tees you up for the one after it. How does it move you toward your ultimate goal?
The roadmap encourages you to measure each feature against your longer-term goals. Viewed in broader context, functionality that feels important now might prove to have minimal impact on your ultimate objectives.
Roadmap, project plan, and backlog
Roadmaps aren’t project plans. And a backlog isn’t the same thing as a roadmap.
A roadmap sits at the highest level. It shows your overall direction and the phases you expect to follow.
The project plan gets more specific. It explains how you’ll execute the current phase. The backlog is more specific still, containing the items that make up the features you’re currently building.
The three levels answer different questions:
- Where are we going?
- How will we execute this phase?
- What individual work is in front of us?
Start with today and work backward
If your organization doesn’t have a roadmap, begin by understanding what you have today. Then define your long-term goals and your vision for the organization’s future.
Now you have two points: today and the idealized future. To start filling the space between them, ask what would have to be true one year from now for you to be closer to that vision.
Then shorten the horizon:
- What would have to be true six months from now for the one-year outcome to be possible?
- What would have to be true three months from now?
- What would have to be true one month from now?
By continually shrinking the timeline, you can identify what needs to happen next and what should follow it. Those steps become your first few phases.
Your vision may change after you complete them. Good! You’ll have learned more and can adjust your course with a better understanding of what the future should look like.
Your roadmap doesn’t have to be elaborate, formal, or especially detailed. If more than one person is building the product, write down where you’re going and the steps you expect to take. That shared understanding is reason enough to start.
Roadmap in hand, you now know where you’re going and the steps you expect to take. Revisit them after every phase. A useful roadmap gives your team a shared direction and enough freedom to change course when you learn something new. Creativity thrives within structure. Your roadmap gives you that structure, freeing you to think expansively within a limited scope without locking you in to a soulless routine.