About a year ago I published a blog post called Roadmapping - How your product finds its way. Since then we have found that people often refer to this post because: A startup will often live or die based on its first product release. Did it get released? Did people find it useful? Good roadmapping dramatically improves your chance of getting to “Yes” on these critical questions.

The summary is this: A roadmap is a prioritized list of features that you want to deliver. A good roadmap will show a short list of high-impact features for the next release. To achieve this nirvana, you go through three steps:

1. Brainstorm, and collect all possible requests.

2. Categorize, vote, and estimate to add some information.

3. Sort by priority. Your next release should sort to the top.

Below, I list some practical hints that have helped us run this exercise on short notice.

PRESENTATION
We have started using a Google Spreadsheet to hold the feature lists for roadmapping - and it works great. One of the greatest benefits is that everyone can view the spreadsheet in real time while we have a prioritization meeting, and mark votes on it.

The columns on the spreadsheet include:

Priority. Usually rank from 1 to 5. This is what you assign in your roadmapping meeting. Ideally, you will have only a small number of 1's.

User. Who is this for? Before you start, you should make a short list of the user types (see below).

Effort. This can be very rough. I think effort can be easy / medium / hard. You will do an easy before you will do a hard.

Theme. This is a large scale grouping of features that you could advertise as the focus of a release. You should suggest a small number of themes before starting. Themes can be based on different use cases, different users, or internal requirements like "Quality and availability".

Description of the feature

PREPARATION
It takes a few days to prepare. 

• Ask people to add their lists and requests by emailing a link to the document.  As I noted in the previous article, it is important to let each participant add to the list, because this makes them more likely to support the process.
• Prepare a short list of user types, with a description of each user
• Prepare a short list of themes
• Have an expert remove duplicates from the list

SELECTION
What to put in the feature list? I suggest the following principles:

Features should come from "use cases" or "user scenarios" that describe REAL individual users. Groups of users or imaginary users have a lot of imagined needs, and can't answer questions about priority.  In my experience, generic or vague user cases are the biggest problem in any roadmapping process.

List user-visible features, not technical components of those features. Components and tasks that are not features, but are implementation details that do not impact whether we want the feature in a particular release.

This rule is not quite valid for the generic "performance" and "reliability / uptime" features. Sometimes you need to list technical components that go into performance and reliability.

Every feature is designed for a user. System administrators and editors are valid users -- they need features, too.

More detail = good. It is good to break a feature down into multiple features, because that gives us the option of implementing the simpler version first. For example, a file upload feature could break down into three features: upload a file, upload multiple files, and create a thumbnail from an uploaded file.

FILTERING
The goal is to find a small list of priority 1 items. If you have too many priority 1 items, then do the following exercise. Demote most of them to 2. Next, try to split the priority 2 items into smaller deliverables. Then you can promote a few smaller things back to one.