Roadmapping: How Your Product Finds Its Way

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Roadmapping: How Your Product Finds Its Way


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.

* 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?

Posted by on Tue, Sep 26, 2006


I suggest going with only the first 3-5 main features of the product for the very first release. You need to get something out there as fast as possible. After the first release you can always add the other features later on, and you'll also have some actual user data on which features are needed and which aren't (as opposed to guessing).

That being said, do a really, really good job at those 3-5 features you picked. You can justify not releasing not too many features in the first release, but there's no justification for not doing the best job you can do on the few that you do release..

posted on Tuesday, September 26, 2006 at 10:37 AM by Ali

"two days for emailed comments" -- or, use a dynamic feedback aggregation tool of some kind.

At the Future of Web Apps conference in SF earlier this month, Kevin Rose of Digg said he employs a full time person whose primary job every day is to aggregate user feedback sent in via email.

For development of, we maintain a topic dedicated to aggregating users' feedback at

posted on Tuesday, September 26, 2006 at 10:53 AM by John Masterson

Two comments that can help manage the risk of a release …

In step 2 above, categorizing, … I would recommend tagging each feature in two dimensions 1) value to the customer/business 2) complexity/risk/cost. Simple low/med/high values are fine. High-value/low-complexity items are, of course, ideal. Too many high complexity items may be fatal even if the value is high. A conservative approach would include some lower-value lower-complexity items to ensure that the release has some features should the higher risk items get into trouble.

A feature list for a specific release should ideally be independent of each other – failure to deliver one should have little impact on other features. This helps achieve the release on target even if features have to be bumped.


posted on Tuesday, September 26, 2006 at 2:16 PM by Andrew Lavers

"I believe in releasing early and often. This allows you to minimize risk, and to collect customer suggestions for rapidly improving the product. "

Agree, early and often is right. But here is an embedded risk as well. First impression can be only one time. If you release too early to too many customers they may be disappointed by the product so much that won't even ask (and then see) your roadmap. A ballanced approached can be not to go for a big market with the first product (which is anyhow rather weak and shallow if you release early) but to scope a small group of trusted customer (maybe with additional priveledges to infulence on the product, maybe with discounts in prices, maybe with other amenities) that will want to try the product and provide feedback. The risk is to go too wide too fast with too young product.

posted on Tuesday, September 26, 2006 at 4:33 PM by Roman Rytov

Great points about prioritizing! I would add three things.

First, if you find that you're having a discussion that says, "the product won't succeed unless it has EVERYTHING" in a large set of features, please try to rethink your rollout strategy. If the product is a 1.0, and your vision for it is large and intricate, you may be getting into trouble.

Second, it is a really good idea to give your 1.0, your 1.1, and your 2.0 products codenames as you do your prioritizing. This will help you imagine all three releases as having their own integrity as products. So, you can decide which features go in which release in a way that is more meaningful than "we don't have time right now."

Third, this same roadmap technique is a good extreme-programming way to plan your pre-product baselevel releases as well as your product releases.

posted on Tuesday, September 26, 2006 at 5:04 PM by Ollie

Though I agree with what you say in the article, I think your focus is slightly off-centre. In my experience training development groups and marketing groups to try to use agile methodologies, the key point is the release date. If you don't make a hard-and-fast rule that the release date will not change under any circumstances, many groups will be quite happy to let it slip a day or two for that one extra thing, or delay "just a little bit" for some really cool feature. Before you know it, you're months behind, or not releasing at all.

If you fix that date, and make it immobile, the feature set issue can often sort itself out. As the dealine looms, people will start to compomise, because they will have no choice.

Also, I find it best to fix a release schedule indefinitely into the future. For a packaged software product, that might be every year or six months. For a web site, it might be twice a week. Regardless, as you point out, it makes life a lot easier for those whose features don't get in if they know when the next release is going to come out. (But they'll only know this if release dates don't move.)

posted on Tuesday, September 26, 2006 at 10:09 PM by Curt Sampson

In response to Curt, i quote... "As the deadline looms, people will start to compromise, because they will have no choice." This certainly is true in a development process, but i feel its too loose. Compromises should be made before development begins, if you are compromising as deadlines approach things can start to get sloppy. This is something we definitely need to avoid. I agree with the ' set in stone ' release dates. If you have a good team who is on point, projecting your compromises based on a deadline should not be an issue. This way, you ensure a smooth dev and a clean, well coded feature rich release that is ready for promotion.

posted on Thursday, May 17, 2007 at 4:36 AM by nothingGrinder

Well, it's all fine to say that the compromises should be made before you start, but even if you have a planning process that will let you predict to that level of accuracy what your development team can do, you'll discover unanticipated things along the way that will lead you to add and drop some ideas. The important point is that when you do hit that inevitable time when you've either got to drop something or let the deadline slide, you drop something.

posted on Monday, May 21, 2007 at 4:44 AM by Curt Sampson

Comments have been closed for this article.