37Signals recently published a blog post titled "You don't need a product roadmap" that suggests that roadmaps are generally bad since they are rarely met. Additionally they suggest publishing a roadmap is "The slippery slope of selling tomorrow over today."
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.
Rob, from what I've read lately I would say that the high-level term for 37 Signals' design and development process is known as "winging it."
--Christian
Agreed and if it is a team of 5 working together (including executive oversight) then I can see it workingRG
I'm with you, Rob. I like a lot of what 37signals does, but some of their recent posts have left me scratching my head.
They seem to be railing against road maps that are published and never updated, used as a promise to sales and customers, and never shared or discussed with other stakeholders. Well, of course those are bad! But that doesn't mean that all road maps are bad.
A road map is a tool. Like any tool, it can be used well or used poorly. Saying "you don't need a road map" because they've only seen them mis-used is like saying "you don't need graphic design" because you've only horrible examples of it.
Jeff
My Blog: How To Be a Good Product Manager
Jeff, Yeah, while I certainly respect the folks over at 37 signals and their apps, the broad blanket statements aren't always applicable. It certainly helps predicating some of their posts with "With a small development team _________________." since from that perspective it does make sense. And again, what is their definition of a roadmap. If it is a nice PowerPoint slide developed for a January kick-off, you will certainly have some disappointed folks if they are holding the same slide in December of that year.