Again, I am coming from more technical software dev. and product management background so may be I am missing something here.

Can you please elaborate, what do you mean by “reflecting customer needs in a heuristic way”? Is that basically figuring out weight factors that define the final priorities?

What people call a “product road map” is usually a document that lists your long term milestones in certain order and assigns dates to those, right? And what I do not like is that certain order and the dates:

– People start using it as your master plan and fight a natural change which is inevitable (the dates are usually artificial anyway)

– Sales start setting certain customer expectations and quite often simply selling this when they get the dates.

One should be really careful publishing such a document. What I think a better document could be is just a couple of immediate milestones (your next 1 or 2 agile iterations) with dates and then just a list of likely milestones that you would like to tackle next but can not know for sure neither the exact order or the dates. This defines your direction, and thinking ahead.

I liked the comments by Mark Gladding, to the original 37signal’s post:

“Instead of publishing a roadmap I’ve published a Product Vision. This simply states a set of design goals that were used during development and a pledge to refine the product over time to better meet these goals.”

I believe that is the way to go.

It is quite ironic but even your vision will probably be changing over time . Just think of Nokia that started as a manufacturer of rubber boots and tires. Their vision was quite different then, I am pretty sure. I would like to see their roadmap from that time to see if it mentions a cell phone.

The roadmap is the favored method of illustrating a strategy. I agree with 37signals; a roadmap shouldn’t be a tool to get people to buy but a roadmap is a good tool to think beyond the current list of features.

Shouldn’t someone be thinking ahead?

My experience with VC funded companies is the same: have to to build a roadmap; have to show alpha, beta, …; have to deliver on time …; have to maximazi quaterly revenue. Actually most of the marketing books teach you the same: have to have a vision and a long term roadmap (on a vision I do not disagree at all although usually even that changes or adjusts quite a bit as you start getting your regular customer feedback).

Does it mean this roadmap business basically a broken means of connecting your software building reality with VC money and VC influenced management goals? I wonder if there is a better way. Or, as you said “such is life”. I guess ideally it would be nice to be able to run a business without any VC money .

As for the backlog of thousand features, I agree, it may get overwhelming but the main features that define your direction are usually already in it, right? If you mark those as your main themes (backlog management tools should probably help here), they would be your milestones or potentially alternative directions.

How you pick which milestone to focus on or which direction to follow is another big topic. Business value, ROI, … Most VC backed up companies probably choose the order of the milestones that result in immediate revenue. Theme focused iterations seem to be more than enough for me. Oh, yes, almost forgot, the VCs … they want the roadmap so we have to find a compromise, hence the rolling wave.

The reason, as you point out in your post, is that some people can’t get past how they are used to software being built. You have many people, in important positions, who refuse to see things any other way.

And you certainly can’t say, “no, I won’t take that 10M in funding that I need to start / keep my business, because roadmaps are obsolete.” You’re creating that roadmap.

My main thinking here is with VCs and senior management that refuse to see things any other way. The reality is, stubborn people refuse to accept software development any other way than, “we create a roadmap, we create a schedule, you hit all of your dates, you release an alpha, you release a beta, and then you ’ship’.”

It is a load of crap that software works BEST this way, or that this is the only way. I can point to many specific examples in my career where if dates weren’t the deciding factor in product launches, or a “beta” was released because “that’s how things are done,” or some other archaic reason, the product would be WAY better off.

But, such is life. I happen to find roadmaps useful for getting big picture. Will they change? Yes. But do you need direction and focus? Also yes. You can’t get a good 2 or 3 quarter product overview from backlog lists of hundreds (or thousands) of features / bugs. I find constantly evolving theme-based roadmaps the best way to achieve that.