Product Managers, how to creatively say No?

“A great product manager has the brain of an engineer, the heart of a designer, and the speech of a diplomat…”

The art of saying No

This is a very dear topic to me as I ponder over this question, as product managers, how many of us say “NO” to our internal stakeholders, business users, customers on a monthly, weekly, daily or hourly basis?

There are multiple risks involved with always saying yes, so why do we feel inclined to say yes? Let’s take a step back and evaluate a few probable reasons why PM’s say yes:

• “But it will take a few minutes…”
• “But an important customer said, they wanted the feature or else they will quit…”
• “But the market data looks kind of positive…”
• “But our competitors have implemented it and driving significant business…”
• “But the feature has been requested so many times…”
• “But the senior leadership insists…”
• “But we will achieve our quarterly target…”

Saying Yes often can lead to chaos. If a PM can’t focus, they tend to have problems. Instead of doing one thing well, they end up doing lots of things poorly. Then there also remains the risk of jeopardizing relationship with one’s development team if you don’t have a prioritized list of things to work on that also takes into consideration a team’s velocity, technical debt, technical priorities and so forth. You end up lacking a cohesive vision and spreading yourself too thin trying to be everything to everybody. How to justify your decision making process?

As PM’s, we surely work on market research, competitive analysis, customer validation, MVP’s etc to determine the value of features or requests to develop however Jack Welch, former CEO of General Electric, said it bluntly: “If you don’t have a competitive advantage, don’t compete.” Put another way, if you aren’t striving to be the best at something, it’s not worth doing.

Say “no” to anything where you aren’t working to be the best.

Few people enjoy saying “no” to someone. It’s difficult for me. It should be difficult. But that doesn’t mean we can avoid doing it. Sometimes we need to say “no” in order to make an explicit decision, as opposed an implicit amorphous one.

Implicit decisions are those that get made for us by us environment, by our process, or by someone else we don’t know. Those kinds of decisions are rarely the best ones. To once again quote Jack Welch, “Control your own destiny or someone else will.”

So, the question arises, how to get to Yes by saying No?

Read this interesting article on how to say No: https://productcoalition.com/product-management-is-not-about-saying-no-it-s-about-how-to-say-no-e461236c138c

Saying “no” and saying “yes” are complementary tasks. While we can’t say “yes” to every feature, by explicitly eliminating a few, we can focus our efforts, and our decision-making about what to include or not include, on those that remain.

And by building a collective priority of audiences and use cases that puts us all on the same page, we can support those users at the top of our list even better than we do today.

Read this excellent article by Marc Abraham where he elaborates on the following reasons why he feels it’s important to say No: https://www.linkedin.com/pulse/my-product-management-toolkit-20-art-saying-marc-abraham

Focus — We can’t do it all! What’s truly important, why? Will it move the needle? If so, how?

Constraints — Every business has constraints, e.g. people, time, money, opportunities, etc. As a result, saying no sometimes acts as an absolute necessity.

Cost and risks — We need to say no from time to time to manage (opportunity) cost and risks.

So how do you evaluate the different criteria and come up with a way to analyze and prioritize your focus list?

Here’s a snapshot of a framework that I have personally used and have derived immense value in making decisions. I usually work with the internal stakeholders, executive team, business users and the Product Team to gather insights. This has led to quicker executive/stakeholders buy in and reduced the discomfort of saying No.

• Implementing “Selection Criteria” & customizing weightings to match current business priorities.
• Analyzing “Project Scoring” by ranking each project on a scale of 1–10 based on how well it meets the selection criteria.
• Evaluating project scores through assigning a “Rankings” score to make resource allocation decisions.
• Using a simple tool like the “Bubble Matrix” to communicate project rankings for strategic fit, economic impact, and feasibility.

The selection criteria that I like to use are:

• Alignment with Company Goals : How aligned is this project to corporate goals & objectives?
• Market Positioning :Does this initiative position us better in the market
• Core Capabilities : Does this initiative leverage our core capabilities (technology, operations, sales)?
• Revenue Potential : What is the anticipated impact on revenue for this initiative.
• Cost/Benefit Analysis : Does this initiative have a solid cost/benefit? Low Cost Is this project relatively low-cost?
• Technical Risk : What is the probability of overcoming the technical challenges of the project?
• Resources-Financial : Do we have the financial resources to execute this initiative?
• Resources-People : Do we have the skills & team bandwidth to execute this initiative?

Once you finalize scores for your list of requests(by brainstorming with your stakeholders to finalize scores for the different projects), you can generate a bubble matrix to categorize projects in four quadrants:

• Top Priorities
• Future Potentials
• Potential Cuts
• Back Burners

When you are in the middle of making a critical decision of prioritizing features, it’s important to make sure the stakeholders, business users, understand the decision making process.

And when the decision is eventually made through a quantitative tool like this, make it clear to them what the decision is, the reasoning behind it, and that it’s time to move on to the next challenge of execution.

While justifying why you’re saying “Yes” to some requests and “No” to a few others, it’s also imperative to effectively communicate that to your development team as most often they do not know why they are working on certain projects and what impact are they delivering.

Hence, this framework works as a well defined communication tool across any organization and has helped me say “No” creatively a lot of times.

Feel free to share your thoughts and feedback around this framework! Happy to connect with fellow Product People on LinkedIn: https://www.linkedin.com/in/mohantyshilpa/