You need a product road map

I enjoyed the 37signals book and agree with a lot of their philosophy, but was baffled by today’s article, You don’t need a product road map.

The article makes a lot of assumptions about people who have a product road map:

• They add all feature requests to the road map
• They don’t do due diligence before adding features to the road map
• They sell their software based on the road map, not the current features
• They share their road map with current and prospective customers
• They promise features to current and prospective customers

I agree that all the things above are bad, but to me this doesn’t translate at all to: don’t use a product road map.

We use a road map internally for Formstack, although it’s very informal — deadlines are vague, items are not well defined unless slated for release in the near future, and we take a lot of liberties in adding/removing items when necessary. But having a road map is the best thing we’ve done to help focus development so that what we create has maximum value for customers.

We had to make a conscious decision to put together a road map based on an overall vision for the product. Our list of feature ideas and requests is very very long, and if we sat at the keyboard each morning and asked, “what do I build today?” it would be far too easy to slip into picking the items that are easy or fun. If you pick new features at a whim, then you end up with a horrible product overall, and one that hardly appeals to any of your customers.

And while I would agree with 37signals that writing a 5-20 year plan is ludicrous, I think it’s even more dangerous to not have any plan whatsoever, even if it’s only a few square feet of space on the conference room whiteboard.

[Updated references to Formstack to prevent confusion about the name change]