Roadmap is a key part of a software product company, especially Enterprise Software (B2B) software. When you sell your software to a customer, it is not just on the current capabilities but lot of emphasis is made on the Roadmap. Especially with cloud based software this is becoming super important, as the innovation and capabilities come out incrementally, in frequent cycles.
In my interaction with startup founders, one of the aspect they want to manage better is Reliable Product Roadmap – to ensure they do not over or under promise.
There are two steps to Product Roadmap –
- Creating or documenting the product roadmap
- Communicating the product roadmap to various internal and external stakeholders
In this post, I would like to share some key areas to focus for effectively create and communicate roadmaps that may have different flavors.
Vision vs. Execution
Logically split Roadmap into the above two areas in order to communicate to right stakeholders. One part should cover the Product vision – or even a higher vision of the product segment or umbrella. This would be the driving factor based on which the customers should perceive the product, of how problems are solved today and into the future. As an example, Microsoft Office vision would be to improve productivity – and how they plan to leverage future technologies to improve productivity. The other part is around the Execution – more of delivery plan, more of product capabilities that are coming in, more of the details. A clear link should exists between the vision and execution – but it is important to have this as two parts.
Long term vs. Near term
Another important distinction to cover in roadmap is what is going to be covered in the long term and what is planned in the near term (short and medium term). Depending on the product lifecycle – long term could be between 2-4 years while near term can range from 3 months to 2 years. The long term ones are still ideas that has been experimented through some proof of concepts or things that would take a longer term to realize or productize, but they are important innovations or things that are coming to get near to the vision. Near terms are the ones which are almost getting completed or is under development, with reasonable predictability of getting them out sooner.
Rigid vs Flexible
We live in ever changing world, where priorities keep changing. It is important to balance the roadmap priorities between being too rigid or too flexible. The roadmap often changes due to customer needs not being met, competitive action driving some changes, internal priorities and investments, lack of market for certain investment. On the other hand, if you keep the roadmap too dynamic and flexible, you will lose focus and probably trust from your stakeholders. It is very important to keep the roadmap and investments spread between certain areas where you can be a bit rigid, whereas keeping some open-ended areas for ability to change the plans. For this reason, it is critical to keep the future roadmap not covered in any legal or contractual commitments.
Incremental vs Disruptive
Roadmap should consist of both incremental features as well as disruptive ones. Often we get into this innovators dilemma wherein the focus is on many minor incremental features that improves the product, satisfies the customer needs, solves the problem in a better way, bring better usability – so on and so forth. But in regular intervals – atleast once a year – its important to think about the next wave, the next big thing and start working in parallel to solve some new business problems, that could eventually eliminate a problem totally. Read my post on “what product are you making – pain killer, vitamin or vaccine” – once in a way you should experiment something disruptive, create and prove , and show what’s coming. Whatsapp is an amazing example of such a disruptive technology – in the past we have seen things like Google, ipad etc which are disruptive. Many smaller, less popular products have also been disruptive. In your roadmap, while it would be hard to communicate the disruptive ideas when they are in Labs, depending on its maturity, its best to prove some of the lab ideas with few handful of customers and validate them with real life use cases and scenarios. For such create /prove situations, a more restricted roadmap with NDAs are discussed with select customers. So use your roadmap to think and cover both incremental and disruptive solutions to problems.
Objectives (the what) vs Activities (the How)
Product Roadmap is not a Project Plan. Many a times we come across some of the roadmap that looks like a project plan, listing out different activities and milestones. Instead of being a list of activities with milestones, roadmap should lay out the objectives of the product – the vision, the capabilities and the tentative timelines those are going to be made available. This is important because the activities may vary based on the approach taken to a solution but the objectives of the product may still be same.
Solution bound vs Time bound
Another question that keeps coming back is whether a roadmap is solution bound or time bound. Roadmap is always time bound, as the user of the roadmap is looking to or planning based on the roadmap. The time need not be exactly accurate, but it needs to be indicative with an acceptable minor deviation. Usually indicating a period of short term, medium term and long term with a usual timeline fixed for each of them would be a good way to represent the roadmap. This helps customers plan better.
External vs Internal
Finally, while Roadmaps are drafted based on common vision and solution, Roadmaps have to be slightly different for external and internal stakeholders – especially with respect to the level of details presented, the timelines and the goals. For customers, Roadmap should address solution to the problem, with rough estimate of the time and the benefits that will bring by adopting them. For other external stakeholders such as investors or partners, it may go further into details of the market potential, and the ROI of investing in a certain set of roadmap items for the business. And for internal stakeholders it could go into more details on the strategy, more specific timelines, risks, competitive reasoning and few other internal only information may be laid out. Communicating the roadmap to different stakeholders is one of the key. Roadmaps should be clearly planned at an appropriate level of details with each of the stakeholders.
Product Roadmaps are living document and most important one for any product company. Lot of engaged time should be dedicated on documenting and communicating the roadmap.
Wishing you all Happy New Year 2018 !