Building a product roadmap.

Many times, we hear the words “product roadmap”, but what is their real meaning? There’s a good definition on ProductPlan, quoting: “A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing the strategy.”

What most stands out to me is “high-level visual summary” because over time there are changes in any product roadmap. For a start-up or a product in its embryonic state, this is very important. In fact, if the roadmap does not change it’s because something is wrong! So do not panic if this happens every week or month, it’s normal, in fact, it shows you are on the right track to respond to customer’s needs. Also, changing the product roadmap can mean that you are keeping up with the latest technology developments and this can only favour your product or business.

General Picture.
The only part of a roadmap that needs to be clear and sort of fixed, is its final goal and the overall vision for the product. Some good questions to ask yourself are:

  • What are the required features the product needs to provide real value to the customer?
  • What are the “nice to have” features that can be implemented in the future?
  • Where will the product be 5 years from now?

When building new products, it’s good to think of the 80/20 pareto principle that defends the delivery of 80% of the product value with 20% of its features. Applying this rule can help answering all other questions.

An additional tip on how to define a clear product vision can be found also at Product Talk, just by following the link: Also, if you share the roadmap and product vision with your customers and stakeholders, they will feel engaged and contribute to its evolution in time, maintaining their interest and investment from the MVP to the beta version.

It takes organization.
A good product roadmap takes time and planning. Make sure you organise and produce clear technical documentation explaining all stages and every final decision. It can be a small chapter together with the documentation or just an appendix. Starting with this kind of organization will pay off later since every step can be traced, as well as keeping future iterations aligned with the overall objectives.

Tiago Simões
Polarising Consultant

Author profile

Leave a Comment

Your email address will not be published. Required fields are marked *