Providing Product FeedbackTommy McNulty
There are few things in business as beautiful as a sales & product team working in lockstep. Information flows from the frontline seamlessly, and customer needs are met. Unfortunately, this isn’t the status quo at most companies, as the two teams often suffer from communication breakdowns. Information is a two-way street, and there are critical areas where salespeople can improve in how they present feedback.
Whenever passing information from one to another, we have to consider the receiving end & their ability to process it. In the sales world, bugs or lack of functionality can lead to severe outcomes like a lost commission or poor customer experience. In turn, the feedback provided can be severe and difficult to receive. As a salesperson, you may have been experiencing this problem and its severity and have a clear, visceral understanding of why it needs to be fixed. However, when you provide this feedback to a product manager, it may be the first time they hear about it and therefore require time and information to understand the potential impact. To provide great feedback, sales must shepherd the process and ensure that information is packaged so that it can be received and understood, understanding that it could take time for a resolution. The communication breakdown in this direction usually takes one or multiple of these forms: fire-drill feedback, recency feedback, or no-evidence feedback.
Fire-drill feedback is when we skip right to ringing an emergency bell. In some instances, it's warranted, like being unable to do your job because an API is down or having all customers locked out of their accounts. However, crises like these are usually few and far between, and in most situations, problems feel more urgent than they are. This manifests for a product manager as an attempt to decipher the problem while trying to solve it simultaneously. To use an analogy, imagine waking someone up in the middle of the night whose house is on fire, but instead of asking them to escape, you ask them to figure out where the fire started, how to put it out, and how to save the household members - tough gig! The stakes are not nearly as high in business, but everyone requires orientation to solve a problem. The heavy hyperbolic and emotional tinge that usually accompanies this feedback can make it more difficult.
Recency feedback is when we react to a recent, isolated incident to prove a larger hypothesis that something is broken or needs updating. This frequently happens on sales floors and will usually come from a customer request. Salespeople live and die by each deal, and although these requests are one-off and non-recurring, if they are the cause of a lost deal, it will create the feeling that the issue at hand is the most important thing for a company to solve. In this case, product managers have to spend time trying to recreate the problem and research whether it's something that, if solved, solves for everyone or just for one customer or sales rep.
No-evidence feedback is exactly what it implies, providing feedback without any supporting data. This will often look like a bug duty or feedback request that comes in without a customer link, description, or any supporting material on what happened. It's difficult to solve a problem without a full story. In this case, rightfully so, product managers will generally de-prioritize the request as the lift of piecing together the full picture may be too high.
The next time you’re giving feedback to your product team, keep the above in mind. Present information that is thoughtful, calm, & collected with evidence on what happened and the impact a fix might have. You don’t want to be known as the salesperson who cried bug.