My Product Management Toolkit (20): The Art of Saying “No”

Saying “no” is possibly one of the most challenging parts of being a product manager. There are so many great business and product ideas out there and ideally we’d like to do all of them. I can, however, only refer to one of the greatest product people and his views on the importance of saying no:

Image Credit: Avelo Roy on LinkedIn

These are the main reasons why I believe in the importance of saying no:

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.

As a consequence, every product person benefits from having a few ways of saying no in his or her toolkit. I’ll highlight five different options for when you want to say no:

Option 1 – Being fully transparent

Being fully transparent with others helps with saying no. As a product manager, you’re typically in a great position to provide full transparency on:

  • Vision
  • Strategy
  • Roadmap
  • Backlog
  • Tradeoffs
  • Cost (incl. delay)
  • Value (incl. ROI)

Being fully transparent helps you to start an open conversation about the potential impact of certain decisions. For example, what will be the likely cost of delay if we decide to deprioritise feature A in favour of feature B.

Option 2 – Scope small and test assumptions

I absolutely love Peter Merholz‘ wedding cake analogy: there are two ways to bake a wedding cake. One way is to create a big wedding cake; starting with a cake base, adding the filling and icing. Alternatively, you can start with a small cupcake and see what the soon to be married couple think about it, after which you can decide to make a cake or a proper wedding cake.

The key here is that you’re not saying no and shutting the door on an idea or project. In contrast, you’re proposing to start small and get real user feedback ‘often and early’:

Scope small – “I suggest we don’t commit to the entire product or project upfront. Instead, I suggest we focus on a single feature or value component first and measure its impact. We can then always decide to do more and iterate.”

Test assumptions – “We assume that our users need a tomato juice to quench their thirst. How can we best validate this quickly before we commit to making tomato juice?”

Image Credit: Des Traynor

Option 3 – Consider side effects

We all know how easy it can be to say “yes” to an idea or an improvement that sounds ‘small’. However, in doing so we often forget that even the smallest of features or changes can have a big impact. There are a number of potential side effects to consider before saying yes or no:

Development cost – What are the cost of creating this? What is does the expected ROI look like and why?

Maintenance cost – Can we maintain it? What are the cost involved in doing so?

Business model – How does this fit with our business model?

System impact – Are there any ramifications on the wider system?

Technical debt – Will we incur technical debt as a result of this feature or change?

Unhappy customers – By doing this, will we alienate clients?

Image Credit: Des Traynor

Option 4 – Not now

It’s not a straight no, it’s something we could or should be doing later. For example, “let’s do this once we’ve implemented our new shopping cart feature, as it will be easier to add this feature on then. We will add this to the “next” section on our roadmap.”

One word of warning: I’ve seen many people using this approach to kick things into the long grass, burying things into the roadmap or backlog in the hope that it gets forgotten about. I believe this counterproductive and dishonest. If you already know that something isn’t going to get done, then it’s better to be transparent about this upfront.

Image Credit: Peter Bongers on Flickr

Option 5 – Provide options

Instead of offering a downright no, provide options and explore the pros and cons of each option. I’ve found that this approach really helps in having a constructive conversation with business stakeholders about business goals and tradeoffs.

For example:

Option 1: build on top of existing APIs

Pros: speed to market, less costly, meet partner expectations

Cons: not scalable, opportunity cost

Option 2: create API framework first and then create new API endpoints

Pros: fully scalable, revenue and partnership opportunities

Cons: takes longer to develop, and will be more costly

Main learning point: Saying no and declining a request or an idea can be hard, but very necessary at the same time. Whilst it can feel a tad uncomfortable, there’s a lot of value in saying no in a more informed and constructive kind of way.

Related links for further learning:


2 responses to “My Product Management Toolkit (20): The Art of Saying “No””

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: