The Sky is Falling
Read on my website / Read time: 5 minutes
Thank you to our sponsors who keep this newsletter free for the reader:
Learn AI: Expert ChatGPT Prompt Guide
Join 650k+ people from companies like Apple, OpenAI, NASA at the Rundown.ai to get free access to our expert ChatGPT prompt guide.
|
The emergency request.
This is 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, or even the CEO.
Emergency requests can place us under enormous pressure. From both sides.
On the one hand, there's pressure on us to respond with an immediate, "yes".
Not only that, we can feel pressure to react in the same excitable way as the requestor. Not doing so can make us come across as unsympathetic and not fully understanding the urgency of the situation.
(I once received this exact feedback. It was BS, and I had to prove with tangible examples 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 our minds, we know how our engineering team is going to respond: we know they're going to to hate it.
Unless it's a true emergency, they're going to see it as distracting, disruptive, and disorderly.
And they'll be annoyed with us at not doing a good job deflecting it.
(Also feedback I've received in the past. The comment was: "There are too many fires all the time. Product Management needs to do a better job prioritizing the work." Which led senior management to think this was a Product Management problem.)
On top of all this, if the "emergency" is coming from an executive, our boss, or the CEO, it can feel like our job performance is on the line.
Most product managers respond procedurally, tactically, or emotionally. None work.
- They bargain with Engineering. ("I know it's disruptive. But <requestor> is 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 persuade the requestor otherwise. (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 they're more technically focused, and that they don't actually understand customers.
And it can have severe repercussions on:
- Our reputation.
- Our credibility.
- Our job progression.
- Our career growth.
So what's the solution?
Respect the emergency and respond in economic terms.
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 our roadmap entirely. We 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.
So, 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.
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...
Opportunity Cost.
This compares the benefit of solving the "emergency" now against the impact of delaying anything we already have in flight or have planned in the short-term by prioritizing solving the "emergency" ahead of it.
In other words, it compares the trade-off of what gets impacted.
Let's take some examples.
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, they're the only ones asking for this feature, and their contract isn't up for renewal for over 2 years.
In contrast, what we're working on this quarter on our roadmap is worth $5M in net benefit. It seems pretty straightforward to make a case that we either won't do this feature or perhaps get to it in the next quarter.
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. 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.
Risks and Mitigations.
This play is pretty straightforward.
- What are the risks of prioritizing this "emergency" risks over existing plans?
- What are the risks of not prioritizing it?
- What could be contingencies and mitigations against these risks?
Dependencies.
If we 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 don't prioritize solving for the request now, are there downstream effects and dependencies we need to be aware of? What is the impacts of those?
Putting it all together.
Not every emergency request requires all 4 plays. Some will require all 4. Have them in your playbook so you can pull them out when needed.
Then, when responding, as you've heard me say many times in this newsletter, articulate in business outcome terms:
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 our current roadmap. If we don't know the anticipated outcomes of what's currently on our roadmap, it's much harder to make these arguments.
It's also important for us to acknowledge that sometimes there are true emergencies. For example, the system going down completely or the company facing significant fines as a result of non-compliance.
It's also important for us to acknowledge that an earlier stage product - such as a startup or a new product innovation - is likely to have more frequent true emergencies. This is because we're still trying to figure out the right solution for our target market and performance issues are not uncommon with an early stage product.
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.
