Your executive stakeholders have life-and-death power over your products. Most companies have the final vote about which product initiatives get the green light and budget to move forward, which products to kill, and whether a product in the final stages of development is ready for launch or needs more work. This is why communicating with executive stakeholders is an art form you need to master if you hope to be a successful product manager.
You can find plenty of guidance on this blog about dealing with your executives. For example, we’ve written posts about setting expectations for your executive stakeholders, when to share your roadmap with executives, and how to say no to a stakeholder’s request (without making yourself a new enemy).
Today, we’d like to warn you about a few things you shouldn’t say when speaking with your executive stakeholders. These apply whether you’re in a formal product roadmap meeting, a brainstorming session, or even when an exec stops you in the hallway to ask a few quick questions. The responses below are all potential landmines in any situation you find yourself in with your executives. Don’t use them.
The 7 Worst Things to Say to Executive Stakeholders
1. My gut tells me…
Yes, a product manager’s intuition can and should play an important role in guiding the product’s strategic plan. But that’s only if the gut instinct represents the sixth sense that the product manager has due to thorough research and understanding. Gut feeling has no place in replacing market research, user and buyer personas, competitive research, and investigations into industry trends.
When you tell an executive stakeholder that you want to do something because “your gut” says it’s the right move, the exec doesn’t know if that gut of yours is the right kind. Is it from the data-backed sixth sense of a true subject-matter expert or just a wild guess?
Instead, say this: “Let me show you the results of our most recent customer survey.” Or, “Here’s a recent chart showing actual usage data. This is why I’m suggesting we de-prioritize that feature.”
2. There’s no risk to this decision.
Sometimes, after you’ve requested a shift in development priorities or a change in timelines or resources, and executive stakeholder will ask you about downsides. They may want to know what the potential negative consequences of your decision are. That’s a fair question. And the truth is, every decision carries some risk.
The last thing you want to say in response to such a question is that carrying out your request will be risk-free. You won’t persuade your stakeholder of anything with this, except for the real possibility that you haven’t thought through all of the potential consequences of your plan.
Instead, do this: Conduct a benefit-versus-cost analysis of your idea or proposed change in strategy. Evaluate the risks and potential upside—and don’t forget to quantify the risk of not taking the action you’re proposing. This way, you’ll be able to answer your executive stakeholder candidly but at the same time underscore the potential benefits of your proposal.
3. I can guarantee you…
In reality, you can’t guarantee an executive stakeholder anything when it comes to your product. Stating that you can only signal to your stakeholder that you aren’t experienced enough to know that. That’s the precise opposite of the impression you are trying to convey here.
Instead, say this: “This is what the data are suggesting.” Or, “Here’s what our development team’s prior performance indicates.” Or even, “Based on how our market has responded to previous new-product launches, here’s the best estimate I can give you now.”
4. I think this will be cool.
Cool features can work wonders for a product’s performance in the market. As we’ve argued here before, customer delight is a must-have on your product roadmap. But that awe-inspiring idea you have for new functionality, product design, or other customer-delight elements must be backed by evidence—not just by the fact that you think it’d be cool.
Instead, say this: “Here are a few data points indicating our target persona would react extremely positively to this.” Or, “We’ve performed a weighted-scoring analysis of this customer-delight element against other priority items, and the analysis suggests this is worth prioritizing.”
5. We can’t get outstanding data on that.
Sometimes you truly can’t obtain the real-world data you’re after. For example, maybe you’re developing a product that’s so innovative it has no real comparable on the market you can study. On the other hand, maybe you don’t have enough customers or even prospects to conduct a meaningful survey.
Whatever your drawbacks, you need to get creative and find ways to quantify the opportunities and threats to your product’s plan. If only so, you’re ready for an executive stakeholder asking you for that data.
Instead, do this: Find some way of building a data-supported case for your proposal. Maybe you can find a proxy product or service on the market (even if it’s in a different industry) that can serve as a comparable for the research you need.
6. We’ll have it done by October 1.
You will have a strategic reason to commit a product launch or release to a specific date in rare cases. For example, perhaps you want your product’s unveiling to coincide with the first day of your industry’s big annual trade show or convention. But in most cases, there is little strategic value—and many risks—in promising that you’ll have a product ready by a specific day.
If a stakeholder asks when you expect to have an initiative completed, that person is often just looking for a general idea, not a precise date and time. So there’s no reason to create this artificial due date for your team, especially if you could easily miss it due to several factors outside your control.
Instead, do this: Give your stakeholder a roughly estimated time frame (maybe a month). You can even support your estimate by walking the stakeholder through your team’s previous performance on similar projects. This way, if the dates slip for some reason outside your control, you can remind your stakeholder that your initial estimate was based on prior work that didn’t include those unforeseen delays.
(If you’d like more guidance on this topic, see our post on when and if you need product roadmap timelines.)
7. It wasn’t our fault.
We’ve saved the worst for last.
In a post-mortem discussion about a product launch or other initiative that went sideways, your executive stakeholders are going to want to know what went wrong. The last thing they’ll want to hear is your team deflecting blame. It doesn’t serve anyone’s purposes, and it only undermines your executives’ opinion of you as the product leader they’re counting on you to be.
Besides, as they say in politics, the cover-up is always worse than the crime.
Instead, do this: Own up to the problem. Even if the errors weren’t entirely your fault (or your fault at all), tell your stakeholders that the product team is ultimately responsible for the product’s successes AND failures in the market. So no matter what happened, take ownership of the bad outcome. Then have a succinct explanation of your data-supported plan to make things right.