A couple of years ago I was asked to create a roadmap of my product to increase transparency among stakeholders. I did it. I checked out upcoming projects that required contribution from my team, came up with my ideas about which features might be potentially improved, and put this stuff in my roadmap.
It seemed to me that I knew what to do within the next 3 years. I had thought I luckily found an answer to the question “What to build next?” until I got into the outcome-based mindset.
I came back to my roadmap and saw it in a different light: I saw a list of prioritized projects and features with dates. There was nothing about goals to be accomplished. What is more important, I lacked ‘why’ I want my team to build those features and contribute to the mentioned projects. I started thinking of how I could close this gap. I needed to figure out how successful companies and product teams tackle the risk of falling into the same trap as I did.
I started with the basics. I decided that I would successfully achieve goals of my research if I answered the following questions:
- Are roadmaps created nowadays?
- If so, which approach is trending?
Avoid Being a Feature Factory
I learned that my previous approach to creating a roadmap was popular when most companies followed waterfall methodology. In this approach, everything starts with an idea. Ideas about features and projects mainly come from executives, key stakeholders, product managers and customers who are supposed to know which solutions they want to be built for them. Some ideas are rejected at the company level (e.g. due to a lack of a compelling business case), and some of them are put in a roadmap. Then ideas are taken one by one, requirements are collected and functional specification is written. Next, it is handed on to a development team. Eventually, a project is fulfilled and the feature is delivered to customers. That sounds very familiar, doesn’t it?
In many cases, this “feature factory” approach leads to failure because it eliminates a possibility to know ‘why’ the effort towards any innovation is made. There are many examples of companies that have built a market around their features and eventually failed (e.g. BlackBerry, Kodak, Blockbuster). Therefore, companies and product teams should stop producing output without deep knowledge of why they are doing it.
Benefit from the Product Release Plan
The feature based product roadmap is the past long-term trend to be avoided today. However, many organizations may find the traditional roadmap beneficial to keep in the loop further feature releases and track progress. It definitely makes sense. I think the best solution to this problem is to create and maintain a release plan. It is a list of features and dates. The release plan effectively communicates “When will we be done?” or “Which features can I get by the end of the year?”. In any case, the feature based product roadmap should be used by no means.
I looked up an example of the feature based product roadmap. The picture below doesn’t answer why the “New Admin Console” or “Mobile Mock Up” features are implemented. If you have a similar roadmap, start calling it the product release plan.
Start with ‘Why’
The best definition of a product roadmap I was able to find is “a product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing the product strategy.”
Every successful roadmap should encompass the following components:
In fact, in the book “INSPIRED: How to Create Tech Products Customers Love”, Marty Cegan suggests communicating business context by using these three components.
I suggest always starting with the highest possible level of ‘why’ because every product effort is aimed at the fulfilment of business needs by making customers and users happy. You need to know why a company exists, hires your team and what it wants to achieve. This information should be given in the business roadmap. The task of a product team is to create the product roadmap in a way to communicate the purpose of a product and direction of its development. The product roadmap primary focuses on customers and their objectives but still contributes to the fulfillment of business objectives.
A product team should know to which business objective it contributes. For example, YouTube might want to increase its revenue by 2%. If I was given a task to contribute to this goal, I might increase customer satisfaction. It could lead to an increase in the number of minutes a customer spends during a day watching video content.
Outcome Based Product Roadmap
The main items of the feature based product roadmap are features and projects. In turn, the outcome based product roadmap is built around measurable outcomes. In other words, it shows how we want to change customers’ life to drive business results.
In the book “Outcomes Over Output”, Joshua Seiden described the logic model. I suggest using this model as a backbone of the outcome based product roadmap and product release plan.
‘Must’ components of the outcome based product roadmap are the following:
A’ should’ component of the outcome based product roadmap and ‘must’ component of the product release plan is the following:
Other important components are the following:
The picture below shows which components of the logic model are included in the outcome based product roadmap. Also, it shows how the model is applied to modern product development.
Anatomy of Outcome Based Product Roadmap
I came across a nice example of the outcome based product roadmap. Apart from a vision, goals, and objectives, it gives the information on a timeline. However, unlike the feature based product roadmap and product release plan, it doesn’t provide its detailed view.
At present business and products roadmaps are used by successful companies and product teams.
Modern roadmaps are driven by outcomes. The feature based product roadmap is a thing of the past. If you want to communicate which features are supposed to be released, it makes sense to use a release plan for this purpose instead of the roadmap.
The outcome based product roadmap should show why any product effort is made to ensure that every initiative changes customers’ life and drives business results.
The logic model is a backbone of the outcome based product roadmap and product release plan.
Overall, change your focus from outputs to outcomes. Don’t measure success by working software. Otherwise, you may easily fail.