The power and responsibility of “No”

In my experience running startups and product management groups, I am asked often how we prioritize X feature over Y feature. Many times, this is tied to a question about stopping feature creep or partnering deeper with a strategic. Other times it might be tied to a question of hitting timelines and having believable roadmaps.

As example, I picked a picture above of ashtrays for beaches. I could imagine a discussion in a consumer product company around building commercial ashtrays for the beach. People who smoke tend to do it outside. Tend to do so at the beach. And usually can do so not to piss off the people around them except when they use the beach as the ashtray. So, building a portable, powered ashtray would make sense for the beach. I am sure a product manager has had to say “No” to building a fancy ashtray for the beach. Why? Because the customer just wants a coke can on a string. The market is just not there.

No. This is an extremely powerful word. A word I do not take lightly. Using it instantly puts people on the defensive. If it is not used correctly, in a product management context, you will lose credibility. 

The word “No” should never be used alone. There should be explanation, this is the responsibility part. No should always be followed by a question or explanation of “why not”. Usually when the word “No” is used, there tends to be a need or gap in information between the product team and the group asking. Here are some examples of how the word No can be used to fill in the gaps and more importantly search for collaboration.

• No, the 20 customers that are representative of the use case believe it works this way. What if we get a couple of them on a video conference to review our plans?
• No, we have the 3 most important pillar features ready to go, we need to ship now on time and when the company and customers expect.
• No, we have not hit our exit criteria to ship this version. We must complete the pillar feature and are willing to hold for the extra sprint.
• No, in the launch plan we all signed up to, customer success should have 65% of the team through level 1 training. Let’s hold till we hit our metrics unless there is cross functional agreement or circumstances that dictate otherwise.

In previous articles, like “What is a Product Culture anyways?”, I discuss how the product team is the hub between the business and the technical aspects of a company. With this being the case, actions need to be taken all the time to foster collaboration. 

I strongly believe that Product managers should never be the most technically knowledgeable persons in the room. They are there to mediate, collaborate, and find the right path for the features that have been requested, innovation, and technology tax. This is based on understanding when to say “No” to keep the process moving forward. 

Saying “No” is saying “no for now, not no forever”. In many companies that are customer focused, saying no is hard. You will always have more reasons to say yes than no. So what is a product manager to do?

In looking deeper into the ways to say “No”, I came across Holly Donohue’s article “A Product Manager’s Guide to Saying No” which does a good job describing some of the key points to not looking like an obstructionist when saying “No”. The two first activities she describes are 1. Actively Listen and 2. Find the Value. These are by far the most important traits of a product manager and critically important when saying “No”.

I suggest coming up with a list of questions you can ask yourself, even if the answer seems totally apparent. These questions should allow you to pull back from the trees to see the forest. Here are a few examples to help you along in the journey:

• What is the “value” to the customer?
• What “use case” is this tied to?
• Is it something we have already committed to do?
• What is the goal of the idea? Where is the proposal coming from?
• Is this something that would be monetized and saying "No" will hurt that?
• What is the impact, positive / negative, to revenue or bookings will saying “No” have?
• What is the target market and is that our target market?

These are very high level and simplistic but go to the point of actively listening and finding value that Holly talks about in her article. 

Most of the time saying “No” is put in terms of a feature being added or not. Many times, saying “No” comes up in the context of sales. Typically, there is an uneasy tension between sales and engineering. I see this with the vast majority of companies I help. They are looking for product to come in and mediate between the two. 

This is especially true when you have a successful, engineering led product company. But as companies succeed and grow, engineering’s relationship to the core use case becomes more abstract. Engineering needs to focus on the growth and efficiency of the development teams. Product has to partner here to be that trusted voice of the customer.

Same goes for the salesforce, as companies grow, sales must focus on efficiency and effectiveness of their teams. Here is one of the most typical examples. The company sales force brings in people that have strong relationships with a particular partners salesforce. The account manager wins a number of deals with the partner. The partner wants deeper integration with your platform. You engage with the partner to understand the “what will it cost” to do the integration. I also suggest asking that partner, introduce me to a customer of yours that is NOT a customer of mine for a conversation. This will tell you a lot about the market for that deeper integration. Maybe there is a route or access to market reason that outweighs the market opportunity. But you cannot say “No, we aren’t doing that now, but continue to track the market” before you know many of the answers.

Saying No should never be the first stance. When I have been on the sales side of things, it always frustrated me when my teams were selling to Yes. Instead of asking the hard questions of “why us” and “why now”. When I have explained to sales forces, product management sells to No. And that this is in order to figure out what uses case get scheduled on the roadmap, they seem to understand it. In fact, you gain the respect and assistance of those sales forces, which is critical.

To summarize this article here are a few key takeaways:

• Saying No should not be the first action
• Put a list of questions together to explore the question more
• Be an active listener and question to gather the data
• Understand where the other person is coming from and the find the value
• Be able to articulate both sides of the question before saying No to one side
• Represent the company’s business interests beyond sales