Your executive stakeholders have life-and-death power over your products. In most companies, they 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. Which 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. We’ve written posts about how to set 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 just 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 a sixth sense that the product manager has as a result of 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, an executive stakeholder will ask you about downsides. They may want to know what the potential negative consequences to your decision are. That’s a fair question. And the truth is, every decision carries some sort of 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 signals 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 just 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 really good data on that.

Sometimes you truly can’t obtain the real-world data you’re after. Maybe you’re developing a product that’s so innovative it has no real comparable on the market you can study. 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 some way of quantifying 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.

In rare cases, you will have a strategic reason to commit a product launch or release to a specific date. 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 a lot of risk—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 a number of factors outside your control.

Instead, do this: Give your stakeholder a rough 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 ultimately the product team is responsible for the product’s successes AND failures in the market. No matter what happened, take ownership of the bad outcome. Then have a succinct explanation of your data-supported plan to make things right.