Product Roadmaps – How much to share, with whom and by whom?
Roadmaps seem like such a simple concept. Simply share what you intend to build so that customers and prospects are happy. Hah! There are political, relationship, accounting and legal issues to deal with.
In the ideal world, the product manager would have a clear vision of where the product is going strategically, a good handle on available resources, and thus a solid picture of the next few release deliverables. However, this is often clouded by internal politics of decision making and who really ‘owns’ the product.
Not only that, Agile development processes have a tendency to produce behavior that is less predictable. It’s not that Agile methods are incompatible with predictable roadmaps, (See Scaled Agile Frameworks for suggestions on how to make Agile processes more robust) just that it seems that many agile shops feel less bound by plan commitments because they write it off to dynamic change.
However, it is the duty of a good product manager to have a roadmap for his/her product. Any PM who cannot say what they hope to accomplish with their product over the next year or two and plot it on an expected timeline, is not doing their job.
The challenge is in how to communicate it and to whom.
What is a roadmap?
Roadmaps are often seen as one of a few things:
- A concept document to communicate the direction of the product. It should help explain what direction the it is taking and perhaps where priorities lie
- Some feel it should be a list of committed delivery dates for features: A release plan
- Somewhere in-between
As you might guess, I think it ends up being number 3. The first is really too vague to be of much use. There may be a version at that level that is used in standard presentation decks and other marketing material. But this will not contain the specifics that some are trying to get.
Similarly, it should not be a detailed, long-term release plan. Doing so is a fools errand. Unless your organization is one of the few with rigorous, long term planning and scheduling, it will never be possible to achieve the schedule. Since most software companies are trying to be flexible and agile, the whole organization will conspire toward failure with this.
Ideally, the PM is able to work with the development organization to scope out the magnitude of the requested items, plot them against expected resources and put the proverbial ‘stake in the sand’ about when key features can be expected. This would be at a decreasing resolution as time goes out. For the next quarter it might be relatively specific about the feature and the month. But beyond that it will be more general about the feature and specify no closer than a quarter or perhaps half year. This then gives the company, it’s customers and prospects a sense of when they can expect things without setting dangerous expectations.
Constraints to consider
- Who is authorized to communicate the roadmap? Is it only the product manager? Or perhaps a trusted and trained set of marketing and sales people who can properly frame the discussion?
- Who is allowed to see the roadmap? Are prospects allowed at all? Under what conditions?
- How do you control the document?
- Do you record who has seen the roadmap?
What are the pitfalls of sharing?
First and foremost: If you don’t have realistic expectations of achieving the roadmap, it will always be a problem. See this article for more discussion
- Angry customers: Once any communication has been shared, there is the risk of disappointment. There are ways to mitigate this through careful communication and updates, but no way to prevent it.
- Inability to recognize revenue: In many situations, revenue recognition must be deferred on new sales if a meaningful future feature has been disclosed to a customer. The theory is that if they purchased based on the future promise, the revenue cannot be recognized until and unless that feature is delivered. Unmanaged, this can be disastrous to the business.
- Non renewal: In the SaaS world, constant improvement is expected. When roadmaps are shared and they don’t meet expectations – on features or time – customers may look elsewhere and they might not even tell you.