Note: This is a guest article written by Andy Singleton. Andy is a career software professional and knows a thing or two about building and launching successful software products. He is currently the president of Assembla which brings open source processes and applications to the world of enterprise software.
Roadmapping: How Your Product Finds Its Way
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.
A roadmap is just a list of the features that you want to build, sorted in priority order. It might be easy for one person to make a list like this. However, it gets a lot harder if you are trying to get an organization, even a small one, to agree on the roadmap. It gets even harder when the stakes are high – when you have only one chance to release a version 1.0 of your product, and you need to make the right decision about what goes in, and what doesn’t go in. You can’t risk bloat, delay, mistakes, cloak-and-dagger politics, or bloody civil war.
I have developed some roadmapping techniques to get through the process smoothly and make the right decisions. I have used this with individual entrepreneurs, my own products, venture funded startups with 50 people, and big companies with separate divisions for product development and marketing.
I believe in releasing early and often. This allows you to minimize risk, and to collect customer suggestions for rapidly improving the product. My goal is to find a small set of the most important features to go into the next release. If we have the discipline to do that, our chance of success is high. If it is a new product, I am looking for the minimum useful release, which will start a process of incremental improvement.
In order to be free to apply this much discipline, you need to be politically aware, and you need to make sure that everyone feels that his/her request will eventually be accommodated. If people believe they will get what they want eventually, they will let you cut down the next release to get the most gain in the shortest time.
I recommend three stages:
1) Brainstorming. The goal of this stage is to collect all of the outstanding requests, develop ideas, and make sure that no one feels left out. In this stage, we expand our list as much as possible.
2) Categorizing, Voting, and estimating. In this stage, you try to get some consensus on what you should do and can do. Put a time bound around this – for instance, one hour of discussion, or two days for emailed comments.
3) Sort by priority. You may need a benevolent dictator to make the final sort. Then, go down the list and draw a line under the minimum set of features that will make a useful next release. If this is a first release, you want to make it lean. Make sure that everything you have above the line really is needed for the product to be useful. If there are any complicated features on the top of the list, try to break them apart into steps. In this stage, you apply discipline to shrink the next release.
Voila! Your shining prize, your next release, is now at the top of the list.
If you are making software, you now have a roadmap that you can drop directly into the ticketing system for an agile development process, complete with milestones or “Iterations”.
You can create a more complete roadmap by drawing more lines, representing additional future releases. It’s a good idea to assign dates to the releases. Once you pick the dates or the release frequency, you should always release on time. This fixed-time, variable-feature strategy is an important part of agile methodologies. It reduces risk and makes it easier to gather feedback that improves the product. If you can’t complete everything that is scheduled, just move the bottom items to the following release.
Hints
* Break features down into smaller components. Often you can grab something simple out of what seems to be a more complex feature, include it in your first release, and move the less obvious stuff to a later release. That is a big time-to-market win.
* Consider specific “use cases”, or “scenarios” – really specific stories about how the product will be used, with the names and jobs of actual people you know. This will be most helpful in expanding the list of feaures.
* Define and prioritize themes, which are groups of related features. It’s easier to get consensus on themes than on individual features, and it helps everyone focus on the big picture. This is especially helpful if you are working on a mature product that already has a long list of customer requests.
* Use voting, and give everyone 10 votes. A voter can use all 10 votes on one feature, 1 vote on each of 10 features, or any other allocation of 10 votes.
ALWAYS schedule a follow-on release shortly after the upcoming release. It’s much easier to bump things out of the coming release and get it out on time, if you know the things that are getting bumped will be in another release soon after.
What are your thoughts? Have you used product roadmaps within your startup? If so, what worked and what didn’t? Any tips you’d like to share with the rest of us?