Product Roadmaps

I can¹t tell you how many times product managers have shown me their sophisticated spreadsheets and algorithms for prioritizing their long laundry list of feature requests (weighting various factors like cost, complexity, risk, customer impact, projected sales impact, documentation, dependencies, etc.) eventually leading to a single aggregated prioritized roadmap.

I understand where this comes from, and many years ago I did this myself, but I try to explain why this is so wrong on a number of levels.

First and foremost, your job is not to prioritize and document feature requests. Your job is to deliver a product that is valuable, usable and feasible. The feature request spreadsheet works against this end by pushing through features that users don’t value or need, increasing complexity, decreasing usability, and wasting engineering cycles. I¹ve written several times about the perils of confusing customer requirements and product requirements (see the number one product mistake in www.svpg.com/papers/toppmmistakes.pdf, and the 37signals guys had a good post on this a while ago “Forget Feature Requests”.

Second, this approach works against the holistic view of your product. Your objective is to increase conversion, or to help users get their work done, or to let users find and play their music, or whatever. Feature requests are specific theories about what might help this, but at the stage of the roadmap you really have no idea if the features described are the right ones, or if they can be designed such that they¹ll be useful and usable. That will come during product discovery. To lock in specific features at the roadmap level is to effectively skip the most important part of your job, and the key to great products which is product discovery.

Third, as I¹ve said many times before (see www.svpg.com/great-products-by-design), it really is all about the user experience, and those of you that have real interaction designers to work with know that during product discovery you will very likely change your ideas about just what exactly is “required.” Good design and product discovery in general can quickly lead you in different directions as you realize that many of your preconceived notions of what is required either just don¹t resonate with the user, or aren’t usable or feasible.

Moreover, this entire obsession we as an industry have with features is hurting far more than it is helping, and if we want to fix this problem we have to stop it at the source which is typically these feature request driven roadmaps.

One reason there¹s confusion about this topic is that there¹s different types of “roadmaps.” Each product typically has a “product roadmap,” but since the different products in the organization are typically built by a common development organization, with dependencies between the projects, this creates the needs for a “portfolio roadmap,” which is usually at a somewhat higher level of abstraction, otherwise there is too much detail.

To confuse things further, the marketing organization often produces their own roadmaps – external or public product or portfolio roadmaps. Hopefully these are derived from your actual product roadmaps or you have yet another type of (big) problem, but remember that these are essentially sales tools. Today, thankfully, far fewer companies produce these public roadmaps, and you should do what you can to avoid them if possible, but sometimes they are necessary. This is because big customers, the press, and industry analysts often want to know what¹s coming in the future. The key here is to keep the public roadmaps at a very high level of abstraction, and with very conservative dates. I prefer to provide public versions of the product strategy ­ share the vision if you must, but give yourself as much maneuvering room as possible in terms of how that vision will be realized.

All this said, product roadmaps are one of my favorite tools. When done right, they are incredibly useful to the product manager, management, marketing, and the engineers especially.

The product roadmap should describe the path from where you are now, to realizing the vision you have spelled out in your product strategy. You do have a product strategy, right? If not, your product roadmap has no real context, and that¹s a serious problem (see svpg.com/product-strategy-in-an-agile-world).

Product roadmaps should be very simple and high-level. They should reflect your current thoughts on which objectives are the most important. Is it taking the product international? Supporting mobile devices? Supporting additional personas? Addressing key usability issues? The roadmap is not intended to be a spec, and it¹s not a laundry list of features.

Also remember that while you do typically put target timeframes on a roadmap (“in Q1 we want to launch in the UK”) these dates are essentially just your hopes and wishes. It’s not until you define the product in product discovery, working with engineering on the actual costs in terms of time, and project management/PMO actually schedules the work, that you have real dates you can believe in.

Today product roadmaps are almost always stored on a Wiki so the project team can easily find it, and see your latest thinking and reasoning.

For Agile teams all these problems can still exist, but there¹s another set of issues that I¹ll talk about in a future article.

This is a big topic and there are several useful and proven techniques for making sure you’re choosing the right priorities and communicating your plan to the organization, and I¹ll talk further about these topics in future articles, but if you are one of those product managers that spends their day sifting through feature requests, and prioritizing and documenting the features, then hopefully this note will motivate you to step back and consider if this might in fact be a reason for your product¹s lack of real forward progress.