If product roadmaps should show dates is a controversial question. Some people have passionately argued that dates should be banned from roadmaps; others claim that they are useful. This article discusses the pros and cons of using dates on product roadmaps to help you decide which option is right for you.
What Product Roadmaps Are (in a Nutshell)
To start with, let’s briefly recap what a product roadmap is. I view a roadmap as a high-level plan that states specific benefits a product should provide over a certain timeframe, which may range from six to 12 months. I find it helpful to use the product roadmap so that it connects the overall product strategy with the product backlog, as shown in the picture below. I also like to derive the benefits stated on the roadmap from the user needs and business goals in the strategy, capture them as goals, and use them to discover the right product backlog items.
Why Dates Are Beneficial
Dates can be helpful for two main reasons: They allow you to state deadlines and check if your current roadmap is realistic and actionable.
Capture Deadlines
Some products must obey deadlines or a specific window of opportunity in order to achieve success. Take, for example, seasonal products like games and smartphones, whose main sales tend to take place prior to Christmas. Having the products ready on time is essential, as a delay would have a significant revenue impact. But even non-seasonal products can be subject to deadlines. For instance, in the case of imaging healthcare devices, a working prototype usually has to be available at the RSNA’s annual meeting in order to announce and then be able to launch the product, as far as I know.
Similarly, I’ve experienced hard deadlines for internal, supporting products like a supply line management application that had to be released at a specific date in order to achieve the desired benefits. Sometimes it even makes sense to employ a release train and timebox major product releases, for example, to coordinate different products or regularly offer improvements to the users.
Ensure the Roadmap is Realistic
Even if your product is not affected by any deadline, it may be helpful to consider dates or timeframes when developing a product roadmap, as this allows you to understand if the plan is realistic. A handy tool for this job is the Iron Triangle shown below.
The version of the triangle depicted above takes into account goal attainment, date or timeframe, and budget. Quality as the fourth factor that influences product success is placed in the middle to indicate that it should be fixed. Please note that one of the triangle’s vertices must always stay flexible and act as a release valve to account for unforeseen events, also referred to as Sod’s Law. To decide which vertices can be flexed, perform an informal impact analysis. Ask yourself if it would it be better to:
- Stick to the goal but take more time to reach it or increase the budget by adding more people (if that’s helpful and possible)?
- Or should you adjust the goal to make it less ambitious but adhere to the date or timeframe and budget?
Considering these questions makes it more likely to create a product roadmap that can be actioned and it sets the expectations of the stakeholders.
Why Dates Are Not Helpful
Using dates on product roadmaps can create unrealistic expectations and expect teams to commit for unacceptably long timeframes: Users, customers, and sales people may regard target dates as a firm promise or commitment and insist that these are adhered to—no matter how fast the development progress is.
This can create a significant amount of pressure for the person in charge of the product and the development team; it can result in an unhealthy work environment and unsustainable pace where teams work long hours or product quality is compromised. In the worst case, a severely compromised product is shipped, a product that doesn’t properly address the user needs and is full of bugs making it expensive and difficult to enhance and adapt it.
Now What?
Dates on a product roadmap are neither good nor bad in my mind. As with many other things, it depends on how you use them.
Whenever you work with an external, customer-facing product roadmap, I recommend not showing any specific dates. Instead, use timeframes that are big enough, so you don’t experience a death-march situation as described above. For example, you might want to choose six-months timeframes, or even more coarse-grained, annual ones like “this year” and “next year”.
But when you work with an internal product roadmap that aligns development team and stakeholders, I would encourage you to consider stating dates or narrow timeframes, as this helps you ensure that the plan is realistic and cleary express deadlines (if applicable).
In either case, make sure that creating a product roadmap is a collaborative exercise that involves the development team and stakeholders, preferably in form of a joint roadmap workshop. This ensures that everyone has the opportunity to contribute to the plan and that people are aware of their mutual concerns and interests. What’s more, it creates stronger support for the product roadmap and better alignment of the dev team and stakeholders.
Last but not least, don’t forget to regularly review and adjust your roadmap together with the development team and stakeholders—at least once every quarter, as a rule of thumb. A product roadmap is a living document; it has to be regularly updated to account for the development progress, user data and feedback, and changes in the overall product strategy.
Published on Java Code Geeks with permission by Roman Pichler, partner at our JCG program. See the original article here: Should Product Roadmaps Have Dates? Opinions expressed by Java Code Geeks contributors are their own. |
