Changing the Way Product Managers Speak to Stakeholders

Changing the way we talk to stakeholders and executives can make a world of difference, both for them and for us as product managers. We can’t expect them to simply understand the way we work, we need to bring them into the product process and open the door to our world. With this comes teaching them our lingo, and rearranging their view on what product is and how it works.

Below are a few terms to kick-start and change the way we frame things to others:

Feature Roadmap = Product Roadmap 

When will it be done? Do you have a timeline for this?

Due dates and timelines should never be promised – as product people we all know this. And yet, it seems to be the one question we always get. 

The first step to changing this conversation is to make sure everyone has access to the product roadmap. Hiding it as a Hootsuite dashboard is a huge mistake.

Reframe the conversation from “time” to “strategy.” At first it may seem daunting and that no one will accept this, but it’s actually pretty simple. 

Think about it this way:

Imagine that you’re going on a road trip, and you tell someone you will get from point A to point B in three days with no further context. They will expect you to fulfil what you’ve said.

Now imagine you prepare them for possible changes, and give them the whole context of the road trip, such as pit-stops and side roads. Your road trip buddy will now be more forgiving with time changes.

It’s the same with presenting a product roadmap without timelines. You’re presenting the whole strategy, not just the time constraints you’ve boxed yourself into. Once you remove the tunnel vision and explain the entirety of what is happening, better conversations will be had. 

Second, make sure no one refers to it as a ‘feature roadmap’, and start calling it what it is. It’s a roadmap for your product. It is not a timeline, it is not a gantt chart, it is not a list of features. A product roadmap is a document that allow product managers to explain what they’re working on and why. 

If you need a little help on building a product roadmap everyone understands, start here.

Outcomes > Outputs

A product roadmap focuses on outcomes – what, why, for whom. What are the goals that your product team are aiming for? What problems are the product managers trying to solve?

Outputs come after you have gone through the product validation process – after the idea has been reviewed, validated and spec’d out. That’s when you pass this on to development and focus on the output. 

And this is where the release plan comes into play. This is an entirely different document that focuses on how fast something will get done, after you have defined what the possible outcome is. Also, be sure you’re not referring to your release plan as a release roadmap or a technology roadmap. A product roadmap and a release plan are two documents that support each other in the whole product development cycle, but they’re not the same document, and terms should be kept clear.

Feature Backlog = Opportunity Backlog

A feature encompasses an area of your product. It simply states that your product does something, but doesn’t focus on what the benefit is. So let’s change the conversation around that first.

Once your entire team understands the benefits your product gives your customers, you can start talking about opportunities or ways you can improve those benefits. These opportunities, or ideas as we call them in ProdPad, make up your opportunity backlog.

What problems can you solve? What value would these provide if solved?

Once your team starts talking about problems to be solved in the opportunity backlog, it becomes less about ripping off the competition, and more about how you can provide value to customers. At the end of the day, you’re not building a product to compete with others, but to provide value to your target market.

Feature Request = Customer Feedback

A request implies something will be done. Will you do every single item that comes through? If you did, you’d just be a feature factory!

Change the language to customer feedback. This implies that it is coming in as an observation from your customer, rather than a request you must fulfil. Product managers shouldn’t focus on feedback being positive or negative, but rather as input for areas you can improve in your product. 

This will also give you a leg up on how your team responds and handles the feedback that comes in. If your team isn’t currently focusing on something that’s requested, they can share your product roadmap (wink wink) to talk about current priorities, and how these will benefit (wink wink) the customer. Thank the customer for their feedback, link it to your opportunity backlog, and as time goes by, understand the impact of that feedback for the problems you aim to solve. Do I have to wink again? I’m sure you guys get it by now.