How I say 'no' to feature requests
It’s not fun saying ‘no’.
A ‘no’ from a product manager can be devastating to a sales rep or a customer service manager. This one feature request could mean a fatter commission check. This one enhancement could mean fewer tickets.
Yet saying no is part of the PM job.
One of the PM’s most important responsibilities is to keep everyone focused on the strategy and the goal(s). That is impossible if every single request makes it to the roadmap.
So, saying no one musts.
But we can’t just say ‘no’. It’s important to provide context, particularly if this ‘no’ will crush a colleague’s dreams.
Below is a framework I've put together when I need to say no. It is versatile enough that it should help say no to anyone, from sales reps to heads of departments.
Note: As I was reworking my draft of this post, Lenny published an excellent newsletter on saying no, too. Thankfully, Lenny’s post focuses on the personal 'no' rather than the product 'no', so I'm clear of plagiarism. Phew. Make sure you check it out: On saying no.
Authenticity
Before we go through the framework itself, I feel it important to state the obvious: ‘no’ must come from an authentic place.
Whatever the reason for saying no (more on that later), it must be genuine. To that effect, I make sure I research every request, speak to third-parties, involve relevant team members, and more.
As a rule of thumb, I never answer ‘no’ to a request on the spot. I’ll always consider any request. That, too, is part of the job. If someone thought a request was worth bringing up, it means there’s something in there worth exploring.
Now that’s clear, here are the five dimensions I’ll use to say no to a feature request.
Dimension 1: The strategic 'no'
This could equally be both the easiest and the hardest no.
It's easy because it's an extremely logical no. If the company is going in a specific direction, the product needs to support that with a specific strategy. If a feature doesn’t help us get there, it’s clear we’re not going to do it.
It's also hard because it assumes the product (or business) has a clear strategy; which isn't always the case. If the product strategy is lacking, if it is murky, if it is not communicated properly, this dimension is almost completely moot.
Most nos should be strategic nos.
Dimension 2: The resources 'no'
This is simple: it’s a good idea, but we don’t have the resources for this.
It’s helpful to back a resources no with hard facts such as ROI, potential TAM, and resources breakdown. Even a simple roadmap might suffice.
Dimension 3: The technical 'no'
Sometimes, the request itself just won't make sense. It’ll be too technically challenging, impossible to implement in our current tech stack, require hiring a new team, and so on.
Technical nos may also overspill into legal or regulation requirements. Again, for those, I like to back my no up with specific requirements we need to meet (or can’t break) such as ISO27001 accreditation.
Dimension 4: The competitive 'no'
This is a tricky one.
Technically, saying 'no' to a feature just because competitors have/don't have it isn't a good idea. We’re not our competitors (and competition is for losers anyway).
However, sometimes, looking at competitors may provide some insights yet. If a feature that seems ‘obvious’ and ‘easy’ (famous last words) isn’t available to any of our competitors, what does that tell us?
Dimension 5: The usability 'no'
It is common for feature requests to be extremely short-sighted. A sales person may request feature X because it’ll offer Y revenue, for example.
But we all know it isn’t that easy.
A new feature may add a layer of complexity to the product. It may make using the product more complex for the end user. It may make deployments slower. It may introduce a new monitoring requirement to a team that’s already stacked with work.
Guarding the product from these ‘little feature’ requests creeping into the product is important. Even if it seems insignificant to others, we (PMs, product, dev) know their sneaky long term impact.
Great read! Important to keep in mind none of these Nos are permanent (except in rare cases) most are just “not the right time, right place, not us”. We might do it later or a flavor of it later at some point.
Great post Alex. I work in an org where 75% of the "no's" are of the strategic flavor where the historical way to these from product are - because everyone including the requestors have access to it - buried into the backlog all the way at the bottom. I guess that makes them more of a "yes! in 2035."