blogpost about roadmaps
SOFTWARE DEVELOPMENTPRODUCT OWNERPRODUCT MANAGER
06/11/2017 • Stijn Schutyser

Dear Roadmap

Dear Roadmap,

We have been together for years. We started off great. Full of ideas, young, flexible and in love. We wanted to do so much, in so little time. These feelings, however, are no more. I am writing you this letter because I am struggling. I feel frustrated and disappointed. I’d rather keep you in the closet than take you along. You have become more of a liability, a fetter, rather than a useful companion.

I want to be transparent about my frustrations, in hopes of working them out. So, please, let me tell you my greatest concerns:

  • Lately you have become extremely inflexible. I wanted to take another turn, change our heading, but this was a no-go. You blocked and hindered the entire process, grumbling at each change.
  • You require a time and budget estimation at all times, even for our far-in-the-future ideas. These detailed timings make you cumbersome and unwieldy. Moreover, I can never achieve the fixed timings that you have set. They are unrealistic. It is a disappointment from the start, for me as well as our stakeholders.
  • As far as stakeholders go, I have the feeling that no one really agrees with you. No one is involved, let alone informed. There is a lack of trust in you: there is no buy-in from management nor the engineers.
  • On the other hand, you have a pretend perfection: “It is on the roadmap, so it will be done”.
  • You focus on listing solutions. I do however like to know the real (customer) problem we are solving. What value are we adding?
  • You have become detached from reality. You are totally not in line with our business strategy and vision.
  • There is no uniform definition and process on how to use and build you. I feel that I am reinventing the wheel each time. Each time doing the same thing over and over, with no clear result.

You are a fictional tool, only here to relief the anxiety of our stakeholders.

So is this goodbye? Time for something else? I hope not! Hopefully we can continue together and improve our relationship with the following ideas.

You should be a communication tool rather than a release plan

First of all, you have to be a real Road-Map and not a Release or Project Plan. Since when did you change from ‘a map of possible roads’ to ‘a timeline’ anyway? You and the release plan are different things. You both serve different purposes and should therefore not be mixed up. Where the Release Plan focuses on when to get there, you should focus on where we want to get. You should be the one that keeps the destination in mind, while the route to the destination can change. There are multiple ways of getting there, each with their own timings. This means that you have to keep a focus on the (user) problems and not the eventual solutions. Keep the focus on the outcomes that need to be achieved.

You should be a statement of intent and direction, with a focus on delivering value.

Even more so, you should be the strategic communication tool that is used to get everyone aligned. You are forward-looking: how is the product likely to evolve (what goals will it fulfill?). This should be the discussion point between all stakeholders. You serve as the tool to align them. You make sure that we gather and process feedback and make an agreement across all stakeholders: management, engineers, product managers, partners, but also, and more importantly, the actual product users. This may also mean that you are shared externally, all to achieve a common understanding on the product strategy, evolution and assumptions.

You are not an artefact that can be delivered, but a process with no end.

To realize the above goals, you should not be about the artefact (the roadmap), but rather about the process and the communication that you trigger. You are not a thing that can be delivered. You are a process with no end and you evolve as we learn. With each Minimum Viable Product, we validate more assumptions and need to align our goal and possible roads with this.

To support you in this process, we still need something tactile. Something that the stakeholders can see, annotate, adapt and shred. Something that contains our product vision, the business objectives, outcomes and priorities. A tool that supports us throughout the entire product lifecycle. The form of this tool is not important, the content and the communication it triggers is.

Dear roadmap,

I do still want to have you by my side. When used correctly, you are able to:

  • Put plans in a strategic context
  • Focus on delivering value
  • Embrace feedback and learning
  • Rally the organization around single priorities
  • Get customers excited

You prove to be valuable in every way. You lay down the path to collaboration, alignment and sometimes even consensus. Let us continue this way and evolve our product the best way we can.

(c) This blog is based on the “Product Roadmapping” workshop held at Mind The Product Londen 2017, led by Bruce McCarthy and C Todd Lombardo, authors of “Product Roadmaps Relaunched” – productroadmapping.com