Say ‘No’ without making your business stakeholders unhappy
“The art of leadership is saying no, not yes. It is very easy to say yes”
~ Tony Blair
There is an itch to say ‘Yes’ to all, but as a product manager it is mandatory to master the art of saying ‘No’. To begin with it is ok to say ‘No’ and not ‘May be’ or ‘let me see’ or ‘later’. But how do you do it right every time without offending anyone as you are actually writing off someone’s thought?
‘No’ is a very powerful word and it takes a lot of practice to get used to saying it with confidence. The art of saying ‘No’ is not only relevant in the field of product management but in all spheres of life and career.
Product Managers need to make choices regularly, which means they have no choice but to turn down more ideas or features to arrive at a decision which derives highest value for the customers. The level of complexity is high because every stakeholder expects faster resolution to their problem, and no one likes to be placed second in the priority list.
Why should you say ‘NO’?
Imagine you are building a product to identify which subject should be included in the primary school curriculum. Let’s say if you say YES to all your stakeholders:
· The CEO says Mathematics is one of the core parts of human thought and the day-to-day logic application and hence should be compulsory.
· The Operations representative says English should be made a compulsory subject as it is essential to communicate.
· Someone says at a primary school level, we should focus on including moral science as it will help the student identify between right and wrong.
If you say YES to all, there will be too many subjects and the students will not be able to concentrate in any of the subjects thus affecting their productivity. In the long run, the parents will end up choosing some other school over this. Hence the end product will turn into a liability rather than an asset.
One of the videos of Steve Jobs touch precisely on this topic “Focusing is about saying NO” and is worth a watch!
Every product can be built in thousands of ways but there are only a select few which will connect with your end users. As a product manager you need to continuously rally to identify those select features keeping in mind limited time and resources, and the fact that it should connect with end customers. You need to constantly switch between the 10000 feet view to 2-inch view, and when you do that not every feature/ask from your stakeholder will fit in right. Hence learning the art of when to ‘Yes’ and how to say ‘No’ with empathy can deliver some ultimate control mechanisms.
Read along to find out how to master the art of saying no without hurting your relationship with the stakeholders.
Toolkit for product managers on how to say ‘NO’ without spoiling relationships
- Be transparent
“Open kimono” is one of the popular business jargons which stresses the importance of being fully transparent with others. As a product manager, explain your position and be completely transparent. One of the effective ways is to put together all the points in a lean canvas and kick start an open conversation of what could be the potential impact of certain decisions. Your lean canvas should on a high level include Vision, Strategy, Tradeoffs, and value.
Apart from this, work on a product roadmap to explain how the evolution of product would be over time. During these conversations, consider touching upon all the requirements and features, for example what would it cost if feature X is deprioritised in favor of feature Y.
2. Spend time in product discovery and work on MVP/Prototypes to validate assumptions
It’s better to fail early in the process than in the end. Instead of a Big Bang delivery, look for how you can go for iterative & incremental development. Henrik Kniberg in his blog, emphasises on how to derive value of basic Agile methodology.
Let’s take an example:
Imaging your stakeholder wants to get a complete report every morning which helps him understand his store sales. This is a very broad requirement and many metrics and KPIs can be squeezed into this report. So, how do you identify what is of value to the stakeholder? This is where product discovery comes into play as it helps you identify right product to build. Create a basic prototype and it can be in excel too, to start with. Layout all the metrics that will tell the story in the best way. This prototype might go in for 10–15 iterations based on the feedback from the stakeholder but at the end of it, there will be a clear direction on what needs to be built. As the old saying goes, “a problem well-stated is a problem half-solved.” Refer to Marty Cagan’s blog to read more on product discovery.
3. Evaluate all the associated costs and risks
As a product manager you need to dabble between zillion asks and limited resources, and hence if someone wants to add X feature to the roadmap, you need to really evaluate the need of having that there. Lot of times, the time to build is minimal but the maintenance itself is high.
For example, the stakeholder wants to add a delete record button.
· Development cost — The development cost is low.
· Potential Risks — Associated risk level is high. If some data record is deleted by mistake, then we should have a mechanism in place to retrieve the values. Hence other features need to be built for the purpose of mitigation.
· System impact — Evaluate ramifications on the wider system?
· Technical debt — Would there be a technical debt if this feature is implemented?
· Adverse Impact on customers — This might alienate and reduce trust in the product if the associated risks mitigation features are not built alongside the feature itself.
4. Pushing back and saying ‘Not Now — We will add it in the product backlog’
Lot of times it is difficult to squeeze the work item in the roadmap because of limited time or resource availability. Hence, it’s a not a straight ‘no’ but it is something that you intend to include at a later stage. For example, let’s say the stakeholder wants a smart filter instead of basic filter. This is a great idea and would add value to the overall product but not something you would want to build in the first version. So, you can keep in backlog and add to the future roadmap. The matrix above can be used to group the features for better clarity and evaluation on what should be considered in the roadmap.
Also please note there are a lot many times product managers say “We will add to the product backlog” in the hope that with time this would be forgotten. However, be cautious not to add any idea/feature request to product backlog if you do not intend to include in the end product. In such an event, where you see a feature should not be added to the product, be transparent with the stakeholders, reason it out and discard. Transparency is the key!
5. Look at providing alternative solutions
It is not possible to implement the exact idea/requirement itself but when tweaked to something similar, you not just add value to the product but also make your stakeholders happy. So, instead of a direct ‘No’, you can spend time listening to the stakeholder’s idea and evaluating them. A product manager needs to be visionary and a thought leader who can guide the stakeholder right.
Constant stream of ‘No,No,No!’ may be frustrating to ears but replacing all ‘No’ with ‘Yes’ can eventually hurt. Hence evaluate your options carefully, be transparent and do not hesitate in saying ‘No’!
References Links for further reading
https://www.mindtheproduct.com/just-say-no-hard-decisions-in-product-management-2/
https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
https://svpg.com/skateboards-vs-cars-revisited/
https://svpg.com/beyond-lean-and-agile/
https://www.prodpad.com/2014/05/saying-tough-love-product-managers/
https://maa1.medium.com/my-product-management-toolkit-20-the-art-of-saying-no-27cdda76d5de
http://www.cleverpm.com/2015/02/24/saying-no-without-saying-no/
https://blog.intercom.com/start-with-a-cupcake/
https://blog.leanstack.com/what-is-the-right-fill-order-for-a-lean-canvas-f8071d0c6c8c
