I watched a lot of movies in the 1980’s and 90’s, including many of my favorite movies of all time and quite a few that I routinely watch again. Mixed in with those are a great many others that tend to blur together in my memory, especially when I also saw the sequels. I learned recently just how blurry some of those movie memories have become as I tried to remember a specific movie involving a map that was burned or tattooed on to one of the characters (and before you ask it wasn’t Waterworld or Prison Break, neither of which I’ve seen). The scene in Raiders of the Lost Ark where the amulet gets burned into the one guy’s hand is close, and the rolicksome search for the treasure map in Romancing the Stone captures some of what I was trying to remember, but neither of these is right either. After racking my brain for weeks and asking several people to help me think of where this plot element comes from, I’m starting to wonder if I simply combined aspects of several movies into a scene not actually found in any.

Why does any of this matter? Because for my next blog post about Agile planning I want to talk about the product roadmap. I’ve already written about the broader context of planning for software development in an Agile environment, discussing the overall planning framework and the crucial importance of listening to the market when creating long-range vision for how a product or a portfolio of products and services will evolve. As I focus now on what a product roadmap is and how to develop one, I wanted to root my observations in the context of a cool movie I remember that stresses how valuable a good map is when embarking on a journey to find true treasure. In spite of my inability to remember where I saw the scene I wanted to use (or my grudging admission that maybe such a scene only exists in my addled memory), I do want to share some thoughts on product roadmaps, specifically about who wants what from a roadmap and the most important things a good roadmap provides. Hopefully my thoughts can offer some useful direction in helping you craft a roadmap that guides your team toward the treasure of a great product.

If you follow me on Twitter you know I’ve been reading a lot about product roadmaps in the past few months and tweeting out links to some great things I’ve found (and if you aren’t following me on Twitter then please do so @asbiv). There are lots of great tools available to help create a product roadmap (I found this one from ProductPlan through a link from someone I follow on twitter: http://bit.ly/N8e48p). Placing the product roadmap within the broader context of the Agile planning onion that I discussed a few posts ago, crafting a roadmap fits within the product level of planning. Planning at the product level involves creating a 12-24 month plan about key features to add or enhance. Planning at this level also offers a time frame for when these new capabilities are expected to be available for users.

What specifically is a product roadmap? The answer to that question is closely tied to a second question, namely, who wants what from a product roadmap? When the sales team or the development team asks to see the product roadmap, what are they looking for?

Generally when the sales team asks to see the product roadmap they want to know how aggressively to sell the new features being developed and when they can promise enhancements to prospective clients. If clients or prospects want to see the roadmap they often want to know when specific capabilities that they want will be ready for them to implement. If the management team asks to see the product roadmap their concern generally is how well product development is tracking with the planned time frame and budget previously articulated. And for developers themselves the primary reason they want to see the product roadmap is to know what new functionality is on the horizon so that they can start high level planning for this development.

While a product roadmap might shed light on all of these concerns, none of them quite captures the key aspects of a good roadmap that product owners are looking for. A product roadmap is not designed to be a Gantt chart or a project plan that shows a set of development commitments to be delivered over a given time period. It is not a static document developed at the start of a project and then left untouched. In an Agile development environment, a good product roadmap is a planning tool reflecting the current best idea of what features will be worked on when. It is more about product priorities than about delivery dates, more about product themes than specific features. The development process always involves uncertainty, but the product roadmap represents the best thought from the product manager about what the most important features are and the order in which the team will work on them. The roadmap should not whipsaw from sprint to sprint (any more than a driver should start heading to Boston, then after a couple of hours start heading toward Houston, then later that day start driving toward Miami). Well thought out roadmaps may change based on new market intelligence or technological innovation but fundamental product priorities ought to be more consistent (just like driving from Baltimore to Boston might involve a detour to New York depending upon traffic patterns or the chance to meet a friend but the trip should still head toward Boston).

In an Agile planning process, the product roadmap provides all of the stakeholders (from prospects to developers) with a sense of where the product is heading and what the highest priority areas for new development are. At the same time, the roadmap also provides some indication of what probably won’t be developed (just like the drive along the east coast to Boston will not involve a stop in Chicago). Roadmaps communicate the focus and priorities for product development and that means both what is most important to work on and what has not yet made the list of high-value features. Again, priorities can change with new market input, but in the Agile planning process the product roadmap reflects the best current thinking on where the product is headed over the next 12-24 months.

A product roadmap that reflects development themes and priorities rather than strict time commitments squares well with Agile thinking about product development. It may not answer all of the questions that sales folks, senior management, potential clients, and even developers have about what will be delivered when, but it does communicate current expectations on the order in which enhancements will be worked on. In a development methodology that emphasizes continual iteration and learning along with the ability to respond to new information about market shifts, client needs, and technological innovations, this type of product roadmap is both more useful and more realistic than a static set of feature commitments made at the start of a development process. Of course, the tension of balancing these Agile principles with the demand for some reliable commitments means that in truth, it’s not that simple.