As a quasi-product/project and design manager, I frequently have to organize a pipeline of features very quickly, while simultaneously learning the development team’s capacity, and priorities for the tasks on the business team’s agenda.

More often than not, the business team has a pretty good idea what they want; they just don’t know how to get it done. The dev team knows how to do practically anything; but don’t know what to do first.

If you wait long enough, the biz team will quickly set unrealistic deadlines on pretty much everything, while the dev team will completely freeze for lack of direction and clear priorities (or they’ll go do whatever makes sense to do next, which (if they’re good developers) isn’t the same as what the business wants.

To prevent the above paralysis, I build a simple roadmap as quickly as possible, containing every conceivable feature (larger than one iteration), arrayed in a staircase, as if they were going to be done consecutively. The roadmap doesn’t require MS Project or anything more sophisticated than a table-editing tool like Excel or Powerpoint. Even a WYSIWYG Wiki editor page can build one, of sorts.

Here’s how it works:
Size every feature roughly by iteration. It helps to group them into same-size increments. For example, if your product needs to grow an inbox, break it down into roughly three-to-five iteration-length stories, and shorten their titles like so:
Send mail between users
Add inbox page and compose, delete and reply actions
Add archive, group lists and share-this-page actions

Once your feature list is more or less laid out, line them up in priority order, as if they had to be done one right after the other.

The trick to prioritizing is that if you don’t know the priority, make it up. The ultimate goal of a roadmap is to get people to change it, so the more “wrong” the first version is, the more likely it will be fixed. The roadmap’s secondary purpose is that it shows that everything WILL get done…eventually.

Now that you have your feature list in priority order, create a spreadsheet with the following:
The first column contains each of your features
The second column contains one of five or six loose categories (I lean toward Usability, Marketing, Adoption, Performance/Stability, and Interaction, but they could also be broad feature sets as in Inbox, Authentication, Profiles, Search, etc).
The 1st row contains the year, merged across all of the columns below it
The 2nd row contains each quarter, going out at least one year from today
The 3rd row contains each month of each quarter

Assuming your iterations are 2-4 weeks long, you probably don’t need another row. Another important concept with roadmaps is that they are more effective as a communication tool than as a planning tool. The aim is clarity, not necessary precision.

Once you have the columns and rows laid out, the fun part begins.

Assuming your features in the left column are approximately the same size, lay them out in a staircase pattern, starting in the upper left corner, and putting the next one box down, then over from the previous.

When you are done, you should wind up with something like this:

Sample roadmap illustrating staircase feature pattern

In the above sample, you can see a completed roadmap.  Note that once your features are assigned to categories, turn on Autofilter in Excel to drill down to specific categories for presentations and group discussion.  Do the same for specific months to see which features fall on certain months.  In the above example, over 100 features run down the page, each with its own staircase pattern, because in our case, we could achieve approximately two large-ish features a month.

I should definitely note that while there is a lot of guesswork in the above, you MUST not evaluate feature sizes without either full knowledge of the technical platform’s abilities, or full cooperation with the development team.  Do not distribute more widely until at least the rough story sizes are agreed.

I’m leaving a tremendous amount of “management” stuff out of this, but I recently built my fourth such roadmap, and since it’s becoming a habit, I thought I’d share with others.  I’ve had pretty good feedback wherever I’ve used this technique, due largely to the increased confidence from colleagues who are happy that their ideas are finally represented on paper, in an (albeit lengthy) easily understood plan.

Once you’ve accounted for most of what the business has asked for, you can begin working hard on the things they really need, as those will float naturally to the top of the roadmap.

Once published, from that point forward, every new feature goes at the end of the roadmap, even if it’s two years out.  Your stock answer to the question “Can you do this?” should always be “Yes”, but the correct question should really be “When?”.  The roadmap above should help you and your colleagues answer that question much more effectively.

Best of luck to you and your projects,

Bryan