Saying No is Hard. Here’s How To as a Product Manager.

Product Management is not really about deciding anything…it’s about providing enough evidence and promoting the right discussions in order to discover a solution that works for both the business, the customer, and the market direction. A lot of this is easier said than done.

Half of the troubles of this life can be traced to saying yes too quickly and not saying no soon enough.

-Josh Billings

The hiccup comes when the solution doesn’t make sense, and does not fit the overall direction of the business, the customer, or the market direction, and that’s where you really have to flex your PM muscles in order to ensure that your customers are successful, but also the long-term strategy of your business is successful as well.

With three basic guidelines, I’m going to lay out a foundation for saying No, and how you can use these in your everyday work as a PM or in any role.

Determine when to say No

Saying No is hard, but when you have a solid framework in place, it makes the process smoother and provides you with a threshold and framework of determining when a ‘No’ is warranted.

“The oldest, shortest words — ‘yes’ and ‘no’ — are those which require the most thought.”

-Pythagoras

There is no magical formula of when to say No, but make sure it makes sense to you, the business, and your business and development influencers. A simple framework that I suggest is based on five true or false questions, and if at least two are false, then it’s an automatic ‘No’ or a ‘No, but if…’

1. Does this request belong in this product?
2. Does this request impact the key results we’re trying to accomplish?
3. Does this request impact multiple customers?
4. Does this request make sense given the market growth areas?
5. Do we have the right team in place to support it?

Help them understand what No means

Most people think of ‘No’ as an absolute blocker or a brick wall on their passage to delivering something that is going to enable them in their role or help solve a customer’s paint point. Remembering that with decisions, there is always a personal attribute to a request whether it’s coming from sales, marketing, or the c-suite, and the care we take to helping requestees understand the decision made will be all worth it.

This is by no means the best or only way to align a whole slew of people, but I’ve found it to work best for the many situations I’ve been in.

Before you say no, paraphrase what the individual or team is requesting and ensure you have an understanding of what it is.

Next approach with the situation that the business and product is in and what that means for where your team is choosing to focus.

Finally, explain how the item either contributes or does not contribute to this vision and if it has a spot on the roadmap for the next 6 months or longer.

If the item ends up having a home in the ‘Future’ bucket for your team, explain why it’s there instead of ‘Now’ or ‘Next’. If it does not warrant a slot on your roadmap, establish when it may depending on the business and product dynamics or criteria.

Back up your No

Sometimes saying No is not enough even with explaining things that evoke emotion and thought, and you need to provide that extra oomph. This extra oomph comes in many different forms.

You may want to document your approach to how you determined that you would not do or work on the item requested, with your framework and evidence gathered based on user interviews or market research. You may also have to gather metrics and data regarding the outcome that would be delivered and the current state of a product it’ll impact;

Example

A director approaches you with a request that is suppose to positively impact the adoption rate of 3 different customer segments that use products within the business. You vet the request, and determine that it impacts your product, and determine that the team will spend 3 months building out this feature.

During your research however, you find that 2 of the customer segments are at the end of the adoption maturity curve. With this finding, you decide it’s not worth it for your team to spend 3 months building out the feature and for the team to focus on other initiatives or requests.

To back up this No, you could present findings on the 2 customer segments that are in decline, and also some 3rd party findings on those customer segments to help. What data or 3rd party research you leverage is completely up to you, so long as it makes sense to the requesting party or parties.

At the end of the day, nobody wants to hear ‘No, we won’t work on it’, but if you follow the three guidelines above, saying No will be much easier on the sending side, and the receiving side of the process.