Our Job Isn't To Say "No"
Read on my website / Read time: 5 minutes
Thank you to our sponsors who keep this newsletter free for the reader:
Support This Newsletter With A Sponsorship
Product Managers lead buy recommendations and decisions for their companies. Promote your product or brand to a passionate community of over 3,300 product managers and leaders.
|
“Yesterday, I was talking to Big Industry Player and they mentioned how they have Shiny Object. I think we should have Shiny Object too. How fast can we get it done?”
A top exec at your company comes to you and says this. What do you do?
Shiny object syndrome...
We've all been there. We spend weeks crafting our roadmap and aligning everyone on the product priorities...
And then we get that one request that threatens to derail the whole dang thing.
It could come from anywhere - customers, sales, support, operations, finance, legal, and - our favorite - an executive.
And now we have to deal with it.
Everyone thinks their idea is awesome. The one idea that's going to unlock untold amounts of revenue, create an unbeatable differentiator, or seal the deal for that one whale of a customer.
In these instances, our instinct is often to say, "No!"
Indeed, there are tons of LinkedIn posts and blogs that have told us to do just that.
"Product management's job is to say no," they say. "If you just keep accepting feature requests, you'll become (horrors!) a feature factory," they threaten. Or they'll quote that line from Steve Jobs where he talks about how focus means saying no to the hundreds of other good ideas.
This gives me flashbacks to how I used to handle these situations. (Facepalm.)
I would push back, talk about how the team is busy delivering on current commitments, how the backlog is full, how (in my opinion) Shiny Object doesn't fit with the current strategy, issue dire warnings about the dangers of building a copy-cat product, lecture about how we need to follow our prioritization process.
I even once threw that Steve Jobs quote at a CEO. (Predictably, it got me nowhere.)
Unfortunately, I came across as close-minded, being obfuscating, offering excuses, and arrogant.
I was seen as being sanctimonious and, ironically, not focused on the customer!
The reality is these approaches never, ever work:
- Sales people will simply go around us and escalate to the highest level they can, including the CEO.
- People will feel like they're not being heard.
- People will lose faith in the product roadmap.
- We gain a reputation of being blockers, not enablers.
- We're labeled as "not understanding the business."
And you and I are not Steve Jobs. (I would say why be him when you can be you? But that's for another article...)
It's not their job to adhere to product development priorities or processes.
The truth is that most executives and folks on the commercial side have little self-awareness that they're eating the cake one crumb at a time.
They can't (or won't) see engineering capacity or product waste.
And they don't care.
They don't care about agile, scrum, sprints, backlogs, prioritization methods, velocity, story points, discovery, process, tech debt, any of that.
They can't understand why their request is not the most important one.
They just want the thing they want at the time they want it.
And, to be honest, particularly with executive requests, not addressing the request can be a career-limiting move.
The job of Product Management is NOT to say "No".
That doesn't mean we just roll over and say, "Yes, sir, may I have another?"
What we want to do is create a structure that provides a strategic context in which to respond to their request. We want to frame things in terms of opportunity costs and trade-offs.
Requestors rarely have full sight of the impact of their requests or any sense of the cost of making the change.
So, it's important we help them through this thinking.
I now use a simple 5-step playbook to quickly triage these requests. I'm going to share it with you today.
By following this formula, I've not only been able to triage requests faster, but also improve my credibility with my co-workers and the people who control my career destiny.
Here's the playbook:
- Listen actively with empathy.
- Calculate a rough order-of-magnitude impact of the idea.
- Compare its value to that of current opportunities being pursued.
- Reframe the request in terms of trade-offs.
- Say "no" WITH them vs. AT them.
Let's dive in to each play.
1. Listen actively with empathy.
Our first job is to make sure the requestor feels heard and that we've given ourselves full opportunity to understand the request.
We need to keep in mind that there is a reason why this idea is meaningful to the requestor. We need to honor that.
- Use affirmative body language to show we are paying attention - eye contact, nodding, smiling, and an open and relaxed posture.
- Use active listening skills when they're talking and don't interrupt them.
- Ask them to explain their idea and the reasoning behind it. Some useful phrases include, "Help me understand...", "Could you walk me through...", and "Could you expand on that?"
- Use mirroring to build rapport and illicit more insights. This is repeating back to them the last thing they said as a question and then empathizing with their concern. For example:
Them: "Not having this feature is costing us millions!"
You: "Costing us millions?"
Them: "Yeah. We've lost 4 RFPs already by not having this feature."
You: "We definitely want to be competitive in our RFP responses."
- Use parroting to confirm understanding - i.e., repeating back to them what they've said but paraphrase it in your own words to show you have listened. Some useful phrases include:
"Let me play back to you what I think I heard you say - and keep me honest as I do..."
"So if I'm understanding correctly, you're saying <blank>. Did I get that right?"
- Ask clarifying questions to understand from them the value they see that the idea would deliver.
- Reserve judgment on their idea for now.
2. Calculate a rough order-of-magnitude impact of the idea.
For example, let's say Shiny Object is intended to acquire more customers. You could do some quick math:
Rough value of the idea =
([guestimated deals lost due to lack of Shiny Object] + [guestimated deals we could win with Shiny Object])
* [average new buyer ARR]
E.g., (5 deals lost without it + 10 deals won with it) * $50k ARR = $750k in incremental ARR
Another example: let's say Shiny Object is intended to upsell existing customers.
Rough value of the idea =
[current customer base ] * [guesstimate of upsell conversions] * [incremental revenue]
E.g., 1000 customers * 5% upsell conversion * $10k incremental per year licensing = $500k in incremental revenue
You could look at what competitors are charging for the Shiny Object as a proxy.
Each of these is clearly a SWAG. It's less about the exact number. It's more about getting a quick sense of the magnitude of impact of the idea. Is it a < $10k idea? A $10k - $50k idea? A > $100k idea? Or a 7-figure opportunity?
3. Compare this to the value of current opportunities being pursued.
Next, compare the calculation above to the anticipated impact of your current top priorities.
For example:
- You're currently working on product enhancements for 20 customers collectively worth $2M ARR in renewals.
- You're working on improvements that will cut down client implementations from 12 weeks to 6 weeks, enabling us to implement 5 more clients this year, thus improving time to revenue and allowing us to recognize $1M more in revenue this year.
- You're working on high priority bug fixes and tech debt intended to reduce support costs worth $500K and "save" 5 customers accounts collectively worth $800K from churning.
- You're developing a product version that will open a new market worth $5M in incremental ARR over the next 3 years.
How does the request compare to these?
4. Reframe the request in terms of trade-offs.
“We haven't heard any customers ask for this or received any feedback from Sales that we're losing deals over this. But let's say not having Shiny Object could lose us 5 deals and having it could help us win 10 more. So that's $750k in incremental ARR. Not insignificant to be sure.
"On the other hand, this quarter we’re focused on product enhancements to prevent customers X, Y, and Z, among others, from churning – that's $800K in total account value – plus, $2M in additional enhancements tied to customer renewals. Perhaps we revisit Shiny Object in the future?"
5. Say "no" WITH them instead of "AT" them.
Approaching requests in this fashion brings transparency to the evaluation and brings the stakeholder into the process.
We can triage requests more tactfully and bring visibility into the hard choices that are often necessary in roadmap planning without devolving into emotional battles. In fact, upon hearing the trade-offs, the stakeholder may come to a "no" decision themselves.
If the requestor is an executive decision maker, and the decision is to still go ahead with the change, we've at least provided full transparency as to the business impact of making the change.
Conclusions
By reframing requests in economic terms, you're now talking the language that executives and commercial side stakeholders really care about – the language of MONEY.
Instead of coming across as "technical" or a process wonk, we can demonstrate our grasp of the business and our customers. We'll start being considered as a strategic thought partner instead of an operational blocker.
Feature requests are an opportunity for us to impress the hell out of the right people!
Your Request Triage Recipe
- Quantify options in terms of economic impact.
- Talk about money and outcomes, not process.
- Frame requests as opportunity costs and trade-offs.
- Replace AND with OR.
I hope this helps you tackle the next Shiny Object request you get.
If you want to get really serious about how to craft a roadmap that aligns company goals, stakeholders, and customer asks, consider joining the interest list for my upcoming cohort class, One Week Product Roadmap. You'll join me live to learn how I was able to transform a messy backlog of product asks into a coherent, actionable, outcome-driven product roadmap, and how you can use the same methods for your own product.
Right now I'm looking to see if a group might be interested in a beta cohort so I can perfect the material. Interested? Apply here to get on the waitlist and be the first to hear when enrollment opens.