Thank you to our affiliates who help support this newsletter:
The emergency request.
A special type of request in the form of:
“We MUST do this Super Important, Cannot Be Delayed, Drop Everything Else thing and we must do it NOW!”
It can come from anywhere.
Sales. Support. Some other part of the organization. Your boss. An executive. The CEO.
It’s understandable and normal to feel pressure in these moments.
On the one hand, there’s pressure to respond with an immediate, “yes.”
On top of that, you can feel pressure to react in the same excitable way as the requestor. Because not doing so can be mistakenly interpreted as being unsympathetic and not fully understanding the “urgency” of the situation.
I once received this exact feedback.
It was B.S. But I had to prove with tangible evidence of how I had a track record of responding to these with urgency.
It was my calm demeanor that rubbed some of the more emotionally reactive people the wrong way. Go figure.
On the other hand, in the back of your mind, you know how engineering is going to respond.
Unless it’s a true emergency, they’re going to see it as distracting and disruptive.
Worse, they’ll be annoyed with you for not doing a good job deflecting it.
On top of all this, if the “emergency” is coming from an executive or the CEO, it can feel like your job performance is on the line.
Where Most PMs Fail
Most product managers respond procedurally, tactically, or emotionally.
None work.
They bargain with Engineering. (“I know it’s disruptive. But they’re breathing down my neck. Can I get an estimate for this just this one time?”)
They get tactical: Get new estimates for disrupted in-flight projects, share that back thinking this data may dissuade the requestor. (It won’t.)
They push back the wrong way. “Is it really an emergency?” (An emotional debate that can’t be won.)
They flame post on LinkedIn, “They don’t get it!”, or “Too many shifting priorities!” (Fun. But fruitless.)
The problem with responding in these ways is they make us come across as non-collaborative, non-responsive, and not understanding the business.
It reinforces the stereotype that product managers are basically just delivery managers. That PMs are too technically focused, and that they don’t actually understand customers.
And it can have severe repercussions on:
Your reputation.
Your credibility.
And your job progression.
So what’s the solution?
What Constitutes a True Emergency
First, let’s level on what is a true emergency.
Here are some examples of minor vs. major emergency situations:
A true major emergency will almost always justify revamping current product development efforts, if not your roadmap entirely.
If the system is going down completely or the company is facing significant fines as a result of non-compliance, that’s a true emergency.
It’s also important to recognize that an earlier stage product, like as a startup or a new product innovation, is likely to have more frequent true emergencies.
This is because you’re still trying to figure out the right solution for your target market and performance issues are not uncommon with an early stage product.
In these case, you just need to figure out a way to prioritize it and assess the downstream impact on anything currently in-flight and on the roadmap.
It’s the not-so-major or minor ones that require careful handling.
How do you do that?
Respect the Emergency, Respond in Economic Terms
Here are 4 plays I’ve learned on how to deal with “emergency” requests.
The cost of delay if we don’t do this.
The opportunity cost of trading this off.
Risks and mitigations.
Dependencies.
Let’s discuss each.
1. Cost of Delay
The cost of delay is the economic impact of NOT doing a thing or in delaying doing it.
Some examples of economic impact:
Potential lost revenue or bookings — e.g., loss of a major customer or set of customers, inability to win new business, user churn.
Delay in revenue recognition — e.g., a client won’t go live with our product unless an important feature is made available.
Impact to cost of goods sold, cost of service, or production costs.
Increase in customer support costs.
Increase in product costs because a key vendor or 3rd party is dramatically increasing their pricing.
Cost of solving the problem later — e.g., if necessary resources will get more expensive over time.
Contract breach.
Regulatory fines.
Cost of delay forces us to ask two important questions:
What would it be worth to solve this right now?
How much would it cost us if we solved it later?
Cost of delay essentially combines Value with Urgency and helps in assessing the opportunity cost of delaying a thing.
Which brings us to..
2. Opportunity Cost
This compares the benefit of solving the “emergency” now against the impact of delaying anything you already have in flight or have planned in the short-term.
In other words, it compares the trade-off of what gets impacted.
Let’s take an example.
Let’s say a $500k ARR customer is making a lot of noise about a pet feature they’d like.
$500K in annual recurring revenue (ARR) is certainly not an insignificant amount. However:
That one customer represents less than 1% of overall revenue
Their contract isn’t up for renewal for over 2 years
They’re the only ones asking for this feature
In contrast, what you're working on this quarter is worth $5M in net benefit.
In this case, it seems pretty straightforward to make a case that you either won’t do this customer’s feature or perhaps get to it in the next quarter.
Now, let’s take the same situation, but this time the customer is up for renewal within the year and there is legitimate high risk they won't renew.
Furthermore, even though the customer is only 1% of total revenue, they’re a “reference customer” — losing them could have a halo effect on the rest of the business and winning future prospective customers.
I can definitely see the CEO applying enormous pressure to satisfy this customer sooner vs. later.
In this case, the opportunity cost of losing this customer may feel significant enough to bite the bullet and prioritize satisfying this request now or at least ASAP.
3. Risks and Mitigations
This play is pretty straightforward.
What are the risks of prioritizing this “emergency” over existing plans?
What are the risks of not prioritizing it?
What could be contingencies and mitigations against these risks?
4. Dependencies
If you drop a thing to accommodate this “emergency,” does it impact anything else?
Does anything else need to be dropped or get delayed? And what’s the impact of that?
Alternatively, if you don’t prioritize solving for the request now, are there downstream effects and dependencies you need to be aware of? What are the impacts of those?
Putting It All Together
Not every emergency request requires all 4 plays. Some will. Have them in your playbook so you can pull them out when needed.
Then, as you’ve heard me say many times in this newsletter, respond with a money story:
For example:
“Big Customer Z is $450K in ARR, so I get the importance here. And the change does seem relatively small – although, I would need to verify that with Engineering...
“As you may recall, we’re currently working on Dog, Cat, and Mouse, which are meant to cut our long customer implementation cycles by half, enabling us to implement 5 more clients this year and allowing us to recognize $5M more per year in top-line revenue.
“So even if we did make this change, it would jeopardize Release Elephant by, I’m guessing, 3-4 weeks (again, to be verified with Engineering), which represents a $1M delay in recognizing that top-line revenue this year.
“With due respect to the customer sensitivity here, I would recommend we look to implement this change after Release Elephant.”
Note how underlying all this is having a clear understanding of the value of your current roadmap.
If you don’t know the anticipated outcomes of what’s currently on your roadmap, it’s much harder to make these arguments.
Remember:
Politely respect the “emergency.” That makes them feel heard.
Recognize the situation. That helps deflate the emotion.
Respond with a money story — an economic argument.
Because if it doesn’t have a currency symbol, odds are it will get done anyway.
And pretty soon your roadmap will be a wreck.
That’s it for today.
Have a joyful week, and, if you can, make it joyful for someone else too.
cheers,
shardul
Here are 4 ways I can help you today:
Strategy Design Workshop: Transform scattered priorities into clear, actionable direction. I’ll facilitate your team through a customized workshop to align stakeholders and create strategies that actually get executed instead of forgotten. Book a call.
Product Management Audit: Get a clear picture of what’s working and what’s holding your team back. Through a systematic analysis, I’ll evaluate your strategy, processes, roles, metrics, and culture. You’ll walk away a practical set of findings and actionable recommendations to strengthen your product organization. Book a call.
Corporate Training: Elevate your entire product organization. I’ll teach your team how to think and act strategically, craft outcome-driven roadmaps, and dramatically improve how they deliver measurable results that matter to your business. Book a call.
Improv Based Team Building Workshop: Boost creativity, trust, and collaboration through improv. Your team will problem-solve faster and work better together. Book a call.
Shardul Mehta
I ❤️ product managers.