Start Small - Think Big | Define your Product Roadmap in 7 Simple Steps
Welcome to the fourth article in this Practical Product Management series. The series will discuss a number of simple and practical solutions and tools to help through the challenging and evolving landscape of Product Management.
We are going to look at how to create a product roadmap using 7 simple steps.
A Product Roadmap helps to communicate product vision, direction and to a certain extent progress, to internal and external stakeholders.
An initial Product Roadmap should be created when conceptualising the product, together with Product Definition and initial feature list. Products evolve over time and so do Product Roadmaps. The initial roadmap is iterated regularly to keep it updated with the evolving product direction.
A good product roadmap
- is a clear and concise high-level, visual summary of the journey of your product from initial concept to the final destination
- attempts to communicate how the product, its core features, and themes are expected to evolve over time
- helps guide the strategic plan and communicate the product strategy
- is a living visual representation that evolves with the evolution of the product
- is able to adequately relate to the type of users (Primary, Secondary, and Tertiary) and their needs
- presents a holistic visual view of the product functions, product purpose, and evolution of various product themes
It can be very difficult to summarise and communicate this enormous information on a single page that resonates with all levels of product stakeholders from engineering teams, the customer success team, marketing teams to senior executives.
Hopefully, this 7 Step guide to creating your Product Roadmap will help you not only create your initial product roadmap but easily iterate on it on an ongoing basis. The steps are:
To help understand the steps in this guide, we will use an example product of a News-Site.
The types of users for News-Site are:
- The Primary Users - the visitors to the site, the readers or consumers of the news stories
- Secondary Users - people who curate and create the news content for the site
- Tertiary Users - people who would want to place advertisements on the News-Site
The Primary User needs are:
- Ability to have access to the latest news and breaking news
- Ability to search for news
- Ability to subscribe to the news
The Secondary User needs are:
- Ability to curate and create News Content in the News-Site
The Tertiary User needs are:
- Ability to place an advertisement on the News-Site
At this point, you might want to refer the other LinkedIn Blogs in this series on
- Product Definition; to understand the concept of different types of users
- Product Prioritisation; to understand how to prioritise the features of your product and
- User Stories to understand the concept of Minimal Viable Features
STEP-1: FEATURES
This is a preparatory step, to ensure that we have the right information available to us at the right level to be able to create a Product Roadmap.
Feature List
Before we start creating our roadmap, let us make sure that we have a comprehensive list of product features. Comprehensive at this stage means the full list of features in the product backlog. Clearly, products, as well as features will evolve over time. So we are working with information available to us at this point in time.
Qualify Features with Product Definition
Now we should qualify this feature list and validate it with the Product Definition to ensure that it is fit to be part of our product. Based on the Product Definition framework, that we discussed before, let us ask a number of questions to qualify each of the features.
- Does the feature align with the Product Purpose?
- Does it satisfy a need of either a Primary, Secondary or Tertiary user?
- Does it support or enhance a Product Function?
- Can the feature success be measured? or Does it enable one of the success measures?
- Does it help implement one of the Foundation Attributes of the product?
Identify Feature Iterations (User Stories)
Product Roadmap is all about articulating product evolution in a visual form. Once we have a qualified feature list, we should try and create high-level user stories for as many features as we can. We are trying to list down the underlying user interactions for as many features as we can to not only help in prioritisation but also to work out the possible evolution and iteration opportunities for a feature. This will help us later on in deciding how to plot the user interactions on the product roadmap.
Have a look at the User Interactions for the 'Latest News' feature for our News-Site. You will find a really good detailed explanation of User Interactions in our article (by Mohit Talwar) on '5 steps to write great user stories':
You can see above how we can evolve and iterate the 'Latest News' feature by releasing small user interactions and measuring the user feedback on these interactions rather than releasing the full feature.
Prioritise the Feature List
Now, let us prioritise this feature list as per the Feature Prioritisation method we discussed before. We want to ensure that for the purpose of creating the Product Roadmap, we only take into account the features that provide high user value and are feasible to be delivered.
Any features that are High Effort and Low Value (Bottom right-hand quadrant - PARKING-LOT, in our feature prioritisation matrix) should be ignored at this stage for the purpose of creating a product roadmap.
As we go through the journey of envisioning, defining, building and shipping releases of our product, more and more information will be available to us.
While creating the product roadmap and undertaking the above activities it is important to work at a level of detail that is relevant to the information available to us. Otherwise, there is a danger that we end up undertaking too much analysis at this stage, possibly become overwhelmed with information and become too precise in our roadmaps.
Remember, Product Roadmap is a statement of intent; what we are likely to do and why and how we see us evolving rather than a project plan with precise activities and dates.
STEP-2 | THEMES
We will now try and identify the Themes for our product and group our features into these themes.
A theme is a group of features related to solving a particular user problem, meeting a particular user need or alleviating a particular user struggle.
The themes are organised around solving a problem for our users
Primary User Themes
Let us first identify themes that represent the needs of the Primary Users, the main consumers of our product. There will always be at least one main theme that represents the core purpose of the product, i.e. ability to send and receive Emails in case of Gmail and the ability to play songs in case of Spotify.
To start with, typically, there will be 2-6 additional themes, in addition, to the one main theme. So you are looking at between 3 to 7 product themes that are focused on the needs of our Primary Users. If you manage to identify more than 7 themes for your Primary Users, you might consider revisiting your Product Definition to see if you are deviating from the Core Purpose of the product or your Product is really a Product of Products.
In the case of our example product, the News-Site, the Primary User (the visitor to the site) themes could be
- Read good quality Latest News and Breaking News (the core purpose)
- Search for News
- Subscribe to News stories
The Secondary User Themes
Now let us identify the themes for Secondary User features, again there will always be at least one main theme possibly supported by 1 or 2 more themes.
For our News-Site, our Secondary User (the news content creator) will need to have an ability to curate and create good quality content and user-friendly features and navigations across the News-Site. So, let us assume this theme is called Content Management.
Tertiary User Themes
If our product definition has identified Tertiary Users of the product, we should be able to identify themes that represent the needs of these users. There will always be at least one main theme possibly supported by 1 or 2 more themes.
For our News-Site, the Tertiary User (who wants to place an advertisement on the site) will need to have an ability to display targeted advertisements for our visitors to the site. Let us call this theme, Advertisements.
Product Foundation Themes
We need to add three more foundation themes to our list of themes, these are:
- Measurements - Representing the feature iterations that will enable us to measure the success of the product features in order for us to Iterate, Improve and Discard or even Pivot!
- Instrumentation - Representing the feature iterations that provide a Dashboard to monitor the health of the product and provides diagnostic information, primarily used by the Customer Success teams and Engineering teams
- Customer Success - Representing the feature iterations that aim to help our Users (or customers) become successful by using our product. These will include product and feature help, customer success contact via Email, form or online chat, trial, and demo versions and a ticketing system to capture user feedback, issues, queries, and concerns.
We have now identified the Themes of our product and aligned the Product Features into these themes. Let us now validate these themes again with our Product Definition to ensure we are still aligned and have not diverted from the original purpose of the product.
STEP-3: MVP
We now need to work out what should be our Minimum Viable Product (MVP).
How to decide your optimum MVP is a topic in itself and probably needs a separate blog, but for the purposes of this guide we will discuss some core concepts and principles to understand the key information required for our Roadmap and introduce two new concepts- Minimum Viable Feature(MVF) and Minimum Viable Theme(MVT).
Consider the following definition of MVP.
MVP is a product with just enough features to satisfy early customers and to provide feedback for future product development.
In order to define our MVP, we need to work out which features, interactions and themes will be part of our MVP.
Let us apply a similar definition as MVP, to Features and Themes, that we have already identified.
Minimum Viable Features (MVF)
Let us identify MVF for all our core features, to do this you will require User Stories for these features and our third article in this series 5 Steps to write great User Stories and define an MVF may be of help.
Consider the following definition derived from MVP definition:
MVF is a feature with just enough user interactions to satisfy early users and to provide feedback for future feature iterations
In our example product, News-Site, one of the feature is
The Feature interactions are as follows and the Minimal Interactions for an MVF for this feature are highlighted below:
Remember that Product consists of features and product evolution consists of the evolution of its underlying features. By understanding the Minimum Interactions required for an MVF, you are able to plot the feature iterations on a roadmap.
Minimum Viable Theme (MVT)
Let us now identify MVT for all our product themes. We discussed earlier in this article that themes revolve around solving related user problems or satisfying related user needs.
Consider the following definition derived from MVP and MVF definitions:
MVT is a theme with just enough features with just enough user interactions to satisfy needs of early users and to provide feedback for future theme iterations
For our example product New-Site, one of the themes is ‘Latest and Breaking News’ with two main features:
- Latest News
- Breaking News
The Minimum Viable Theme for ‘Latest and Breaking News’ is a combination of MVF of ‘Latest News’ and ‘Breaking News’ as explained in the diagram below:
MVP for Primary, Secondary and Tertiary Users
Now, that you have a view of MVF for all your core features and MVT for all your themes, consider defining an MVP for each type of user Primary, Secondary and Tertiary.
In our example website, although it is necessary for our Secondary users (news Curators and Creators) to have an MVP in order for the Primary User to be able to have access to the news, it is not necessary for the Product MVP to have any advertisement features at all.
But, the Tertiary User (the advertisers) would need to have a minimum viable feature to be able to operate an advertisement on our site in order for early (advertisers) users to try the product and be able to provide feedback on the product.
So, using this argument, the MVP for Advertisers can come later than the MVP for Visitors and News creators.
This provides us with a good and clear view of the MVP of the overall product and how the features and themes, subject to user feedback, market research, and measurements, are likely to evolve with each iteration.
Now let us validate our MVP, MVF, MVT and the MVP for different user types with our Product Definition to ensure we are still aligned with the overall purpose of the product and are addressing the user needs.
STEP-4 | THE DESTINATION (THE GOLDEN RELEASE)
Consider your product evolution as your own journey. In the previous step, we worked out our starting point, our MVP. Let us try and work out where we aim to get to, our destination or our summit. This is the ultimate vision of the product as defined by the Product Definition.
Let us call it ‘The Golden Release’ of our product. This is the Pinnacle, at least as we know it today!
Golden Release aims to fully deliver the Product Purpose and fully satisfy the identified needs of its Primary, Secondary and Tertiary Users.
To work out our Golden Release, we follow largely the same thought process as working out the MVP.
- Identify Golden Release of each of your core features, the point at which the feature fully satisfies a user need
- Identify Golden Release of each of your theme, the pinnacle where the theme fully solves a problem for users
- Consider separate Golden Releases for each type of user. You may have fully met the needs of the Advertisers to the News Site but are yet to fully satisfy the needs of its Visitors.
Don't get too hung up on aligning the golden release of each feature, themes or user. We will work that out when we plot this information on the Roadmap.
Remember, ‘The Golden Release’ is a statement of your intent, the Pinnacle you want to achieve and the Summit that you want to climb.
STEP-5 | THE MILE-MARKERS
We now know where we are starting from, the MVP and where we aim to get to, The Golden Release’. Let us try and work out all the major Mile-Markers (the major events or releases) in our Journey (or on our Product Roadmap).
Let us start with noting down two Preparatory or Foundation releases:
- Mobilisation - to define, design, and socialise the concepts; and to mobilise the teams and resources
- Framework - to build the design, architecture and technology foundation of the product
These are not end-user releases but very important preparatory milestones before we release our MVP to the users.
These will be followed by MVP release - a ‘usable’ and ‘measurable’ first release of the product for early users to allow future product iterations. This is the start of your journey to the summit.
Before we get to our Summit, The Golden Release, MVP release will be followed by two basecamps, BRONZE release, and SILVER release.
- Bronze Release will improve and iterate on MVP
- Silver Release will aim to fully meet and measure all user needs
Followed by The Golden Release where the full intent and vision of the Product Definition is delivered. This is your Summit.
In reality, what we will deliver in Bronze, Silver and Golden release will change over time as we take into account the user feedback and market research. We will talk about Iteration on our Roadmap in a later step.
STEP-6 | THE MAP
We now need to plot our themes, the evolution of themes and releases to show how product features will evolve over time.
Depending on your intended audiences, you may have to tune the level of details for features and interactions that you provide in the Roadmap. Try and stay with core Features and Interactions that provide maximum user value and paraphrase them either as product capability or user need.
Let us first list down the Themes that we have identified for News-Site
Now we need to plot the two foundation releases, Mobilisation and Framework.
Notice that for Mobilisation and Framework releases, the focus is on the holistic concept of the product as these are important preparatory and foundation releases and need to consider the whole product vision to create the right foundation.
We now list down the features of MVP against each of the themes to show MVP Release.
Notice that this MVP for the News-Site does not include any features for the 'News Subscription' and 'Advertisement' themes. They are not necessary for the early users to try our News-Site product and provide feedback on it.
Now let us plot the evolution of themes from MVP to the Golden release via Bronze and Silver releases. For each theme, we are moving from left (MVP) to right and showing the evolution of features and themes.
Here you will notice how each theme is evolving through the releases and features are getting richer, solving increasingly complex user problems and enhancing user experience. The Golden release is the Summit stating the ambition for this product in terms of each theme reaching its Pinnacle as we reach the Golden release.
Now let us put all of our releases together and Voila!!!, we have our Roadmap!
Depending on whom we are communicating with, we could also show our roadmap in a Current, Near-Term and Future view. You can use a variant of the format below with items in the 'Current' horizon much more granular and specific than items in the 'Future' horizon.
STEP-7 | ITERATE
Our Product will evolve over time and so will our Product Roadmap. Our objective should be to release small increments of Minimum Viable Features, measure effectiveness of released features for our users, iterate, improve or discard, based on what our measurements are telling us to do.
Sometimes it may be necessary for us to Pivot and change the direction of the evolution of the product, you can read more about Pivoting in my other article here.
It is important for us to revisit our Product Roadmap regularly, to ensure it reflects the current direction of the product. I would recommend iterating on your Product Roadmap at least every Mile-Marker, more frequently if the Product Measurements indicate a possible pivoting opportunity or the user feedback highlights some core features or themes that were missing from the original roadmap.
When you iterate on the roadmap, be ready to consider new themes that emerge o merge or discard the existing themes if this is what the product measurements, market, and user research are indicating.
If you have reached till this point, I hope you enjoyed reading the article 'A 7 Step guide to create your Product Roadmap' and use it to help you create your next Product Roadmap.
We have developed a little tool in Excel to make it super simple to create the Product Roadmap using this guide.
If you would like a copy of the tool for you to try and improve upon, you can download it here. Nimble Framework - Product Roadmap tool.
You can also find the full slide pack on Slideshare.
Ex IT Project Management Consultant with delivery track record ★Author/Blogger Be a Better Sheepdog
5 年To add the Project Management dimension to this post, I would add to the statement "The Golden Release aims to fully deliver the Product Purpose and fully satisfy the identified needs of its Primary, Secondary and Tertiary Users .... and ensure all needs articulated in the Business Case are met".? The production of the first Product Roadmap will be a critical checkpoint in the Project lifecycle. At this point it should be possible to better estimate the Product development costs compared to when the original Business Case was created. At this point, check "does the Business Case still stack up?". If not, it may be time to halt the Project before any more money is spent. To better understand the role of the Business Case have a read of my PM Blog post?https://bettersheepdog.blogspot.com/2016/03/PRINCE2-Principles-Business-Justification.html