Product management can often feel like a zero-sum game. You have finite resources to develop your product, and if someone wants you to add X to the roadmap, doing so will have to come at the expense of Y.

Effective product management often comes down to making the best choices possible with the limited resources you have. To be successful, a product manager will often have to say no — to ideas, suggestions, requests, or even urgent demands from internal stakeholders and external customers.

But this doesn’t mean that you have to be confrontational or adversarial as a product manager with the many interested parties who will come to you with requests that you don’t have the resources to fulfill. (And for those of you who are new to product management, trust me, you’ll be fielding these requests often.)

In fact, if you learn a few techniques for turning down these requests effectively, you might even find that your audiences completely understand and even support your decision.

Six Tips Product Managers Can Use to Say No — Without Making Enemies

1. Spend Time Acknowledging and Discussing Your Stakeholder’s Request

In customer service training at virtually all of the world’s most successful companies, new reps are taught to listen attentively to a customer’s request or complaint and then speak with the customer in a way that demonstrates the rep understands and empathizes with them their issue. The reasoning is simple: People want to be heard.

When an internal stakeholder or a customer comes to you with a request to add a feature — a request you can’t support, at least not right away — how you frame the conversation can be just as important as the answer itself.

You wouldn’t want to say something like, “That doesn’t sound like a priority for this product” or, “We don’t have that on the roadmap.” Why? Two reasons.

Frame your conversation

First, when you jump to rejection without giving legitimacy to your stakeholder’s request, you deprive that person of feeling heard.

Instead, you want to spend time acknowledging the request, explaining to the person that you understand why they would want or need it, and showing empathy for their situation.

You might say, for example, “That’s a strong idea for a new feature, one we’ve actually considered [or that we currently weigh] as a possible addition to the product.” However, only after you’ve acknowledged and demonstrated an understanding of the request can you explain why it’s not something you can support for the time being.

A second reason you wouldn’t want to answer a feature request with a context-free rejection — “That isn’t a priority for us” — is that without giving your reasoning, you leave your stakeholder feeling as though your “no” was arbitrary. Having a request turned down can be disappointing, but having it turned down without reason feels far worse.

This brings me to the next tip: When you have to turn someone down, demonstrate that you know your stuff and have good reasons for doing so.

2. Know Your Stuff — So You Have Sound Reasoning Ready

This is a broader tip, a suggestion to spend as much time as necessary to become an unrivaled expert in all details relating to your product. This includes a deep understanding of your market, your company’s internal resources and capabilities, the competitive landscape, and any other factors that would affect your decision to include (or not include) a new feature or other request relating to your product.

If you know these details inside out, then when it comes time to turn down a request, you’ll be much better equipped to provide your requestor with good, sound reasoning.

You can think of this as the second part in a two-part strategy that begins with tip number one. When someone comes to you with a request for your product, and you have to turn down the request, you’ll first want to spend time discussing it with your requestor. Show that you understand her needs and appreciate her for offering up the suggestion. Then, when you explain why you cannot accommodate the request, you can provide the larger context — which might include issues like competing projects or preserving your product’s simplicity and usability — that your requestor likely didn’t consider.

An example of a request you can’t accommodate

A common example of a request you won’t be able to accommodate conflicts (or at least does not align) with your company’s larger strategic objectives. For example, your company’s primary aim for the next year might be to increase users’ number for your software product. With that organizational directive in mind, you might have prioritized initiatives like streamlining the sign-up process and creating a scaled-down free-trial version of your product.

Now, when an executive or other internal stakeholder asks you for a request that doesn’t support the primary company objective — for example, if they ask for an overhaul to a major epic in the product that only your power users would benefit from — you can explain to them why you can’t add that epic to the roadmap, at least not right away. Instead, you need to focus all available resources on meeting the company’s main strategic objectives of bringing in new users.

Knowing your stuff also means having relevant data — user feedback, usage reports, competitive information, sales details — always at the ready to explain why a stakeholder’s request might not be as urgent or impactful as they might think. For example, let’s say an executive asks you to prioritize a bug fix he found in a feature deep in the application. If you’re able to show this stakeholder that fewer than 1% of your user base ever access that feature, that data and reasoning will go a long way to explaining why the fix can wait.

When you apply this technique correctly, you’ll first demonstrate to your stakeholder that you’ve heard his request and see its value. This will then provide a nice transition to your explanation that you are also operating in a larger context, weighing all requests, even valid ones like his, in light of this bigger picture.

Although being turned down can be disappointing, being provided a clear, logical reason can soften the blow.

3. Wherever Possible, Show the Requestor That It’s Not “No Forever,” Just for Now

Let’s say you have to turn down a request from the sales or marketing team that is, indeed, valid. Or one that you hadn’t encountered before and which might be worthy of inclusion in your product but first needs vetting. Your answer might not be “no” at all — but instead, “not right now.”

