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:
Fig. 1 — Taken from: https://www.linkedin.com/pulse/focusing-saying-avelo-roy
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 — Open the kimono
“Opening the kimono” is quite a popular phrase, but is effectively just stressing the importance of being fully transparent with others. As a product manager, you’re typically in a great position to provide full transparency on:
Open the kimono 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.
Fig. 2 — Taken from: https://uk.pinterest.com/olivialatenight/lolita-harajuku-korean-streetwear/
Option 2 — Scope small and test assumptions
I absolutely love Peter Merholz’ wedding cake analogy: there are two ways to bake a wedding cake (see Fig. 3 below). 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?”
Fig. 3 — Peter Merholz’ two ways of baking a wedding cake — Taken from: https://blog.intercom.com/start-with-a-cupcake/
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?
Fig. 4 — Estimated vs actual cost of a small feature — Taken from: https://blog.intercom.com/product-strategy-means-saying-no/
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.
Fig. 5 — Taken from: https://www.flickr.com/photos/terdata/287937963
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:
- https://blog.intercom.com/product-strategy-means-saying-no/
- https://www.prodpad.com/2014/05/saying-tough-love-product-managers/
- http://www.cleverpm.com/2015/02/24/saying-no-without-saying-no/
- http://www.mindtheproduct.com/2015/02/just-say-no-hard-decisions-in-product-management-2/
- https://www.productplan.com/how-product-managers-can-say-no/
- https://vimeo.com/110270432
- http://www.jamasoftware.com/blog/product-managers-you-can-say-no-and-still-make-people-happy/
- http://www.mironov.com/strat-priority/
- http://adaptivepath.org/ideas/cupcakes-the-secret-to-product-planning/
- https://blog.intercom.com/start-with-a-cupcake/
- http://www.peterme.com/2012/09/04/reframing-ux-design/
- https://www.under10playbook.com/blog/dealing-with-one-off-feature-requests
