How do you say no to feature ideas or requests?

Clarify:
1. by say no I assume you mean 'cannot be prioritized at this time'?

Goal: to have a clear process to communicate at the time of a feature request and a clear consistent criteria for prioritization that can be shared for transparency.

There will be multiple layers of priorities impacting any given product or feature. The broad buckets with primary contributing input are:

Business (requestor) priority
1. P&L
2. business case - balance cost and benefit
Global (organizational) priority
1. total revenue
2. Strategy ie balance global goals in the business model
3. cultural
Product priority (deep user empathy)
1. user stories
2. user impact
3. product strategy - acheive product goals within technical and user trade offs

In general
a product strategy serves a function for the business stakeholders while setting global strategic objectives.
So a product will prioritize high impact efforts across it's stakeholder businesses in alignment with it's product goal while ensuring that it is in sync with meeting key global criteria.
One way of doing this is 
1. Ensure your product strategy is aligned with the global strategy ie. if org wants to hit X interactions touched by GenAI this year your user stories and impact should reflect this
2. product priority: keep a running backlog with top 3, top 5 and top 10 features (assessed in terms of customer impact vs effort)
3. assess this list in terms of widest number of businesses impacted to see if it changes the ordering
a if it does not, no action
b if it does there may be more alignment needed on business casing for underserved businesses 

At this point a new feature request can be responded to with a clear articulation of process:
'we will assess your feature against the product strategy which has incorporated global objectives and respond with your ranking in top 3, 5, 10 or other along with potentially additional business casing actions you may take to precipitate a better ranking'

It's very important skill for a product manager to say no. And saying no in such a way which makes sense for the stakeholders requires a whole lot than skill.
Below I have mentioned the situations where a product manager has to say no and how they can convey 

Alignment problem

The feature does not align with the product's strategic direction or business objectives.

Core problem not addressed

The feature focuses on surface-level issues rather than solving the underlying problem.

Effort vs. Impact concern

The feature's potential impact does not justify the resources and effort required to implement it.

Resource constraints

Current team capacity is allocated to higher-priority projects that promise greater impact.

Technical feasibility issues

The feature is not technically viable within the current system or would require disproportionate resources to implement.

Risk to user experience

The feature could disrupt or degrade the experience of core users, leading to potential dissatisfaction.

