The Collaborative Development of a Roadmap

Problem

"I have been a CTO, CPO for 15 plus years now. If you ignore the T or the P, I've always run product, design, and engineer. The three legs of the stool. It was maybe 10 years ago that I made a shift in how I developed and communicated the roadmap to my team. In the past, I would put together a product strategy, decompose that down into a product roadmap, and then go out and start communicating it to the team. I tend to use a different, more collaborative strategy now for the development and implementation of a roadmap."

Actions taken

"I have a constant dialogue with the heads of different departments. There is an ongoing conversation where I am consistently working with the heads of the departments to gain knowledge on what is working, what's not working, and what their needs are. The social object in these conversations is the data brought up between me, the department, and the existing roadmap. While I'm having those dialogues, I am also constantly having a conversation with the board and our CEO about the company's vision. What is the big picture? How are we decomposing that picture into the broadest strokes? And what is the sequencing of those strokes? You see, there is not simply one big single conversation happening, but a lot of foundational conversations. It is the building of strong relationships with each department head, executive, and stakeholder that develops itself into a prospective roadmap.

Once I have a collected an extensive volume of information from these parties and can formulate a narrative, it is then my duty to make sure that all of that information comes together and that the teams join together on an agreed upon hypothesis. At this point in time we have created an internal roadmap. To be clear, though, I roadmap problems and opportunities, and then the expected outcome by addressing or capitalizing on that opportunity. I do not roadmap features. Of course, every company does this differently and there is no right or wrong way, but this strategically works best for me. This ensures that we are all rooted in the core problem that needs to be solved and we understand the core opportunity that we are trying to capitalize on.

We then conduct off-sites with all of the above mentioned parties. But, before I even walk into that room everyone there has already seen the roadmaps that I am going to propose. During those constant conversations I am having with each of the department heads and executives, my team is putting together a roadmap that I can float by them to get everyone's feedback on. That way, when I walk into the off-site I know where people are aligned, and where and what are their objections. This is a time to collaboratively walk through the big problems, the outcomes that we believe we can achieve if we solve them, and the reasoning behind solving them in a specific order. More so, we talk about them in terms of the vision. The roadmap is backed by the vision with interspersed conversation on the strategy.

Initially during the off-site, however, the word roadmap has not even been mentioned. It is obligatory that we are first aligned on these things before I show the roadmap. Once that has taken place then I will present and we will walk through the different roadmaps. All of the roadmaps are focused on problems that have been discussed prior to the meeting and address why they are a good fit. Note, though, at this point we're just debating problems. We're not getting caught up in how to actually solve them. I direct the conversation to a more productive and collaborative means instead of having a debate about different executions."

Lessons learned

• "I believe as head of product your job is to get the right answer, the right outcome, the right roadmap. This does not mean it has to be a specific roadmap that you thought of or put together. It takes deep collaboration to get the best roadmap in place."
• "Make sure everyone is aligned on the foundational aspects of what should be driving your roadmap before you even show others the roadmap. I have found that if the foundations are not there in advance then objections arise and present themselves in the context of debating a feature. It becomes a convoluted conversation opposed to a beneficial discussion around that roadmap."
• "Avoid being blindsided by having constant conversations and feedback about potential roadmaps. I don't ever want to blind-side those attending an off-site nor do I want to blind-side my team. And of course, I don't want to be blindsided and have to respond to things on the fly and without a pocket full of information."
• "I can actually completely orchestrate and control, to the best of my ability, the dialogue of a roadmap meeting by arming myself with useful information and feedback prior to the presentation of a roadmap. I can facilitate a collaborative team conversation about each thing in the particular roadmap because I know what people said before. What they liked and didn't like about the roadmap."