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] Product Roadmaps
David, at 37signals, wrote an article about the problems with product roadmaps. Thanks, Amar, for sending me the link. I believe the article was written by David Heinemeier Hansson, since there are several comments from “DHH” in the contentious debate that follows. Maybe the article was meant to be contentious link-bait (the blogging equivalent of trolling in a newsgroup). Maybe DHH/David hasn’t been exposed to a good product roadmap.
Either way, consider me hooked.
The comment thread on the article is fun to read, and gets emotional. And that’s a good thing. People should get emotional about how we create software. It is a creative process. Just because we use science and engineering disciplines does not mean it is not creative – we just use a different pallet of colors than canvas-artists. So emotion is good. I also contend that every great product is imbued with passion.
The comments were closed four days after the article was published (last November), so we can only chime in here.
Ade Oloneh blogged a well reasoned response to David’s article. Ade sums up the heart of David’s article really well, so we’ll just quote him:
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.
<cite>Ade Oloneh</cite>
Ade then goes on to describe the positive experiences that he and his team have had in developing a roadmap for the Formspring product. He generally mentions that he does not do any of the stupid things in the list above, and points out that roadmapping has worked well for them.
Jeff Lash, of Good Product Manager fame, added an excellent comment to David’s article, and another great one to Ade’s article with links to more resources. His main point:
A road map is a tool. Like any tool, it can be used well or it can be used poorly. Saying that it’s a useless tool because some people misuse it is shortsighted and irresponsible.
<cite>Jeff’s comment on David’s article</cite>
Even Pragmatic Marketing offers a class – just on product roadmaps! It would be money well spent for DHH and team to check out that class. They could create even better products, and improve their customer relationships.
The Argument For A [Smart] Product Roadmap
We’ve looked at the value of product roadmaps for enterprise software before. I guess our theme of “broad and deep” resonated a little, since several comments on the original article were ad hominem attacks fixated on the contrast between enterprise product management and small company product management. What we failed to do effectively is point out that this approach applies to all product development.
Now we get back to the “traditional” requirements work. An application has a set of requirements, which are prioritized, and which drive a product road map and implementation plan. This is a long term, deep, product-centric view of the world. The product manager focuses on the users and their goals, as well as the business stakeholders and their goals. These are combined to define the road map for the application. Much like any other product development.
<cite>Enterprise Product Management – Broad and Deep</cite>
That article was specifically addressing how product management within an enterprise is something that happens in the context of the enterprise – and other moving parts, and concurrent development of other products. All very true. But that is not the only reason for creating a product roadmap. In a response to another comment, DHH could have been responding to our article:
I think product road maps make a lot of sense when you’re trying to coordinate supertankers like Apple because the iCal.app team needs to have an idea of when Leopard is shipping. And the iTunes team needs to know when the iPods are getting updated.
But actually, I think calling that a product road map is stretching it’s generally accepted definition. That’s more of a company coordination map.
A road map for an individual product that doesn’t have strong dependencies to other releases is a lot more questionable in value. What exactly are you getting out of deciding 3, 9, 18 months in advance what to work on? What extra powers are you gaining? I’d say very little.
<cite>DHH’s comment</cite>
And that comment is the reason I decided to write this article tonight.
Elements of a Product Roadmap
A product roadmap is the product-manager’s equivalent of a project manager’s rolling wave planning. In a sound-bite, you provide short-term details (for the next release), and long term “broad brush” discussions. If you don’t plan your product to address the needs of a particular market, and then execute against that plan, the only way you will succeed is by luck.
The long-term view of a product roadmap does not talk about features, or even capabilities. What it talks about is problems. Problems faced by your customers, in your target market(s). Last week in one of Pragmatic Marketing webinars, Steve Johnson quoted Peter’ Drucker’s famous saying: “The aim of marketing is to know and understand the customer so well the product or service fits him and sells itself.” Steve points out that (1) this is the aim of product management, and (2) when Drucker says ‘customer’ he means ‘the customers in your market’ – he’s being abstract.
Each item in your product roadmap – specifically 3, 9, or 18 months out - should be a problem faced by your customer. If you’re a good product manager, you will tackle the most valuable problems first. In the course of those first three months, you may uncover even more valuable problems to be solved. So you re-prioritize! When you’re right, your customers will not complain – they will thank you. Because you will be solving a problem that is even more important to them. With each incremental release, you address the most-important unaddressed problem. And you learn more about your customers (and your market). When you learn that the plan should be updated, you update the plan. This isn’t spring cleaning, where you blindly follow last year’s plan because it isn’t time to replan. This is continuous improvement, applied to product roadmaps.
Not only do you get smarter, but things simply change.
When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?
<cite>Scheduling Product Releases</cite>
You can adapt to that change, or you can ignore it. If your adaptation is only to update the product backlog for the current sprint (release), then you will be forced to deal with that change again and again with every release. If you update your roadmap, you only have to deal with each change once. And that leaves you more capable to handle more changes.
There is value in sharing your product roadmap. You let your customers know that you know what problems you are going to solve for them. And you let them see that you have become smarter about their problems when you do become smarter.
There is risk in sharing your product roadmap. Maybe part of your distinctive competence as a company is that you understand your customers, and your competition does not. Why help them?
You have to decide if you share your roadmap publicly (or “privately” with your customers). But you shouldn’t hesitate to have a roadmap.
Value of a Product Roadmap
There is value to your customers in knowing your roadmap. You can use a roadmap to effectively manage customer expectations with less effort and more consistency – and a more visionary horizon. You aren’t just waving your hands at a “product vision” – which is important too – you’re backing it up with “and here’s how we get there.”
There is value to your team in knowing your roadmap. You provide context, which is critical to addressing stakeholder goals. At a more tactical level, context provides a framework for interpreting requirements. As much as we strive to avoid ambiguity in requirements, there is still always room for context to bring even greater clarity.
Just make sure you don’t become a slave to an old roadmap. Keep it current. Use it to chart your course. And when your course changes, update your roadmap.
Latest Articles
Comments on all Articles
