Posts Tagged ‘Roadmap’

If you’re an empowered Product Manager / Product Owner who has the authority to shape the strategy of your product and need insight into effective product strategy/roadmap practices and frameworks, this book by Roman Pichler is for you.

The book is well balanced giving you guidance on when and when not to use particular practices, for example when a product is yet to be validated in the market and therefore has not reached product-market fit, you shouldn’t spend your time making up a roadmap when you should be spending time experimenting and talking to target customers.

However when you’re scaling or have a mature product then product roadmaps would have many benefits which are explained well and are very accurate, such as collaboration, alignment and generally showing how you plan to progress towards your product vision.

I particularly liked The Strategy Canvas which looks like a great tool for competitor gap analysis.

The practices and frameworks are explained in enough detail that even if you’re not empowered to shape the strategy of your product, you could still find this book beneficial by understanding the tools and proactively having a stab at using them for your product.

Pichler leaves no stone unturned as he covers every aspect of product strategy from idea to execution, which ultimately enables product management functions to operate effectively.

Once you’ve defined a compelling Product Vision and VMOST, you will need to map out the ‘what’ and ‘when’ and the Product Roadmap is a great way of visualising the journey.

The Product Roadmap is also a good way of managing expectations with stakeholders, a great visual to collaborate over and view dependencies, as well as giving assurance to the engineers that you do have a well thought out data-focused plan rather than changing your mind daily based on who shouts the loudest.

Key points of a Product Roadmap:

  • It should be at a high-level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the teams’ product backlog items (PBI) under the epics.
  • It needs to include dates spanning the next twelve months whether monthly or quarterly.
  • The bars on the chart show when items start and when the development will be complete (live hidden).
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus/delivery and that things will change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve-month view rather than knowing whether something starting in six months will be delivered exactly a month later than that for example.
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan.
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it.

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important purpose of the Product Roadmap is for you to provide a sign of intent for when product items will be delivered over the next twelve months (your journey to reach your goals/product vision), with the keyword being ‘intent’ here ie. Not an exact drop-dead delivery date. Product Managers with experience of the teams’ velocity could use gut feel also which is acceptable or rough t-shirt sizing from the lead developers, rather than dragging the dev teams away for hours/days to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.