Managing expectations, improving communication and thinking Agile: building an effective product roadmap for software development projects
A product roadmap is a tool used by Product Managers to communicate direction and growth in a project to their teams and external stakeholders. Aligned around product strategy, product roadmaps help PMs visualize and communicate high-level goals (timelines, features, and resources) as well as layout the tactical steps needed to achieve these goals.
But despite the tool’s capabilities, it’s not always straightforward to create a product roadmap. One of the most difficult aspects of creating a roadmap lies in deciding what to include to make it useful. Our post outlines some crucial best practices for creating effective product roadmaps for the software development lifecycle.
Don’t: focus on specific timelines
“A roadmap is not a magical prognostication of the future that predicts exactly where the market will be in 12-24 months.” Cliff Gilley, The Roadmap Conundrum: The Clever PM
There is long-term product manager resistance to roadmapping with specific dates. Why? To start with, because it’s difficult to accurately estimate when a project will be ready to deliver during the early stages of the software life cycle. On top of this, there are several variables to contend with throughout the project that you simply can’t factor into a roadmap, such as changes to the market, team capacity and stakeholder indecisiveness.
Avoid false commitment
The success of the software we build is contingent on the ebb and flow of the market and our users. And roadmapping without knowing how the marketplace is going to evolve can make timeline definition a bit of a guessing game. If your roadmap is being presented to external stakeholders, why risk disappointing them? Of course, there is a time and place to offer timelines for a project, such as when defining internal estimates for the product backlog in an agile sprint.
Tip: if you can’t scrap dates in your product roadmap, make the scope of the project as broad as possible. Define your requirements within your software definition tool, but make it clear from the start that they are subject to change – as most things are in software definition!
Do: manage expectations with an agile product roadmap
When it comes to project timelines, roadmaps are famous for creating unrealistic expectations among teams and stakeholders. Luckily, we’re seeing a shift in the way roadmaps are made with the golden years of agile methodology now in full swing.
Agile product roadmaps are flexible and goal oriented, focusing on the day to day work of the team and responding to shifts in the market. They are subject to a number of variables that include market trajectories and resource constraints – making specific timelines a no-go.
Having said this, agile does deal in planning and estimating. After all, managing expectations doesn’t mean cutting out dates altogether. According to Pendo’s CEO and Co-founder, Todd Olson, your roadmap should reflect the future 6-18 months forward. An example of agile product roadmap planning with timelines is outlined here by Cliff Gilley, the Clever PM:
- Certain — We know exactly what we’ll be working on in the next 3 months, and know specific features in a 1-month timeframe.
- Planned — We know roughly the right features to meet the thematic goal for the 3-6 month range.
- Researching — We know the themes for the 6-9 month range, and are collecting input and data to make specific plans for execution.
- Strategy — We have plotted a course for themes in the 9-12 month range based on our product/company strategy.
- Aspiration — Anything further than 12 months in the future reflect aspirational goals that are based on our overlying vision and strategic plans.
Tip: create a GO Product Roadmap. Download this PDF template and get started on your agile product roadmap!
Find out what Justinmind Enterprise could do for your business.
Don’t: mix up project and product management tools
The product roadmap is often confused with other tools and devices we use to manage projects, such as project management tools. It’s important to know when to implement what in the software lifecycle and not mix up resources. Here are a couple of famous examples of tool mix-ups:
Gantt Chart Vs Product Roadmap
A project management tool, the Gantt chart is useful way of showing specific tasks and/or events displayed against time. It’s used to help project managers visualize several activities, and offers specific feedback on project schedules.
Despite resembling the Gantt Chart (both with horizontal bars set across a time period), the product roadmap is actually a product management tool. It reflects the overall progress of a product – a ‘best guess’ of what’s going to happen based on knowledge of the team’s capacity, resources available and market tendencies. It does not manage product status or reflect specific timelines, rather it focuses on high level strategic initiatives.
Agile Product Backlog Vs Product Roadmap
In agile, the product backlog is a list of all items and tasks that need to be completed within the project. These items can be either technical or user-centric in nature, and are very much feature-specific. The product backlog needs constant maintainance or ‘grooming’ to ensure that the team is always working on the highest-priority tasks.
In comparison, the agile product roadmap doesn’t require quite so much maintenance as the backlog. It is created at the requirements definition phase of the software lifecycle and updated continuously throughout, similarly to the backlog. However, as Janna Bastow on Mind the Product points out, your roadmap does not need to show off ‘every last nook and cranny of your development plan’, nor include specific bugs or improvements to be implemented.
Tip: Don’t use project management tools for product management tasks. Check out Linda Johannessen’s Day to Day Product Management Toolkit here and avoid mixing up tools.
Do: think of your Product Roadmap as a communication tool
Think of your product roadmap as a communication tool for both internal teams and external clients. It should be keeping your team aligned across mutual goals and working on the things that push your company towards achieving its business objectives.
Your roadmap should also serve to demonstrate high-level, strategic initiatives and goals of your product strategy to external stakeholders. Communication with your stakeholders should be continuous throughout the entire software lifecycle – iterative feedback. Plan and prioritize with them to avoid any nasty surprises upon delivery.
Tip: Create a portfolio roadmap that can be communicated across levels of business and across products, to maintain consistency with the product strategy.
Don’t: be overzealous with feature definition
Feature stuffing has no place in product roadmapping. Let’s take it back to managing expectations. Pre-defining features in the product roadmap provides a false sense of security. How many times has a feature been dropped on the roadmap due to a shift in the market or lack of resources, and left unrecovered?
Features that are mapped out at the beginning of a project but aren’t actually realistic lead to frustration amongst stakeholders and users who were expecting, if not depending on, this feature. Why handcuff yourself to a set of features and risk disappointing stakeholders?
Of course, defining features and specific engineering bugs certainly does have its place in internal sprint planning. But when presenting your overall vision to investors, don’t plant seeds that can’t grow.
Tip: Learn how to say no to stakeholders to avoid turning your roadmap into a ‘feature soup’. Hold a roadmap definition workshop to allow everyone to make their suggestions and then leverage the ideas that most reflect your product strategy, and your users’ needs.
Do: think in terms of themes
Themes are a great alternative to features for your product roadmap for various reasons. They are quick and easy to communicate to your team and clients, they’re an effective way of earning audience buy-in, they keep people focused on objectives and they are wide enough in scope to get ideas flowing in the product roadmap definition phase. Being wide in scope, themes also give you the flexibility to switch specific features in and out according to changes in the market, stakeholder indecisiveness and/or software limitations during the software lifecycle.
Your product roadmap themes need to be goal-driven and specific enough to measure the direction and progress of an objective, but high-level enough to keep vision long-term. Here’s an example of a measurable theme for improving a company’s mobile app:
Theme: improve the experience of the mobile app
Feature: update UI icons, incorporate push notifications and create a custom sign-in form
Product Plan’s detailed guide to using themes in your product roadmaps is worth taking a look at.
Tip: consider creating your roadmap using story mapping to help understand the functionality of the product and identify any gaps in the process. Group these stories into themes and use these to create your map.
Product roadmap do’s and don’ts – Takeaway
The product roadmap can be an effective way to communicate your vision of a product both internally and externally. It is a high-level plan and should offer a look at the next 12 to 18 months down the line, based on current knowledge of the product and where it is heading. Avoid feature-syndrome, stick to broader scope and you’re half way there!