Dealing with Emergency Requests
I’ve written before about what product management is and what it is not. In summary, product management should focus on the needs of the market, not just a single customer—and they should focus primarily on problems, not solutions.
Yet, in real life, every product manager is pulled into emergency issues. Most product managers report at least half their time is spent chasing down and dealing with unplanned activities.
So, yes, even though it’s not truly product management, product managers have access to information—about the product, the market, the domain, and the business—that is often needed in critical sales and support scenarios. How can you better support your organization?
Address the issue
When an emergency occurs, triage the issue. What is the best resolution? Who has the information needed to respond? It could be a minor issue that requires just answering a few questions or it could be a deal-breaker that requires a new feature that threatens the roadmap.
One of the great things about an agile approach to product management is you maintain a list (backlog) of prioritized items. Each new item added to your list is prioritized with the same method. Urgent items can be added to the top of your list and given to the team when they are ready to take on more work. This way, you’re not stopping them in the middle of a story to work on a new one. They work on the new one when they are finished with the work-in-progress.
So what’s urgent? Matt LeMay uses this template to help identify the truly important items.
- What is the issue?
- Who reported this issue?
- How many customers is it affecting?
- How much revenue is tied to this issue?
- What would happen if this issue was not addressed in the next TWO WEEKS?
- What would happen if this issue was not addressed in the next SIX MONTHS?
- Who is the contact person for further discussion or resolutions?
Source: Matt LeMay, Product Management in Practice: A Real-World Guide to The Key Connective Role of the 21st Century
Now, address the root cause
Once the emergency is addressed, you also need to perform a retrospective. What caused this problem? Is there a flaw in the process or in the flow of communication? What could we do in the future to prevent this type of problem.
Example: RFP responses
I don’t know about you, but I have answered more than my fair share of RFPs. An RFP is typically a long document of questions and requirements (and often specifications) on how your company and product can address the client’s business and technical issues.
Responding to RFPs isn’t product management but, hey, somebody’s gotta do it.
In the ideal world, the sales team should respond to RFPs. But in the real world, many RFPs require answers provided by product managers and product marketing managers.
Why? In many cases, the sales team is under-staffed and under-skilled. They don’t have the technical resources with enough technical depth to answer those questions. And that’s a problem. If you have a complex product sold through a direct sales channel, you need sales engineers on the sales team.
If you don’t have adequate staffing in sales engineering, product managers fill the void.
How can we address this in the future to avoid emergencies? Here are a few ideas:
- Discuss the need for more or better sales engineers with the head of sales
- Provide more extensive training for your existing sales engineers
- Create a Frequently Asked Questions (FAQ) document with the questions typically asked in an RFP. That is, answer the questions once and re-use the answers again and again
Example: Customer feature requirement
When many of your deals seem to require one or two new features, what do you do? After all, new features often delay critical items on the roadmap.
Some sales people think that your developers are just sitting around or playing ping-pong while waiting for new features to build. They believe their job in sales is to find a customer who is willing to pay and then sell them whatever they want to buy. “After all, it’s just software (or hardware or services.)”
How to deal with this mindset? Share the roadmap and your process. It’s amazing what transparency does for you.
Many sales teams simply don’t know how your products are made. Explain how ideas come into planning and then move through the organization to the customers.
From the roadmap, your sales team sees everything that is already underway. Many sales people see that they are working against their own interests by committing to special customer requests. Be sure to update the roadmap to show any features that were delayed due to special work for individual contracts.
Help out once but then solve the real problem
In many ways, product management is about scalability. Individual product managers simply cannot help all the other teams one-by-one. We have to find ways to help them all. Work with your organizational teams to identify better ways to support them systematically.