You need a product road map
November 9th, 2007 by Ade OlonohI 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 FormSpring, 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.
November 10th, 2007 at 3:46 pm
I could not agree more, Ade. I enjoy having a ‘loose’ roadmap that doesn’t have clearly defined dates and deliverables. But it does have very solid priorities as well as grouping into sections. Once we decide to embark on a project plan and build requirements, I gather the applicable product ideas and build them in.
Often, our vision of our product is skewed by the loudest or the largest clients - and we lose control over what is best for the entire product to compete. A product roadmap provides us with a clear direction. It needn’t be the exact coordinates, but when everyone sees what ‘true North’ is, we wind up getting there much faster.
November 10th, 2007 at 5:56 pm
Agreed — my comment on the post said much the same. Maybe they’ve only seen roadmaps being used badly, I’m not sure, though even in the discussion they admit that they’re not against road maps, per se, just perhaps sticking too them steadfastly or publishing them too broadly.
The funny thing is that there’s lots of good resources about the benefits of sharing your roadmap and how to manage risks when sharing road maps.
Road maps are a tool, and like any tool, they can be used well or used poorly.
Jeff
My blog: How To Be a Good Product Manager
November 11th, 2007 at 10:20 am
[...] Recursive Function Blog » Blog Archive » 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. (tags: software development productmanagement productroadmap roadmap) [...]
November 12th, 2007 at 11:34 am
Couldn’t agree more. We use roadmaps with our customers to elicit feedback on what’s important to them. Ask them the question and they have no answer - give them a roadmap on what we think they think is important and you get great feedback.
It also helps us to avoid getting into the freedom-crushing business of customer-specific functionality. The roadmap helps us to keep customers at arms length when it comes to defining what goes into our product - and that is real important to us.
November 12th, 2007 at 1:48 pm
I take anything from 37 Signals with several large rocks salt. They are far more interested in trying to feel important rather than addressing what actually works.
April 28th, 2008 at 9:50 pm
Don’t Build a Stupid Product Roadmap!…
Logic is a funny thing. People can make the following argument: “Building a stupid product roadmap is bad, therefore, don’t build product roadmaps!” Ahem. [Author cracks knuckles] Read on for a rant.
The Argument Against [Stupid]…
May 5th, 2008 at 10:12 am
I agree with both you and 37signals, though you’re not talking about the same thing…
In the 37signals blog he was talking about a “detailed plan for execution over a long period” while you are talking about “a general idea about which direction to move in” so I don’t find your rhetoric contradicting each other.
A detailed “roadmap” (the way DHH means) basically puts way too much constraints on the developers on *most* projects and I think that’s the reason why DHH says what he says. It’s also quite funny since I gave the EXACT SAME arguments as DHH gave in his blog to our CMO a couple of months ago when he virtually begged me for a roadmap to “increase predictability for our existing and new customers”. My answer was basically; “sorry, not before hell freezes over”…
(in a way more polite tone though that is
.t