“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the 100 other good ideas that there are.” – Steve Jobs
This year, I have worked with a range of Product- (both in hard- and software development) and IT organizations. The common denominator among them seems that they all feel hopelessly overloaded and struggle to cope with the demands put on them.
This experience culminated in someone from an IT organization approaching me during a workshop’s coffee break last week and asking my advice on how to say “no.”
In my view, there are at least three causes of the overload:
- the siloed design of many organizations requires endless coordination efforts
- a widespread lack of (product-) strategy
- Product Owners, Product Managers, Project Leads, … never having been trained on why, when, and how to say “no.”
I will focus on the last of the three today: “saying no.” However, at least the second issue – strategy – will need to be tackled for a sustainable solution to the problem.
Let me start with this: PMs and POs have the right, if not the duty, to say “no” often. They must keep their product focused on the job-to-be-done it is meant for, as development resources are finite.
Therefore, the most beneficial features are often the ones never built. Randomly adding more “stuff” to a product because some stakeholder demands it rarely makes the outcomes more helpful or usable. That holds true in particular if the additions follow different directions or strategies.
Too often, the results remind me of a utensil my Mom kept in her kitchen drawer: It combined multiple tools, hammer, pliers, screwdriver, and others. But due to theincoherent way they were implemented – a far cry from modern Gerber or Leatherman tools – they got in each other’s way, rendering the combination essentially useless.
Focus on a product’s purpose and strategy avoids that. Saying “no” is a way to keep focus. But how do you do that?
- Actively try and understand the demand. Empathize with the stakeholder. Ask clarifying questions to make sure you fully grasp the requirement and the stakeholder’s reasoning behind it.
- Try and assess its business value. How many users or other stakeholders will be impacted, what is the measurable benefit, and how can you know fulfilling the demand will unlock it?
- Paraphrase and summarise what you understand to ensure you are on the same page with the stakeholder.
- Say “no!” – but avoid making it personal. Refer to the data provided, how they rank in your priorities and how they relate to the product strategy (make sure you have one!). Use a framework like e.g. RICE, to rationalize your arguments. Point out opportunity costs where applicable. Don’t compromise.A low-value demand adds even fewer benefits when implemented only halfway.
- Make sure to part on good terms with the stakeholder.
- Continue to use data or data-based assumptions to evaluate demands transparently. Kill questionable ideas for good by pointing out their lack of value.
“How to say no” is a frequently discussed topic. Google counts more than a billion (!) items relating to it. Here are three reads I believe are worth your time:
5 Tips for Saying NO to Stakeholders
Renowned product management author Roman Pichler’s five practical tips for saying “no”
Product Strategy MeansSaying no
Intercom’s CSO Des Traynor discusses the most commonly used stakeholder arguments for adding stuff