As a regular producer of software product roadmaps I certainly agree that static roadmaps (updated once or twice per year) don’t account for changes in business decisions or challenges in development and can lead to disappointment for stakeholders. Additionally for a small group like 37Signals that has a large external stakeholder base but small internal group of stakeholders, it would be a wasted effort since they generally know the plan. Communicating a product roadmap to the wide group of external stakeholders wouldn’t generally be fruitful other than potentially catching a few folks that are holding out for a feature. For other organizations roadmaps can be an effective tool for business prioritization and communication. With feature requests from multiple stakeholders (internal and external) there are always conflicting priorities with a limited number
of resources.

A roadmap (depending on it’s composition) can be a great tool to help an organization capture, evaluate, prioritize and communicate features as well as overall business direction. A quick Google search will yield a variety of roadmap formats from a feature matrix to a very high-level series of features over a period of months, quarters and years. Regardless of the format, a roadmap that isn’t based in business goals, effort and impact, an evaluation of effort is for show only. A good roadmap is a communication tool that helps normalize dialogue with stakeholders from the executive team to the sales team in the field. Additionally, regular (montly/quarterly) roadmap reviews with the executive team help prevent ‘executive amnesia’ and publishing it keeps internal stakeholders informed and focused.

While I agree that formalized roadmaps may be overkill for a small development group focused on a product but they certainly can be helpful for other organizations with more complexities.