Translate Your Vision to Action with an Internal Roadmap
You’ve got a clear vision for the future, and it looks bright! But now you need to get down to street level and map out the steps that will carry you forward. Part one of this article taught you how to align a roadmap with aspirational business goals. The initial steps of this framework took collaboration between business leadership and the product team to set a direction for development decisions. In the second half, the product team will work with the development team to tie actionable projects to business goals.
Step 4 — Project Selection
Outcome: A timeline view of the potential projects scheduled during the roadmap’s timeframe.
Participants: Product Manager (required), Product Owner (required), Development Manager (required), Business stakeholders (optional)
Guiding Questions: What are the highest value projects that will help realize your strategy at the end of the roadmap.
This step gets into what people think of when they ask for a roadmap. What are you going to work on? This step may be the biggest challenge to a realistic roadmap. It works best when you already have an organized backlog that includes high-level estimations of project sizes and values, and prioritization projects. The good news is you can still move forward if your backlog isn’t this organized. The bad news is that your roadmap is only as accurate as the information driving it.
- To start, pick the projects from your backlog that support your strategic themes. Try limiting selections to things your team can complete within the roadmap’s timeline.
- Place each project into the quarter you believe it will start. Align them into the strategic theme swim lanes. Swim lanes may have no projects in a quarter, depending on how you’ve allocated effort.
- If you choose projects that don’t fit the strategic themes, ask if they are the right projects.
- If a project will cover multiple quarters, stretch the project across the quarters.
- Highlight each project with a color to communicate the level of certainty. For example, highlight top priority projects that are sure to start next quarter in green. Highlight projects with unknown dependencies, resource requirements, and scheduling in yellow. Not only is it okay to have uncertainty in your roadmap, it’s a positive. By embracing uncertainty, you acknowledge the roadmap will change and adapt with time. The number of yellow projects should increase the further out you go.
- After selections are complete, compare how you’ve allocated projects to the effort estimated in each strategic theme in the last step. If a swim lane has more projects than the effort you assigned, then you must either adjust your projected levels of effort or remove projects. You don’t want your projects to be out of sync with your priorities.
I’ll continue to use the Amazon example discussed in the previous article. The image below shows a simplified version of what the Kindle roadmap looked like after product selection. It shows the highest priority projects in green and schedules them in early.
As the roadmap extends out, more projects are planned but with less certainty. Projects that may move are displayed in yellow. Marking something yellow instead of green doesn’t mean it’s less valuable. Shopping on the kindle is a key function of the device, but the project to integrate with online purchasing isn’t fully scoped yet. The uncertainty in a project dependency affects when the next can start.
In the example pictured, the projects scheduled in the swim lanes seem equal. At first glance that seems like balanced priorities, but the strategies in the lower half are less important than top. This might be an opportunity to equalize the weight of the strategic themes. But more likely the product team should remove a few projects from the lower priority categories. The “Reading Light” and “Paid Ads” are not critical features, so the roadmap should adjust to keep priorities and projects in sync.
Step 5 — Platform Guiding Principles
Outcome: A list of supporting concepts that should be considered when designing projects.
Participants: Product Manager (required), Product Owner (required), Development Manager (required), Leadership (optional), Business stakeholders (optional)
Guiding Question: Does the platform have any long-term goals that can help guide decision-making in projects without being specific to the project itself?
In order to complete your roadmap, take time to consider the ideas you dismissed as being too broad to achieve as a strategy. This step is optional, but it will help you be explicit about key concepts when designing and building projects.
For example, the Kindle design team identified earlier on that if the experience of reading an e-book was too dissimilar to reading a paperback, readers stick with physical books. If they could convince the customer to think of the Kindle as something familiar but better, it removed a barrier to entry.
That idea contributed to every step of the design process, from the size and weight of the hardware to the color and contrast of the text on the screen. It was the guiding principle of the product.
Guiding principles should help to make decisions over the lifetime of the roadmap, even though they don’t produce outcomes on their own. These are considerations you should address in every project scheduled. By being explicit in those choices, you set your roadmap up for success.
Step 6 — Review Cycle
Outcome: A living roadmap that consistently communicates projects aligned with company goals.
Participants: Product Manager (required), Product Owner (required), Development Manager (required), Leadership (required).
Guiding Question: Are the concepts and schedule defined still applicable, and what is missing from the roadmap?
At this point you have a working roadmap and could start sharing it with your stakeholders. You have everything you need to have meaningful conversations about the projects under consideration and how they will contribute to the long-term success of the company.
So why is there a sixth step?
An effective roadmap is an evolving document. In three months, the project manager, product owner, stakeholders, designers, and developers will be further along in their journey. They will know more about what success looks like. They will fail and learn and have new ideas. The strategies needed to realize a vision will change over time, leaving the roadmap out of date and out of touch.
If your roadmap is to provide ongoing value, it must grow and change with the times. As the Product Manager, you are responsible for a consistent review cycle to plan the next round of projects. Reviews should include checking completed projects against the expectations of the schedule and making adjustments for new information. Then report on the alignment between what the development team is doing and what the business needs. Above all else, keep looking to the future.
Unless your product and market are volatile, it shouldn’t change too much from quarter to quarter. Your goal is to balance current status vs overall need. Below is a suggested schedule to spread changes out.
1. Review the projects selected once a quarter. Update projects to stay in sync with new knowledge and maintain a reliable schedule. Remember to stay agile and learn from performance each quarter! Roadmaps aren’t commitments and you can change them.
2. Review the strategic swim lanes and allocation of effort every 6 months. Validate the effort spent on completed projects against your projections and rebalance as needed.
3. Review the vision and contributing strategies once a year and redefine for future planning. Don’t let the roadmap get out of alignment with the mission. Otherwise you’ll return to a collection of projects that don’t align with the direction you need to go.
Share that roadmap!
At the end of their journey, Amazon launched a successful new product that took the market by storm. It didn’t end the sale of physical books, but the name Kindle dominates the e-book market. This wouldn’t have been possible without coordinated and intentional collaboration between teams and a vision understood by all.
By following these steps you should be ready to take your product on a similar journey to success aligned with business goals. All that’s left is to share it with your team. It is tempting to take it further and share it with your customers. Don’t give in to that temptation! Public roadmaps need a different approach, one I’ll cover in a future article.