Here’s where an “idea parking lot” can prove invaluable — not only because it’s a place to keep ideas that might prove useful down the road, but also because it’s a great way to show your stakeholders that you are not rejecting their requests—just parking them for review later.

At ProductPlan, for example, our Table Layout helps PMs in the prioritization stage by allowing those features or requests that don’t meet their criteria for inclusion on the roadmap to be captured for later consideration.

A second idea for showing stakeholders that you plan to evaluate their requests and that you’re not merely rejecting them is by placing these requests in a community forum, ideally, one that is accessible to both your internal teams as well as external customers and even prospects, where any interested party can vote or comment on new ideas.

Bonus idea:

If you aren’t already operating such an open forum, create one. It could be a community Slack channel, a blog on your company’s website, or built on a third-party platform like the excellent one from UserVoice. The idea is, you’ll be encouraging your user base to contribute their ideas for your products — and then allowing other users to give their feedback on these ideas. Who knows? You might discover features or ideas for your product that you’d never considered, that your competitors haven’t thought of and that your customers are telling you they want.

Placing a product request that you can’t immediately fulfill into an idea parking lot or onto an open forum where others can vet it for you is another way to show everyone with a stake in your product that you’re taking their requests seriously.

Tools such as forums, chat rooms, and idea parking lots are useful in their own rights. Still, they can also be precious in helping product managers protect the integrity of their roadmaps and products — by giving product managers a place to put unproven or lower-priority feature ideas besides the product itself.

4. Be Transparent About How You Prioritize

One of the best ways to say no, particularly to an internal stakeholder like an executive or a sales director, is to lift the veil on your product roadmap and walk your colleague through your methodology for prioritizing epics, themes and features coming releases.

If you can clearly demonstrate through a presentation of your roadmap that the next sprint or longer-term development cycle is focused on X. With solid reasoning behind that decision, then your stakeholder should find it more logical that you cannot accommodate her request to include Y.

This is where a visual product roadmap application can be so helpful. With the Prioritization Board tool built into ProductPlan’s roadmap software, for example, before you begin building out your roadmap, you can create a list of initiatives and work with stakeholders to score their priority levels according to factors you determine. Then, when your strategic discussions and scoring are complete, you will have a logical, supported list of priorities for your roadmap.

By using a tool such as the Planning Board in your product strategy’s early stages, you’ll have the ability, at any stage of your product’s development, to show the reasoning behind your prioritization decisions — complete with numbered scores — to a stakeholder who wants something included on the roadmap that’s off-topic and therefore cannot make the cut.

This can both help demonstrate to your colleague that you are being fully transparent and put your “no” into the context of the larger product-development picture.

5. Try Not to Say “I” When You Say No

Yes, as the product manager, you’re the person a stakeholder will come to with an idea or request for your product. But no, that doesn’t mean you’re making a personal decision when you turn down that request. In fact, if you’re spearheading your product’s development intelligently, the decisions you make will be based not on your personal feelings but rather on your expert understanding of your product, customer, and market.

One powerful way to underscore this fact and give your internal and external stakeholders a better understanding of why you need to say no is not to refer to yourself in the conversation.

Instead of saying things like, “I don’t think we should focus on that epic now,” you can refer to the data: “Our research has told us that….” You can also refer to the agreed-upon strategy: “The stakeholders have decided they want the next release to emphasize….” Or you can refer to the roadmap policy you’ve established: “For tough calls like this one, we’ve established a set of guidelines….”

In the end, the decision to grant a request for your product or to turn it down is not about you. The decision will be based on what’s best for the product and support your company’s strategic objectives. When you have to say no, the more you can keep the conversation focused at this strategic level and not on yourself or your thoughts or ideas, the more likely it that your requestor will leave that conversation understanding your position — even if they are disappointed.

6. Try Not to Say “No” When You Say No

Who says you have to say no at all? You now have several legitimate answers — other than no — to a product request that you can’t fulfill right away. You can place such requests into an idea parking lot, where you can revisit them at a later time. You can also place them into an open forum, where you can publish an idea and allow qualified sources (your customers) to help determine its merit.

Which means you don’t actually have to say no.

Say someone comes to you for a feature add, and you know immediately that you can’t include it on the roadmap for some time. Your answer can go something like this:

“Thanks for the idea. We really appreciate hearing from our users. Requests like these let us know that you’re using and getting value from our app. Unfortunately, our product roadmap and development schedule are pretty well locked in place for the immediate future… but let me put that idea out to our community [or let me place that into our idea parking lot, or let me revisit that as soon as we complete our next release and our dev cycle loosens up a bit].”

You haven’t committed to anything. But you haven’t said no, or anything close to it. So your customer feels heard and appreciated, that their idea has merit, and that you have a legitimate reason for not being able to execute it right away.

This customer might walk away from a little disappointed. But because you used these techniques and showed you heard and understood their request, they’re much less likely also to walk away angry.