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] 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 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.

16 thoughts on “Don’t Build a Stupid Product Roadmap!

  1. Scott, Thanks for the great post. Product roadmaps when done well are valuable. As you say, it’s a strategy, and strategies can and should change. Sharing them with customers is valuable: it’s win-win. When it’s shared, the customer gets to prepare and plan for what’s coming, and you get to learn if this roadmap matches your customers needs. I’ve always found it valuable when vendors share their roadmaps with me.

  2. Thanks Bill!

    Couldn’t agree more. What do you think about the angle of showing “We’ll address problem X in Q3” versus “We’ll build widget Y in Q3”? I think that’s the twist that allows a product roadmap to encourage change, rather than prevent it. Nothing should prevent a team from changing their tactics as they get smarter, imo.

  3. Great post! I think this is the key premise of your defense of product road maps, “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.” However, I suspect the folks at 37Signals would agree with this statement. So what is the difference?

    Apple and Steve Jobs are infamously secretive about the future of their products. In this sense, they have no PUBLISHED road map. However, they spend a lot of time thinking about the road maps for those products. The difference here is the secrecy.

    Open source projects/companies struggle between transparency and useful secrecy (like the thought that goes into a “smart” product road map). I suspect many successful OSS projects have secret short and long term road maps. However, they try to get the elements started and sometimes even get them fully implemented before they talk much about them in public.

  4. Thanks, Larry, and welcome to Tyner Blain!

    I think, realistically, that the difference is that the 37signals folks got some bad guidance along the way about what a product roadmap is and should be. Their criticisms of “that thing they tried” are all spot on. My point is that if it was a product roadmap, it was a bad one.

    Your points about the risk/cost of making a roadmap public are spot on. One current OSS project that is publishing both short and long term roadmaps in advance of development is the gnomepal project. Chris Pirillo is leading the charge on getting a ‘turnkey’ build of drupal developed (as open source) to make it much easier for people to deploy drupal-based solutions. A very exciting project (Google for ‘gnomepal’).

    Thanks again!

  5. @ Scott
    As always, another fine, thought- and discussion-provoking post.

    @ et. al.,
    My $0.025 is that along with the general practice of Product Management, roadmap is a term that has different meanings for different people. The important thing is to first determine what it means for YOUR organization.

    It’s easy for a PM to create a roadmap for their own use and then see it presented (or asked to be presented) at the quarterly sales meeting or an executive/board meeting. All of a sudden, the roadmap is being used for something it wasn’t intended for, which is where I see a lot of the frustration with roadmaps coming from.

    Imagine if you wrote up some notes from a customer visit and then found that your Dev team wrote a PRD based on those notes. The notes were certainly valuable information (otherwise, you probably wouldn’t have written them down), but are they sufficient or appropriate as the basis for a requirements document? Doubtful.

    The same goes for roadmaps. They are great for their intended purpose (whatever that may be), but when they get used more broadly, there are gonna be problems.

  6. Thanks Ivan!

    You make a great point – any tool or artifact can be misapplied or otherwise abused.

    I think a good product roadmap could be used as a view of the (currently planned) future for a product with other groups within the company. As long as you indicate that it is the plan. Some people will be more comfortable than others with the prospect that a roadmap can change.

    The future always has a degree of uncertainty, and the further in the future you look, the more uncertain it is. When people understand that a roadmap reflects “our plan for the future, based on what we know now” they are usually ok with it.

    Imagine a product roadmap for one of the American auto manufacturers a few years ago. They might have targeted their most important problem for 18 months out as “the car interior is too noisy for hands-free cell phone usage.” When the environment changed (gas prices crossed a threshold price), they could have changed their 18 or 12-month “most important problem” to be “cost of operating the car is too high.”

    Arguably, these companies waited too long to make that change. But no one today is criticizing the new focus on economy – the complaints are about the delays in making the change. And the companies, and their employees are feeling the pain. As are the consumers, who now have fewer products available to choose from that address their very real problems.

    Thanks again!

  7. Pingback: Scott Sehlhorst
  8. Pingback: Brian Schnack
  9. Pingback: Paulo Branco
  10. Pingback: Brian Schnack
  11. Pingback: Brad Dixon
  12. Ok. So there is value in a roadmap (internally and with customers to a controlled extent). And they should be statements of how you will execute on your company’s vision/mission in terms of what problems you intend to address in a prioritized and sequential manner. Further, that the roadmap should be reviewed and reviewed as your market conditions and prioritizes change. So how do you prioritize and size problems in a way that is realistic given the resources you currently have, and are not sure you will have next year if the next year doesn’t go as planned (as it has the last two years for many companies)?

    1. I’ve used one technique effectively in a few different environments to manage/predict a roadmap when resource-levels are subject to change. Based on a “best guess” level of resources (current, planned, whatever you think is most likely), “draw the line” – the projects above the line (in priority order) “make it” and the ones below don’t. Then draw a second line, representing what you think you could realistically accomplish with the different staffing level.

      It definitely works well for managing expectations to draw two lines. I’ve seen teams label them as “likely” and “possible”, I’ve also seen “committed” and “stretch goal.” I also mention that these are out “most likely expectations, we’ll do things in order, we may adjust the order, and we’ll get as far as we can.”

      I’ve also used this to justify additional headcount – by showing the potential value of the things we could accomplish with new people, that won’t get done without them.

      Does that help?

  13. Pingback: Katie Viviers

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.