Four ways PMs can say No
As we race to finish the year 2022, the field of product management is seeing a paradigm shift. We have more PMs joining the product community now than ever, as more PMs are progressing up their career ladder. Experienced PMs are contributing to making the product roles less ambiguous, making it easier for new PMs to succeed in their jobs.
From learning to driving, product management is evolving in favour of mastery.
While this is great, the shift demands more courage and confidence from the product manager. For better products to churn out, PMs need to be okay with disagreements — with stakeholders, engineers, and other PMs. They need to learn to say No for the benefit of their product and create the most significant impact.
Here are some ways a product manager can say No:
- Focus on your company goals to say No: Many times, a PM can look into their stakeholder-driven product backlog and think, “hey I should build these next as these have been in the backlog for a while now”. However, most items on the backlog may not tie back to the company goals. If say your company has the goal to spend less on acquiring new users, then one of the objectives of your product can be to improve user retention. Stakeholders might create urgency by talking about their pain points, however, their pain points could just be an inconvenience that doesn’t impact the ultimate product objective. Bring up the objective, the broader company goal, to say No.
- Think about your product’s evolution to say No: If your product has been around for a while, it has seen an evolution that clicked. Its success can be tied to a clear evolution path. Eg- a discount product might have evolved into a loyalty points product, and the same customers who liked the discounts now enjoy earning loyalty points and utilizing them as they wish. Thus if you notice that a feature or a set of features gets discussed by your team that distorts the evolution of your product, or derails it from its ultimate vision, pragmatically, say No. It’s better to build for success when the ultimate product vision is clear. There’s only a need to reinvent a product (aka changing its evolution path) if the product is not working for a while and you see enough data to tell you this.
- Discuss data that aids prioritisation to say No: Another way of evaluating a stakeholder’s product request is by seeking data. If their requested feature can speed up execution but is a roadblock to another feature that benefits your product in the long run, seek the data: is the faster execution needed this quarter? is the current speed of execution through the existing product features not good enough? is there enough evidence to guarantee adoption of the requested feature as soon as it is shipped, or will it take much longer to adopt it? If the requested feature is truly important and urgent, your stakeholders will give you these data points in their initial request. Decide feature priority based on these data points, say No if you see that the data is not sufficient, or if the data doesn’t make a good case to pick up the feature in priority.
- Ask Why to say No: As a product manager, it is your job to sift out dopey feature requests. Dopey feature requests are the ones which get aimlessly talked about because it’s easy to discuss these features. They usually come up during your product strategy and discovery phases because someone just decided to be lazy. Never forget to ask Why a certain feature is needed. If the reasoning carries conviction around the outcome, it will automatically build a consensus. Say No if the reasoning is not strong enough — it’s a dopey feature that your product doesn’t need.
