Summary
A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for the product. But creating an effective roadmap is not easy particularly in an agile context where changes occur frequently and unexpectedly. This post helps you create an effective agile product roadmap using my roadmap format, the GO product roadmap.
- Do the Prep Work
- Tell a Convincing and Realistic Story
- Have the Courage to Say “No”
- Keep it Simple
- Get Buy-in
- Choose the Right Timeframe
- Prioritise Date vs. Goal
- Determine the Right Innovation Cadence
- Goals Come First, Features Second
- Select Helpful Metrics and KPIs
Describe and validate the product strategy – the path to realise your vision – before you create your roadmap and decide how the strategy is best implemented. The following picture illustrates this approach.
As the picture above shows, I like to use my Vision Board to describe and validate the product strategy. The Vision Board captures the vision, the target group, the user and customer needs, the key features of the product, and the business goals plus key elements of the business model.
You can download my agile product roadmap, the GO roadmap, and my Vision Board from romanpichler.com/tools/ for free.
Your product roadmap should tell a coherent story about the likely growth of your product. Each release should build on the previous one and move you closer towards your vision. Your roadmap should be convincing and realistic: Don’t speculate or oversell your product. Be clear who your audience is: An internal roadmap talks to development, marketing, sales, service, and the other groups involved in making your product a success; and external one talks to existing and prospective customers.
While you want to get buy-in to from the key stakeholders, you should not say yes to every idea and request. This would turn your roadmap into a feature soup, a random collection of features. “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features,” says Steve Jobs. Use your vision and product strategy to make the right decisions. Have the courage to say “no” and do it in the right way.
Resist the temptation of adding too many details to your roadmap. Keep your roadmap simple and easy to understand. Focus on your goals and capture what really matters; leave out the rest. Keep the features on your roadmap coarse-grained and derive them from the goals. The details including the epics, user stories, scenarios and UI designs belong in the product backlog and not on your roadmap!
As the picture above suggests, I have a preference to derive the product backlog from the roadmap (rather than the other way round). This approach tends to be particularly beneficial when you develop a brand-new new product or when your product is not yet mature.
Your roadmap is worthless if the people required to develop, market and sell the product don’t buy into it. The best way to create agreement is to involve the key stakeholders in creating the roadmap. This allows you to leverage their ideas and knowledge and helps ensure that the roadmap is realistic and actionable. I recommend running a two to four hour workshop to create the GO roadmap, as the following picture illustrates.
If half-a-day is not enough, then stop and reflect. Chances are that there is something wrong with your strategy and that you have to do more research and validation work.
Choose a realistic timeframe for your roadmap – a timeframe where you can anticipate the growth of your product without resorting to speculation. I find that a 12 months horizon often works well: It doesn’t look too far into the future and it provides the opportunity to align the product roadmap with the company strategy, to show how the product supports the wider business goals, and to acquire the necessary budget.
When building the roadmap, ask yourself if meeting a date or fully achieving a goal is more important for the success of your product. If you are constrained by dates – for instance, to launch together with other products, to have a new version available at a major tradeshow, or to launch sooner than a competitor – then start with the date and determine what goal you can realistically achieve within the given timeframe.
If meeting a goal is more important – for instance, to acquire users, to generate revenue, to improve the UX, or to reduce technical debt – then start with the goal and determine when the goal can be achieved. A great concept for identifying the goal of the first major release is the Minimal Marketable Product (MMP). The MMP describes the product with the smallest possible feature set that creates value for the users and customers and that can be marketed and sold successfully.
I find it not uncommon that some releases are goal-driven while others are constrained by dates. For instance, the first major release may have to achieve a goal such as acquisition while the subsequent releases are launched at fixed dates.
To determine how often you should launch a new product version consider how ambitious your goals are, how difficult is it to build the product, and how often your users and customers can take advantage of new product features without feeling overwhelmed or confused. As a rule of thumb, aim for at least one major release every three months after your initial product launch.
It can be helpful to establish a steady innovation cadence and use timeboxed releases. You could, for instance, release every two months. This can make it easier to coordinate the development and launch of related products, and users know when to expect a new product version. (You can and should, of course, deliver smaller, incremental improvements and bug fixes continuously.)
I recommend that you derive the features on your roadmap from the corresponding goal. The features should be the key product capabilities or themes required to reach the goal. If your goal is to improve the user experience (UX), then an example for a feature would be “intuitive, hassle-free user registration” (assuming that the current registration process is not great).
If you have an existing feature that you want to add to your roadmap then look for a goal that the feature supports. If there is none, change your roadmap, adjust an existing goal or add a new goal, or drop the feature.
Once you have selected a goal, ask yourself how you will know that you have met it successful and determine the appropriate metrics or key progress indicators (KPIs). Your metrics hence depend on you goal. For instance, measuring the success of acquiring users may involve looking at traffic, search results, and download data; understanding if technical debt has been successfully removed may require measuring code complexity and refactoring potential. Choose quantitative metrics if you can. If not, use qualitative ones. Refine your metrics as you learn more about the product and the market by developing and launching new product versions.
| Reference: | 10 Tips for Creating an Agile Product Roadmap from our JCG partner Roman Pichler at the Pichler’s blog blog. |