What I have observed is that most of the time, most of the requests do not necessarily align to the current objectives of the organisation as a whole. This comes from the fact that each individual department have their own goals to achieve. While in properly aligned organisations, all departments will coherently work towards a common direction of a north star metric, even though their immediate objectives may be different, but what rather happens most of the places is (and I'm only narrating this from experience) that teams push for macro-objectives to simplify their workflows or problems statements that have little to no major impact on your key metrics. 

I generally go about asking a few clarification questions on the requirements:

1. Who will benefit from this feature request? (this is to identify the target users, and how many of them will be benefited)

2. How will you measure the benefit? (to bring about clarity on the success metrics at its core)

3. Which key metrics would this request move? (more of a question to myself) 

4. How urgent is this requirement? Is it impacting an entire workflow, causing blockers, or if it is more of an enhancement on an already working flow?

5. What are you losing out on if this feature is not there? 

Based on the answers I would receive above, I would do a quick mapping of the request to the priority, urgency, impact and effort and run that with my own interpretation of the data (whatever they present, and whatever I have internally).

This process helps me to ensure I do not request or approve any feature request without running it through multiple angles so that my inherent bias is minimized. Data eliminiates ambiguity. 

I would love to hear a feedback on this approach of mine. The loopholes in this, what can be done better. 

     Saying no is a big part of product management. But how can we be certain it's a no? A valuable YES can be found among thousands of NOs. How are we going to filter out all the noise? And how can we keep folks who suggest features from becoming irritated when their suggestions are ignored?

    Whenever a request comes in, we should ask three questions:

     What problem is this request trying to solve?

Feature requests are frequently one person's best estimate at the best answer to an unstated problem. Many troubles are only indications of greater issues. We need to go deeper to find the root of the problem. We begin with the request and then question "Why?" not once, but several times in order to peel back the layers until we find the fundamental problem.

 Once the true problem has been identified, the goal should be to solve it.

 ❌ If we learn that the problem isn't important enough to fix or that a decent solution already exists, we'll come to a halt. It is not worthwhile to proceed with the request.

✔️ If the problem appears to be important enough, there will be more than one way to solve it, not just the output/feature suggested. But before, here are two additional questions to consider:

v Does solving that need align with our objectives?

We must determine whether we are just adding value or achieving a goal that will help our organisation achieve its Vision and Business Objectives.

We need to inquire:

• Does this fit our Vision?
• Is it a forward step along the way?
• Can we grow the business because of it?
• Will it really generate new and relevant engagement?
• Will it increase adoption?
• Is it going to be significant in 5 years? 

❌ We will end here if the desired conclusion does not withstand any of these questions.

✔️ However, if it appears to be in line with your goals, we should ask one more question:

v Is it more vital than what we have in the roadmap now?

When the request was received, we already had a plan with a list of goals. Is the request's targeted goal more significant than the other objectives we've planned to focus on in the near future?

❌ If not, we can probably come to a halt here. It's too distant in the future to consider right now. Let's be realistic: when the time comes, the context will have altered so drastically that it won't be worth retaining.

✔️ If so, we'll need to find a spot in the roadmap for it. We'll have to re-prioritize and compromise.

You have to say NO a lot as a PM.  But I want to be supportive. Luckily there are cheaper ways to support an idea than building it. Here's how.

1. I'd start by making sure I understand the feature request.  Then I'd ask how strongly they feel about it and if they're willing to work to make it a reality.  If yes, I'd ask if they'd like to sit down and figure out how it would serve the user.
2. If they say yes, then  I'd sit down and learn more about what they thought the benefit would be and how much impact it would have in terms of RICE: Reach, Impact, Confidence & Effort.
3. If they don't know all of the above, I'd ask them to get that info and get back to me. (Then GoTo #4)
4. If they know the above I'd sit down and calculate the value of that feature and compare it to some other features.  Hopefully they'd start to see it has a lower priority.

Following is the way to decline to new requirements or features etc...

Step 1: Check where is it coming from - that is who has raised and who are going to be the owners of the requirement.

Step 2: Perform Cost Benefit Analysis of the requirement on following parameters :

1. What is the cost to implement it?
2. What is the Impact?
3. Business Advantage.
4. Are their any risk with respect to current build, release or to the product
5. Is the requirement clear that is try to find gaps in the new requirement?

To answer these questions I will divide stakeholders into two groups 

1. Group 1 - Involves stakeholders who directly or indirectly are upper in the hierarchy like customers, supervisors, leadership

2. Group 2 - Involves stakeholders who are directly or indirectly are in the below or at the same level of the hierarchy like "colleagues", "juniors", "other team members"

Saying no to Group 1

The best way to say no to the stakeholders of this group of people is through Data (directly or indirectly through data ). Never say NO to this group just based on your opinion or experience. Because people in this group have authorities to override your opinion blatantly. 

Push back this group of people through Data as data does not offend anyone and overriding what data is saying is difficult and shift the onus on them if they choose to go ahead ignoring data. 

Data could be 

1. Data from the database which might show that launching this feature might have an adverse effect

2. Learning from the past experience of the organization 

3. Data from the internet or some plausible research 

4. Prove by analogy - like we tried to do something similar to this before and it does not work etc. Or XYZ company tried the same thing but failed. 

The only Caveat in saying NO to this group is that you have to do all of the above work. While for stakeholders in Group2 - instead of saying NO, you can ask them to justify their feature by doing the above things themselves. Things are sorted and no one feels like they are denied or not listened.