How to transition to a public product roadmap

In this thought leadership article, I’m speaking with Director of Product Management, Rikke Knutzen, about the transition from a private to a public roadmap, and how to work with outcomes rather than feature deadlines. This article only scratches the surface of the wealth of practical knowledge Rikke has on these topics, but nevertheless, it’s full of great advice and perspective.

Let’s jump straight into it. A lot of companies like the idea of having a public roadmap, but the product leaders often mention they are hesitant to do so for competitive reasons. What are your thoughts on that concern?

“One of the main concerns I hear from product leaders is that they are afraid of competitors copying them. My perspective is that you can either spend your time defending yourself from competitors or to get ahead of them. It all comes down to how you execute with features that can solve problems, not the ten lines you use to describe them on your public roadmap. That’s your differentiator. I would rather spend our time making sure we have great alignment with customers and execute well than defending that no one knows what we do and sort of keeping those defenses up.”

Rikke goes on to add:

“In a way, our product roadmap is our execution of our strategy in terms of how the product delivers on the strategy. And our purpose is to eliminate downtime, to build the most useful industry for the world. And if we don’t have that in transparent format, then how are customers and partners going to be part of the movement to eliminate downside? It’s our core principle around collaboration and transforming the ecosystem. We simply have to be transparent, otherwise that’s never going to happen.”

How does the public roadmap impact internal teams like, for example, customer success?

“We make sure to show customer success the benefit of not having to relay roadmap information. Instead of spending time on communicating features on the roadmap, they can spend their time getting customers to adopt existing features. The roadmap is right there in public. They don’t have an outdated PowerPoint presentation. Customers can just read it themselves and comment to learn more about upcoming features from the product teams.”

Speaking of the product teams. How do you make sure new product managers who aren’t familiar with public roadmap work correctly with it?

“We heard very few concerns from product managers we hired over the last few years since we adopted a public roadmap. But we do have a governance model around it. If something is 6 months or less from launch, you can just go ahead and launch roadmap items on our roadmap as a product team. If it’s more than 6 months out, then you get some sparring to make sure we don’t put anything out there that we don’t want to display broadly, such as new things that can be perceived as cannibalizing existing products, or that we might put back on the shelf again etc.”

According to Rikke, it’s about creating an empowering culture, where people are not afraid of being transparent about what they are working on and making changes to it in public:

“If we did not have a public roadmap, then it would be hard to change anything quickly. Now, if a colleague decides they made a mistake or want to make a change, they can just change it quickly and it’s updated. We had a colleague who posted something the other day. I actually did not believe it belonged there. We had a few talks, no harm done. Then he decided to take it down. But if he hadn’t posted it and asked for permission first, then we would stall the process of creating transparency and utility.”

I noticed that you also generally don’t work with deadlines on your public roadmap. What are your thoughts on putting deadlines on things?

“I think deadlines will never go away. We still make high integrity commitments to large customers. I don’t think empowered product teams shouldn’t do any customer commitments at all. At least, I never saw that in the real world.”

Rikke goes on to add:

“When the team knows the customer’s problems and the value that they want to drive, they are the right ones to make those detailed priorities. We don’t want to put dates in our public roadmap. I think a lot of the product managers are relieved that they shouldn’t keep deadlines, but they have also realized that they are now more accountable than when you just have a deadline. Now they are actually accountable for solving the problems they believed in. You can’t just say that you were given this scope and time and had to execute on it. So with that great freedom comes responsibility.”

I think many product managers who aren’t used to working this way might be a bit anxious about what happens if they don’t deliver on outcomes. How do you make your product managers comfortable with the risk involved in having the responsibility of driving outcomes rather than outputs?

“We have a few frameworks we use and talk a lot about the importance of working hypothesis-based. It’s okay to say that “I don’t know” or “I’m not sure this is working right now”. When we onboard new product managers who come from a culture with deadlines, then you have to go through a process with them where they change the language they use. They need to learn how to say this is what I believe in based on these insights, and this is what I am unsure about. So getting comfortable with talking about risk and what you are unsure about because you never know until you launch.”

But how do you make product managers comfortable with sharing those sometimes very vulnerable thoughts?

“We have a culture of surfacing risk and sharing mistakes early, broad and loud. We as leaders role model this culture when we make mistakes. I just made a mistake last week, and found out that we had a mistake in one of our processes that prevented us from delivering something for three months. I took accountability, shared it with my team and explained how we could move forward and fix it.”

Coming back to the public roadmap again. How do you manage situations where something launches according to the roadmap and then you need to spend more time iterating on it?

“Our public roadmaps are very ideal descriptions of the value we want to deliver. We don’t have click-through prototypes, so if we need to spend more time iterating, then we talk more into the problem we want to solve rather than the solution itself. So rather than showcasing a detailed feature set, we stick to describing the problem we want to solve instead, and that gives us the flexibility to iterate if we don’t hit the mark on the first try.”

Now, we talked a lot about the public roadmap and deadlines so far. If we take a step back, what would be your general advice to companies considering changing to a public roadmap?

“You have to strategically consider what version of a public roadmap you feel safe enough with that is then good enough to try. You can always add more to it and take more risks later on. You can even start with just launching very high-level descriptions. So choose the level of depth that you feel comfortable with as a product leader.”

Rikke goes on to add how they started themselves:

“You have to find the courage to start somewhere. When we launched our public roadmap it first had a private link that our CS colleagues could share to customers. That was our first attempt that felt safe enough back then. And just earlier last year, my marketing team reached out to ask if we could put our roadmap on our website? And I was like, oh, I’m not sure I’m comfortable with that. And they challenged me and asked why not, Rikke? Now we are at the stage where we can be more courageous. The thing is, you have to build your courage and add transparency as you get more courageous as a company.”

And there is one more important piece of advice from Rikke if you want to do public roadmaps. She recommends not having pseudo roadmaps. I asked her to elaborate on what she meant:

“So we have different types of transparent roadmaps. One is directly to customers, which is the one with high-level descriptions. The other one is more internal for colleagues to get a sense of when these features are coming out. We tell customer success  that if they share the internal one, then they are on the hook for managing expectations as we know deadlines always shift around. If you share the public one then it’s always updated and you can actually mitigate the risk of telling a story that later will change.”

Finally, Rikke mentions the importance of having some internal champions who really believe in having public roadmaps:

“You need to have a few colleagues who love the public roadmap so deeply because they are passionate about making sure we are as transparent as possible, even if it’s not their job, they make sure people are using it and everything is up to date. Nudging people to keep using it. Because if it’s just something that is pushed down from leadership that will never create that natural attraction to doing it. Some people will of course love it more than others, but as long as you have your internal champions it works smoothly.”

Here at the end, I would like to focus on something else that public roadmaps. And that’s one piece of advice that has always stuck with you? Something you keep coming back to and use in your day-to-day life?

“Yes, it’s hard to be curious if you are reacting to frustration or emotional discomfort. Whether it’s a customer problem or feedback from your manager or a peer, you have to remember to reflect before reacting. Be empathetic, understanding, and curious to learn more about the context instead of just reacting to it.”

Rikkes goes on to add a specific example and the importance of having a concept of what she calls 200% accountability:

“If I get feedback personally, I want to make sure I understand the specific situation and context instead of just reacting to it. But we also have an important concept called 200% accountability. It means that both the person giving the feedback and receiving the feedback are accountable for understanding and making changes needed. There is never just one side. You have to be accountable for how you give the feedback as well as receiving it.”