When Helping Isn't Helping
Guiding your helpful instincts to better outcomes
You want to be helpful. You see a looming problem and you jump in to prevent the problem. Soon you find that your time is consumed with preventing that problem. In the blink of an eye, you became the fixer. How do you channel your desire to help toward hitting more strategic goals?
You might be thinking you wouldn't go fix a problem unless you had to. It can be very seductive to be a hero and fix that nagging issue in your product or organization. Let's think about being helpful without becoming the fixer!
Three steps to helping and being productive:
Know your objectives and adjust when you tackle a new problem
Evaluate the costs of your help
Look at multiple perspectives and then decide about helping
This leads to a thinking loop and helps you stay on track.
Know Your Objectives Well
If you are a little fuzzy on your performance goals then you are tempted to take on many problems in your daily work. When you understand what you need to do long term, then you can assess daily problems in the long-term context.
Suppose you are a product manager on a software appliance in the cloud that tracks cloud spending for your customers. In customer conversations, you learn that customers are getting incorrect invoices and they are not paying the monthly fees for your appliance. You check with your accounting team and learn the invoicing problem started with the last software release. Realizing your revenue is going to be impacted, should you continue investigating the problem?
As a product manager, your prime objective is to prioritize features and anticipate your customers’ needs. While you have the ability to call meetings and escalate the issue, how does the incorrect invoicing relate to your prime objective? Right - it doesn't relate to your objectives!
A better approach is to submit a bug report with screenshots of the incorrect invoices. This is more helpful than disrupting work with an escalation meeting!
Evaluate the Costs of Helping
Ominous problems look easy to solve but there can be hidden costs. Examples of hidden costs are a lack of tools or knowledge to handle the problem. Sometimes the easy fix has unintended consequences.
For example, you are a product manager on a software appliance in the cloud and your product uses a good bit of cloud storage. A customer points out that the storage capacity utilization in your dashboard is slightly different from the utilization when using your API. You decide there must be one line of code that needs fixing on the dashboard. You start phoning your favorite software leaders to ask about fixing that line of code. Next multiple software people start examining the code. Then testing tries to reproduce the problem on the dashboard. After many hours of investigation, the API developers realize the developer’s kit has mislabeled the storage utilization field. The API is actually reporting on the utilization trend.
In this case, the better approach would be submitting a bug report with the API output and the dashboard output along with the description from the documentation. The API team would handle the bug report without the hidden costs of problem reproduction and code reviews.
As a product manager, you can help best by getting problems to the experts. When you feel compelled to help with something outside our expertise area, think about the hidden costs first.
Look at the Situation from Multiple Perspectives
In the heat of the moment when a problem comes up, you normally would just solve the problem. Like your whole team, you are ready and willing to help. Sometimes, though, helping isn't helping. How can you avoid being too helpful and causing more problems? Take time to look at the problem from other perspectives.
As a product leader, you have the benefit of working with many different teams. And you have relationships with many leaders in the organization. The next time a problem arises, you have teams that can help you see their perspective.
Suppose your customers report they never heard about the features in the newest release of your product. This is especially disappointing since the last release added administration policies that many customers had requested. Your engineering team added these policies at the cost of many other key features. From your perspective, it looks like marketing and sales are the cause of the customers not knowing.
Instead of blaming marketing and sales, you decide to look at the issue from other perspectives. You put yourself into the role of marketing for a minute and examine the problem from their perspective. As you think like your marketing team, you recall the overall marketing message is aimed at getting new customers. You realize there is no room in the messaging for customer-requested features like admin policies.
Next, you look at the problem from the perspective of sales. Surely the sales team heard the customers asking for admin policies! You think about the typical salesperson that is incented to make new sales. Then you realize there was no material developed for salespeople to use with their existing customers.
Now that you see the issue from another perspective, a simple solution is clear. Using the release notes from your last release, there is documentation on the new admin policies. Your marketing team is happy to notify customers about the new feature since the release notes have it covered.
Conclusion
Pausing to think about the impacts of helping with a problem can keep you focused on your objectives, avoid extra costs and prevent needless frustration. The three steps to direct your helpful instincts toward better outcomes are:
Know your goals well
Watch for hidden costs
Look at other perspectives
Using a thinking loop leads to better solutions.