My favorite quote on Product Roadmaps is from David Cancel, the Executive Chairman of Drift.
Here’s what he has to say on the subject:
Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.
So, what’s wrong with our roadmaps?
A few years ago, I was managing a product that helped automate some of the building management tasks using OCR. We did a POC in the China market and then began to roll it out in other regions.
During this time, we were following a standard feature-based roadmap template (see below) to demonstrate the list of features expected to release each quarter. However, no matter how much effort we put into getting everything right on our roadmap, we kept running into the same challenges over and over again.
Over time, I have learnt that at the basis of most of these shortcomings were the feature-based roadmaps that were widely adopted everywhere in our organization.
Here are the common pitfalls of feature-based roadmaps:
Losing the bigger picture
No matter how religiously you follow your product strategy, it is often only a matter of time before you have to succumb to the myriad of feature requests thrown from all directions.
Having lost sight of the bigger picture in order to appease the executives, our roadmap soon turns into an incoherent feature factory. I understand that many people would suggest to pushback on the requests by “Saying No” in this scenario, but if you have ever been part of a budding startup, you would understand the inevitability of eventually “Saying of course” in some (if not all) cases.
With an incoherent set of features making up the individual releases, it is often difficult to measure the impact of the release towards the strategic goals.
Promotes output-focused over outcome-focused mindset in teams
Feature-based roadmaps promote output-focused mindset in the teams. The goal is to ship features, instead of delivering business value.
Teams end up spending a lot of their bandwidth perfecting features to the full extent in order to meet the expectations from the executives. This often happens because everyone makes their own interpretation of the feature from the high-level feature description included in the roadmap view.
Down the road, when those expectations are not fulfilled (often during the release demos), there is inevitable pressure to deliver the “complete” version of the feature, as per “their” interpretations. This launches a vicious set of events leading to delays and deadlines getting missed and dev teams spending working weekends and someone (often the Product Manager) not getting an appraisal.
Roadmaps become contractual obligations
With feature-based roadmaps, roadmaps often become contractual obligations with the stakeholders, rather than a view of the direction your product is expected to take towards implementing its strategy.
How often have we all run into scenarios where a failure to deliver a feature on the roadmap becomes a matter of life and death for the team?
Premature convergence on solutions
In today’s day and age, premature convergence on a solution, in the form of features, way before time, is risky. Your understanding of the customer problem, as well as the technology available to you to solve those problems, will change from quarter to quarter and is therefore bound to reset your roadmap.
Furthermore, having low-level details in the form of features as part of your roadmap leaves very little room for the team to innovate and improvise. In most cases, they feel less valued because they are being spoon-fed and are bound to lose motivation over time.
Goals-based roadmaps
Goals-based roadmaps shift the focus of the team from shipping features to delivering value and achieving product goals. While the features are still part of the roadmap template, the focus is always on meeting goals set for each release.
How to implement a Goals-based roadmap?
In the Product Strategy pyramid, the roadmap forms the third layer, coming after the Product Vision and the Strategy, but preceded by the Backlog layer.
If the ultimate success of a product and its team is measured by how close a product is to achieving its vision, then each subsequent layer in the pyramid needs to stem from the layer above it.
This forms a tightly synced pyramid, with each of the bottom layers contributing upwards and ultimately taking the product closer to its vision.
Having said that, for every successful product roadmap practice, the pre-requisites of Product Vision and Product Strategy must be fulfilled.
In established products, where the vision and strategy are already in place, it is equally important to develop a strong understanding of both before you, as a Product Manager, can start contributing towards the product roadmap.
Once you have the pre-reqs sorted out, you can start formulating your product roadmap.
Goals-based roadmaps come in various forms and structures. However, as spoiled by the name itself, each variation starts with the Goals.
How to determine the right goals for your roadmap?
Goals are what essentially differentiate goals-based roadmaps from feature-based roadmaps. These goals act as the sticking glue between the strategy layer and the rest of the components of the roadmap layer.
The goals should be drawn out directly from the product strategy. One of the common frameworks I often use, in conjunction with the product strategy, to help with the process is the North Star Metric (NSM).
The right North Star Metric (NSM) connects the business goals with the value the customer gets from your product.
Although a single product-wide NSM helps resolve the prioritization issue across teams, it can often be very hard to measure and attribute directly to the team's day-to-day activities.
Therefore, most teams prefer breaking down the NSM into smaller goals that are achievable in smaller chunks.
Identify your Input metrics that feed into the North Star metric and convert them down into goals for each release.
Let’s consider Uber’s example:
Vision → Becoming the cheaper alternative to owning a car or taking public transportation.
Strategy → Reduce the wait time in major cities to less than 5 mins by having 1 driver for every 50 people in each of the major cities.
North Star Metric → Rides per week
Now, Uber's NSM can be broken down into several goals for each team working on the different components of the application, as well as for separate releases.
However all these goals, at the end of the day, should contribute to the NSM, which is closely linked with the Product Strategy.
Example Goal 1: Increasing Driver Acquisition & Activation
While this is not directly linked with the NSM, however, it helps increase the supply of active drivers, therefore reducing the wait times and, as a result, eventually increasing the NSM value of rides per week.
Example Goal 2: Improving Driver Engagement
Once again, this contributes to the NSM by increasing the supply of drivers in the market.
As a product team setting the goals for your roadmap, this is the stage where you need maximum stakeholder participation and alignment.
The goals specify the problems you intend to solve without going into the details of the How. This is what makes the goals less susceptible to change over a period of time. As the goals only specify an intent to solve problems, they can also be reused across quarters or different releases.
The teams can bucket one or more goals together for a specific period of time (monthly, quarterly, etc) depending on the team size and the product’s lifecycle stage.
Implementation plan
There is an increasing trend to separate the roadmap goals from the implementation details. The goals are set in collaboration with the main stakeholders and then communicated across the rest of the org.
All the teams take these goals as input and build an implementation plan for their respective streams. The implementation plan includes the list of features to be implemented by each team and mapped onto the timeline in accordance with the set goals for that period.
Larger teams also often add another layer in the form of Themes, before the features layer, which gives a high-level view of the solution that the team identified to achieve the goals.
In continuation of Uber’s example from above, here’s how the themes would map out for the first goal:
Goal→ Increasing Driver Acquisition & Activation
Theme 1→ Improving the Driver Onboarding experience
Theme 2 → Providing incentives to Drivers
The themes help provide a high-level view of the solution, without going into the details and make the roadmap more robust to change.
After the themes follow the list of features that make up each theme. Features contain details about the solution on how to achieve the goals.
Theme 1→ Improving the Driver Onboarding experience
Feature 1→ 1-click signup
Feature 2→ Same day driver approval
Feature 3→ In-app onboarding tour
Theme 2 → Provide incentives to Drivers
Feature 1→ Referral program
Feature 2→ Bonus policy for any driver completing >10 no of rides per day
A few teams often confuse the features with the Product Backlog and end up complicating the product roadmap. It is essential to highlight that the purpose of the product roadmap is primarily to convey the direction the product has to take to implement its strategy. The specifications of the solution, also known as the feature specs (including the user journeys, design screens, user stories, architecture etc), have no place in the product roadmap and are better left as part of the product backlog.
Finally, there is a metrics or a KPIs layer linked directly with the features that are part of the roadmap. This allows you to assess how effective each roadmap release was in implementing your product strategy and in taking you closer to your vision.
Goal→ Increasing Driver Acquisition & Activation
Metric 1→ Driver growth %age
Metric 2→ Conversion rate from website signups to app
As you move down the roadmap layers, the susceptibility to change increases with each layer. While the problems identified as goals are more robust to changes, it is quite possible that the solution that you identified to implement in a later quarter is no longer relevant in a matter of a few months. Therefore, the lower layers of the roadmap are bound to change as you progress. The important thing to note here is that even amidst the inevitable updates required in the roadmap, stable goals allow you to keep on the strategic course.
The low-level implementation updates are also less relevant to the executive stakeholders, and therefore easier to manage at a team level.
Eager to try out the goals-based roadmapping approach for your product?
Try out the predefined roadmap template here.
Bonus read: Alternate perspective on Goals
Goodhart’s law states that “When a measure becomes a target, it ceases to be a good measure”.
Therefore, setting goals upfront can often lead to short-term incentives. Once those goals are identified, we as humans feel incentivized to do everything in our reach to move the needle on that metric.
As a result, when building roadmaps, the teams prioritize features that help achieve goals in the short term and lose track of implementing the strategy that would bring long-term and sustainable success.
Instead, goals should be used as a way to measure the implementation progress of the strategy through the product roadmap. They should be treated as indicators of success, rather than a measure of success itself.
Therefore, when building roadmaps, you have to be really cautious of this fact and not allow these selfish tendencies to overcome your thinking.
Sami Rehman
Read also
Build great roadmaps
