Upgrade your Product Roadmap!

Redesign to suit Agile or Kanban development process

Product Roadmap is generally a high level plan highlighting the short term and long term goals of a product, agreed and approved by all the stakeholders in an organization. It incorporates information including, features to be developed, markets to be expanded, customers to be targeted, timelines, technology and related information along with the sponsorship details.

It is a communication tool used by Product Management team, and sporadically by Sales, to set expectations (and not commitments) among team members, sometimes customers and keep them appraised of what is coming next and why they should do certain things now to be prepared for the future. But its use is almost becoming extinct for various reasons and it comes out as a customary document that satisfies a Product Management process.

It is time to rethink!

Changing Paradigms in Product Ecosystem

Since the advent and wide spread adoption of Agile development methodology the software development practices are constantly changing and evolving. There used to be 4-5 week sprints and now more products and organizations are looking to sprint every week and we are even thinking about non-restrictive releases in our organization.

These changing paradigms just show how essential it is to stay agile and nimble to respond to customer needs and expectations on weekly or even daily basis. As we migrate from monthly sprint process to non-restrictive release process we are forced to think, market and sell one feature at a time and not a release at a time. Here are some changes I am personally seeing.

1. Go-to-market strategy is now more fluent and ad-hoc.
2. Product Management cycle which used to be a month on month process is more nimble, feature specific now and not release specific.
3. Release of training material, documentation, upgrades etc. are ongoing rather a one-time monthly activity.

Flaws in drawing a roadmap

Despite the changing environment the Product Road-mapping process itself is flawed to an extent, in how it is being executed.

1. When setting up roadmaps that span across months and years it clearly means our natural tendency is not to stay agile. It means we have planned for features that are not important and urgent now but will be important at some point in future. In theory, roadmaps are aversive to change.
2. Estimations and ETAs do not make much sense because most of the times the actuals do not match with expectations. It is impossible to include all influential factors into consideration while doing estimations. This is true even if you break down features into granules. No product team today is able to meet timelines unless they under plan the activities. With such ambiguity, forecasting a development plan for months and years ahead is only true on paper.
3. Most roadmaps do not talk about user problems but only the features and technical aspects. This makes communication a one sided ritual. It becomes hard for teams to pitch alternatives to proposed features and for customers to comprehend the utility and value of features.
4. It does not support an iterative development process advocated by lean development practices. If you pivot based on your learning roadmap becomes invalid and if you do not pivot your product becomes invalid.

What’s the alternative option?

The whole point of this writeup is not to pitch against having a plan for future, but to question the way a Product Roadmap is being used in organizations. Here is my 2-cents on how things could change for good:

1. It would make more sense if there are enhancement plans in place for features you build today. Such a collateral will allow you to pitch the idea to prospects, get feedback and pivot. The difference here would be that you would not just stick to one plan and there could be ‘n’ options for the evolution of the same feature, without the restricted view of a Roadmap.
2. You can also build a list of customer problems and goals around that by grouping related ideas or features. These ideas can further analyzed through deeper research and feedback. When you get to a point where you need to pick priorities for development you would pick the epics that have the most business value at the time of development. Such a development should again be an iterative process with enhancement plans as discussed in point 1.
3. Have your communication centered around the customer problem instead of features and solutions. This way the recipients get a clear picture of the vision for the product and it also facilitates them to provide productive feedback.

Such a non-restrictive approach would keep you on lookout for validations all the time.Your larger goals and minor enhancements become meaningful through research and iteration. On top of that you do not have to waste time in building a collateral that is obsolete before you complete it.