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.

Peter Merholz recently gave a presentation where he advocated looking beyond designing products and design the entire experience strategy. I absolutely applaud the concept of taking a systemic approach in designing the customer experience but would first advocate teaching the concept of ‘product’ first. Too many people have yet made the leap from project to product. Too often I find that folks don’t recognize that their site is a product nor do they have the tools and processes in place to manage it.

The first step to recovery is recognizing your website is a product, not just a project. And, this is a good thing.

A colleague asked me “What’s the difference between a project and a product and why does it matter?” In short, projects have a fixed beginning and end where products have a lifecycle that can be comprised of many projects. Managing a website as a ‘product’ allows you to view it strategically, not just for the short period of time. When you are living from project to project everything is a priority and often an emergency where you implement partial requests and the result can be half-ass implementations with everybody angry.
As Joel Spoelsky points out, “A schedule is like wood blocks. If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks.”
Systemic thinking certainly helps in defining strategy as well as a more complete user experience but good process and tools help to execute tactically. A simple process of capturing feature requests, evaluating the requests, prioritizing and assigning them to releases is key to successful execution. Combining that with a published (and visible) roadmap helps the folks manage the day-to-day.

While I certainly agree with Peter that understanding the systemic experience is key to ensuring the complementary implementation of products and services, there is still some fundamentals that many folks haven’t picked up yet.