One of the things I’ve seen product managers struggle most with is how to say “no” effectively to internal stakeholders when asked to incorporate a new feature or capability that doesn’t align with the strategy. It’s a difficult balance since the product manager needs to steer the product team’s work towards its biggest customer needs, objectives and key results (OKRs), while maintaining a trusted relationship with their peers and partners. Common requests can range from:
- Sales: “I just had lunch with [biggest client] and they raised how important it is for them to be able to [do something in the product], how quickly can we make this happen?”
- Engineering: “We are unable to process [thing] efficiently anymore and need to re-factor [component] in the next sprint to avoid any potential issues.”
- Strategy: “Did you read about [competitor’s] new launch? What are we building to compete with that?”
- CEO: “I believe that there’s an opportunity to expand to [new market / segment] by just building this one new capability. How fast can we get a working prototype up and running?”
Rather than feeling like you are on the defensive, look forward to having these conversations. They present an opportunity for you to engage with your most important stakeholders and share where the product is going, how you are measuring effectiveness, and have a healthy debate about whether the request is supporting these objectives. Taking the time to understand the request, pushing back with strong reasoning, and showing confidence about where you are guiding the product can strengthen your relationship rather than bruise it…as long as you do it in the right way.
We will often say no (or not now) because:
- It doesn’t solve our biggest customer problem(s);
- It would prioritize one client’s needs over the broader customer base needs;
- It doesn’t support our goals and OKRs;
- We would have to stop something important to start this, resulting in negative consequences or lost opportunities.
You will be pressured, put on the spot, even called out in large meetings in front of your boss – how you respond is equally important to the end-result. Below are seven recommended tactics on how to engage and say no effectively:
- Understand the request. Although most stakeholders will come your way with a solution (“if we just built this feature it would solve what my client needs”) ask questions to understand what the customer is trying to accomplish and why. Forget solutioning and understand the core problem at hand, and then see where it sits alongside your other work.
- Don’t wait…seek out ideas. You always want to be looking for ideas whether it’s from your customers or internal employees. Reacting to one-off requests often make product managers feel defensive. If you establish a process and make it part of day-to-day activity, it will feel more like business as usual. It’s likely that tools you already use like Aha! or Jira have this funnel capability – turn it on, but make sure to set the right expectations around receiving requests vs. automatically doing them.
- Empower the rest of your product team to say no. By habit, stakeholders will come to the product manager to request something new. Remember, you are one person part of a larger product team. Your tech lead, designer, analyst…all should feel empowered to have these same conversations. If you have a clear vision, roadmap, and OKRs then you can all speak the same language.
- Bring data into the conversation. A product manager needs to know their customer base better than anyone else. Know your critical data points and bring them into the conversation. It’s very powerful to push back by saying things like, “One of our OKRs is to increase retention by x%, how does this help us get there?” or “our latest research has shown us that x% of customers are asking us to solve problem y, how does this fit in?” Other data points to have on hand are capital budgets, revenue goals, headcount, and competitor activity.
- Reinforce the product’s strategy. Use this as an opportunity to re-communicate your broader product vision and in-year plan. Be transparent in not just what you’re building, but what you’re testing, and why. Make sure everyone knows your vision, 12 month OKRs, biggest customer problems, and roadmap. Continue to over communicate so nothing is ever a surprise.
- Test the hypothesis. What if your boss or CEO is insistent on moving forward even after you’ve presented an incredibly strong counter-argument? Try to steer the conversation towards testing. Can we design a low-fidelity concept to present to customers so that we can test the hypothesis? Look at ways to get customer and/or market feedback to validate this person’s demand.
- Provide no-code alternatives. Instead of a flat-out rejection, offer alternative solutions or compromises that could address the underlying problem or need without derailing the current priorities. How about building an Excel report that gets emailed daily vs. putting a new web report in place? What about email alerts one customer needs vs. creating a UI-driven feature for all?
As you engage, remember that it’s not just what you say that has impact, it’s how you say it. Some other tips:
- Be firm but respectful: It’s essential to maintain a respectful tone when saying no. Firmly communicate your decision without being dismissive or confrontational. Continue to be empathetic and understand where the urgency is coming from and how this person is trying to manage the need.
- Document and follow-up: After the conversation, document the decision and the reasons behind it. Follow up with the requester to ensure they understand the decision and address any concerns or questions they may have. Share links to roadmaps and other artifacts and if need be, schedule a follow up in a month.
- Learn from feedback: If someone challenges your decision, be open to feedback and be willing to reconsider if new information or insights emerge.
Saying no is not a negative act in itself. No can be a positive, reinforcing sign of confidence and focus for a product team, as long as there is an openness to explore the idea and a coherent, data-driven explanation on why ‘not now’.