How and Why to Say No as a Product Owner/Manager

As a Product Owner and/or Product Manager, it's important that we partner with our clients to achieve the best outcomes possible. Sometimes the best way to achieve an outcome is by saying, "no". While it may seems counter-intuitive that being a good partner means saying no, it truly is an effective tool to help teams remain focused on high-value items, stay on schedule and be conscious about the overall health and budget of the project.

When to say no

 Reasons to say no can vary widely. Here are some common themes.

• The request is not in alignment with the vision. The idea might be good, but it completely takes the product (or project) in a different direction.
• The request is a high cost with low or no value or there are more valuable features to build. Your end-users say this is a feature they would never use, but a stakeholder thinks it's the best thing since sliced bread. Or your team has limited resources available, so you need to pick the highest valuable feature to build first right now.
• The request is not feasible. Asking for a 6-months worth of features to be done in 3 months sets the team and project up for failure before starting. The Product Manager should always be pushing but needs to know what is reasonable and feasible.

Understanding why saying no is so difficult

One of my favorite books I read in 2021 was called Not Nice: Stop People Pleasing, Staying Silent, & Feeling Guilty by Dr. Aziz Gazipura. In this book, he coined the phrase, "Don't Be Nice. Be Real." He described that what keeps us from speaking up is that we're afraid of hurting someone's feelings, or that someone won't like us, or that the guilt will be so overpowering that giving in is better than saying what we really think. I've validated this with peers who said they struggled with saying no because they don't want to seem like they aren't being a team player. It is better for you, the team, and the product to do the hard thing and use your consulting and persuasion skills to advise the Product Manager on the request rather than simply taking orders. How do we know if we are making the right choice and what is the risk of getting the decision wrong?

If we can dig into why we are struggling to say no, then we can focus on finding a way to counter that emotion. This does take some Emotional EQ work. When you are trying to figure out why you can't say no, take a moment and don't immediately answer. Have time to understand and give space to see what is the root cause keeping you from saying no. Is it guilt? Is it to impress? Is it external pressures you feel powerless against?

For example, you have a key stakeholder with a product who is pushing for a solution by a certain deadline. The reality is that there are very limited options, and the new deadline is not the right choice. But you want to please this stakeholder so you can be their "superhero" and they can support you on the next product feature you need to get funded. So, what do you do? 

Dr. Gazipura would say, "You can choose to start saying no when you want to and need to and face the initial discomfort, or you can continue to avoid saying no and continue to play nice to avoid the disapproval of others." Is it worth pleasing a stakeholder one time, who may not even return the support in the future? Or is it more valuable to be candid and real - laying out the challenges with the request and finding an alternative solution that will be a win/win for everyone? If you can acknowledge why you are struggling with a simple no, then you can identify your trigger and make space for it. You can acknowledge what you are feeling and then give yourself permission to say no. You can still be kind and empathic, and being real is being nicer than you think. Plus, "saying no in your business and work-life ends the insanity."

Tricks for saying no

Now that you have a better sense of why you're struggling to say no, let's explore some tips and tricks to help stand your ground! Please note that these examples do not live in silos. You can combine and adjust as your scenario demands.

• Tip 1: Options 
  My favorite – Delivering options and letting the person with the request be part of the decision. The key with this tactic is how you present the options. Think about the scenario above: your key stakeholder insists on moving up the product release date. Moving up the date will not give you enough time to get in all critical features, plus your team will probably declare mutiny! Try approaching this stakeholder this way:
  
  Bob – I hear the desire of the ask is to deliver the product to the market quicker to beat a competitor's release. I totally appreciate that, so here are the options that we have and the impacts for each: 
  
  
  • Option A – We move up the timeline but cut half of the features to hit your deadline. Value: we deliver against the timeline, but you won't get all features you have expressed were critical.
  • Option B – We keep the current date, which is past your desired deadline, and we keep all features we have planned. Value: we keep all features you have deemed critical, but we aren't expediting the timeline to meet your desired market release.
  • Option C – We try a phased release to reprioritize the features in this order so you can release sooner but with a smaller slice of the features, and we enhance over time. Value: we can deliver to the market sooner, and we can get a functional base of the critical features you deemed critical. We continue to work to further enhance in an incremental approach. 
    
    My recommendation, Bob, is Option C - This not only allows us to be flexible in the future in case we need to pivot to address changes in the market, but as we create a regular release cadence, end-users will look forward to what new enhancements will be coming.
     
• Tip 2: Leverage Data
  Clearly say no, but back it up with data. For example:
  • I respectfully disagree with the ask. The feature you want is not a priority to the product right now. Based on the research we have done only 5% of the end-users would use the feature. We should focus on the current effort we have in place that will impact 60% of our end users and help drive revenue (or reduce cost) by 25%.
     
• Tip 3: Set Boundaries
  Set a boundary on what is being focused on right now. People have ideas and teams need to stay focused. It is okay to say, "That sounds like an interesting idea, but it is not a focus of the product currently." Generally, if something is important, it will pop up more than once.
  • Please bring this back up in X months and we can re-evaluate against the other priorities.

Sometimes the culture you are working in doesn't have 'no' in their vocabulary; it's the culture of 'do whatever it takes.' Here's the thing – I personally believe there is always a path to a solution that can be perceived as falling into the 'do whatever it takes' category. HOWEVER, factoring in all the things that are possible to achieve, the value is key. Pushing to build the shiny object even though the end-users of your product don't want the shiny object makes no sense. When dealing with the 'do whatever it takes' culture, it is often best to present the options approach or get others to rally behind your recommendation.

As you plan your strategy, be mindful of the most effective method for your audience to receive your plan, as mentioned in the book, How to Win Friends and Influence People in the Digital Age adapted from the teachings of Dale Carnegie. The ideal method is in person, but a video call is a great substitute. If you need to email or use a written form, keep it short and to the point, and give the opportunity for a meeting to talk through the options. 

Knowing when to say yes

Someone comes to you with a key market need due to the pivot a competitor is making, OR there are new critical compliance needs to ensure you don't get dinged by the feds, OR your end users are screaming about a pain point and it's costing you money and reputation… then for goodness' sake, say YES.

That is after you have done your due diligence. Have you fully identified the right problem? Do you have data on the impact of saying yes? Do you feel confident it truly is the right thing to work on RIGHT now OR are you being reactive? It is extremely important to listen to your end-users, but just because folks are screaming for the background to be in glitter text doesn't mean it is the right thing to do. But if you have data, see the return on investment (ROI) the change can make, then do it. 

For example, on one product I was managing, we started to see a pattern of end-users not understanding why some transactions were not displaying. As we dug into it, we identified two business rule changes that would significantly reduce the confusion. We decided to immediately bring the stories into the current sprint so we could update them in the next release. Before the change was released, we had an average of five end-users contacting us through the feedback tool every business day. After the release, the frustration-filled feedback fell to zero on those topics. This is a strong example of when to say yes.

At the end of the day…

Understand why you are saying no or yes. Be able to tell a story about the value the decision is bringing especially if you need stakeholder buy-in. Think through your approach to presenting the options - consider the impact on time/quality or even cost. At the end of the day, everyone really does want the right thing done, but sometimes we get in our own way of saying no.