Use This Strategic Resource to Steer Your Team
in the Right Direction for Project Success
When you hear the term “roadmap,” what comes to mind?
For me initially, I went down memory lane to the 1990s when I got my first car. It was nothing fancy, just a Dodge Shadow (stick-shift). When my parents handed me the keys to the car, they also gave me a AAA Road Atlas of all 50 states. Looking back, I am not sure why I needed a map of Hawaii or Alaska. I guess my parents wanted to make sure I knew how to get from point A to point B no matter where I was in the country.
Likewise, in today’s business world, when you need to successfully chart a path from Point A to B, a product roadmap can keep you moving in the right direction.
What is roadmapping?
A roadmap is a high-level list of prioritized features or requirements for a product or service. It visually depicts the timeline of when these features could be released. A draft roadmap shows a timeline that is more of a wish list of business stakeholders. It gives the teams a starting point to discuss priorities, level of effort, and dependencies. These discussions typically change the roadmap quite a bit.
After synthesizing the level of effort and the available/projected bandwidth, the timeline of the roadmap helps communicate the capabilities and features that we are focusing on to all teams. It helps Product Owners and Scrum Masters identify cross-team dependencies, and leverage synergies between those teams. The roadmap is a good foundation to build the product backlog.
Roadmapping is primarily the effort of developing a product roadmap. I say “primarily” because there is research and visioning that should be done as part of the roadmapping exercise. It is like venturing into unchartered territory with the goal of identifying features or capabilities. A roadmap does not apply to only new products or services. It can be a very useful tool to define and communicate product or service enhancements. These enhancements can be near- or long-term.
Why do we need a roadmap?
Let’s ask ourselves a question: Would we drive around in an unknown area of the city without a map or a GPS? I am pretty sure we would not. Without a roadmap or GPS, we might end up driving around in circles.
A product roadmap helps manage and align stakeholder expectations, and clearly defines areas of focus for the short- and long-term. You can think of it like a very high-level draft project plan. If the organization had a software release cadence, the roadmap will enable us to map features to releases.
The roadmap is the best tool to communicate the product vision clearly and concisely. It is a Product Owner’s best friend. Based on input from stakeholders, features may be moved around from one release to another. The roadmap does not guarantee that a feature will be delivered in a given release. It is a guideline of when the stakeholders would like it delivered. The release schedule is typically maintained by the Program Team or Release Manager.
The roadmap ensures that any new feature(s) added to the list is prioritized by the business. Our business stakeholders now have a visual to see what features will be pushed out if they prioritize a new feature above other features in the roadmap. This makes the roadmap the most important tool for a Product Owner to fight scope creep. When we have multiple teams working together to deliver functionality, the roadmap helps them work on the features that are deemed most valuable by the business.
Where do we start?
The best way to start working on a roadmap is to start documenting high-level features that the product should contain. This is a good conversation starter.
The goal is to identify as many features as possible. Don’t worry about the priority or level of effort for the features at this point.
A good Product Owner makes sure that stakeholders articulate the needs of the business clearly. Identifying capabilities needed by the Business users and eliciting current pain points creates an atmosphere that is conducive to develop tools and techniques to improve business productivity. We should let the ideas flow freely when developing a roadmap.
Once the Product Owner has this list, we should get input from all stakeholders and impacted teams. It would be a good idea to separate the features into two buckets – “nice to have” and “must have.” There should not be any stifling of ideas, even if the features are not required for the core business process aka. gold plating. We should make sure that the ideas that are considered gold plating go into the “nice to have” bucket.
After we synthesize the input from the stakeholders, we should work on getting a T-shirt level estimate that is typically in “weeks of effort” for each of the features. This will drive the width of the feature in the product roadmap. One caveat that should be highlighted and communicated is that this estimate is not a guarantee and can vary depending on what the team learns when it breaks the feature into stories.
One of the most common mistakes Product Owners make is to create a roadmap and not update it regularly. A good rule of thumb is to update the roadmap based on changing market conditions, requirements, or business priorities at least monthly. There are times when we are not given a clean slate to chart a roadmap.
If we find ourselves in a situation where there are program milestones that we have to meet, we should work backwards from those dates and plan to deliver our piece of the puzzle a few weeks ahead of the program milestone. We should leave sufficient time for integration and performance testing.
Here is an example of a simple roadmap. The light green rectangles show a partial month’s effort, whereas the darker green shows a full month’s effort.
How do we prioritize a list of features?
Some would argue that it is always based on the needs of the business. We should also keep in mind that there are features that are driven by technology. For example, upgrading an application may not be the highest priority for the business, but from a technology perspective, it might help us get off an unsupported platform. Both the business and technology teams should work together to set the priority of features.
There is sometimes a push to go only with the business priority. If this is the case, it puts the onus on the technology team to educate their business partners on the importance of technology upgrade projects and how the business can benefit from the upgrade. Once the business understands the critical nature of the upgrade, that feature will be prioritized appropriately.
A good Product Owner acts as a good liaison between the business and technology teams, and builds trust between the two organizations.
Another way to prioritize features is to calculate the Return of Investment that a feature delivers (i.e., most business value with the least effort). A good Product Owner facilitates dialogue between the business and the technology teams to make sure that both the short-term and the long-term goals for the product are supported.
Just because the team is focused on a large effort does not mean that low hanging fruit are completely ignored. Depending on the amount of work, we might have one team focus on the short-term goals and another team work on the longer-term goals.
Another method to prioritize features is WSJF (Weighted Shortest Job First). In this method, we calculate the cost of delay and divide it by the time it takes to develop the feature. This is an unbiased way to prioritize features, as long as we can quantify the cost of delay. Never let the competition catch up with you.
A good Product Owner always looks for ways to enhance the product/service and stay ahead of the competition.
projekt202 is the leader in experience-driven software design and development. We are passionate about improving the experiences that people have with enterprise and consumer digital touchpoints.