I bet you were in situations of regretting not saying something. Sometimes in those where you should have said tough “No!” Every so often, as a Product Manager or whatever product-related position you take. Say “No!” to your boss, a big customer, a teammate regarding a new fancy feature. It’s always much easier to say “Yes!”. That’s when the feature prostitution starts and priorities blur as oil patches on the water surface. And being prepared means having some rules when to refuse.
I hope you already have at least some vague beliefs of what works for your product because, as we know, prioritization needs it. And prioritizations is the key here. Make it clear for yourself and your team which metrics or beliefs are most important. For example, ARR Increase > Activation Metrics > Delightfulness. Go through this simple rule anytime a big customer comes to you with an idea of how your product should work and, in case if it’s not going to work so in a month, they are going to leave you with a competitor. In our scenario, if this company is not going to increase our ARR, we say “No!” to prioritize other our ideas higher (fortunately, we always have like 28 of “knowing” how to spur the revenue).
Another great way is to find a compromise. Think about it as partially “No!” Cheaper, faster implementation. A resemblance of what is needed. Hone your negotiation skills to perform better in finding solutions fitted for every side.
The truth is that you can’t please everybody, no matter how many resources you have. And rule #1 for when to say “No!” is to set right and comprehensive expectations for all sides. Thinking of everybody should be aligned with the product strategy and priorities. Priorities, in turn, are the alignment of inputs (efforts, resources) and outputs (values, gains). Be clear and straightforward about them—you are not allowed to dodge and mumble.
As was mentioned above, people are more inclined to say “Yes!” It’s psychology. You can develop similar rules for that, but let’s be honest, there are always rules in our heads to say “Yes!” Some of them are flimsy. Some are hard to disagree with. We come up with them on the fly. And what is written here is just a way to protect our right for “No!” in the product development process.