The rep who cried bug; help product help you
"I seen the boy who cried wolf, he's a grown man now" - Tupac
We are all familiar with the classic fable “The Boy Who Cried Wolf.” It offers the sobering lesson that if you lie or exaggerate too often, people will stop believing you, even when you are telling the truth. This can have serious consequences for you and the people around you.
Unfortunately, exaggeration is common from most business functions back towards the product and engineering team. It makes sense. There are limited resources, and you must make a case on why yours is more important. That is unfair to our friends on the product and engineering teams. How can you prioritize when everything is a level-10 fire? And, if what you shared is not a level-10 fire, how are you to be trusted again? To provide great product feedback, you must shepherd the process and ensure that information is packaged to be received, understood, and prioritized. The communication breakdown in this direction usually takes one or multiple forms: fire drill feedback, recency feedback, or no evidence feedback.
Fire-drill feedback is when we skip right to ringing an emergency bell. Sometimes, it's warranted, like being unable to do your job because an API is down or having 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 needs orientation to solve problems. The heavy hyperbolic and emotional tinge usually accompanying this feedback can make it hard.
Recency feedback is when you 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 usually comes from a customer request. Salespeople live and die by each deal, and although these requests are one-offs, if they cause 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 precisely what it implies: providing feedback without supporting data. This will often look like a bug duty or feedback request without a customer link, description, or any supporting material on what happened. It's difficult to solve a problem without a whole story. In this case, rightfully so, product managers will generally de-prioritize the request as the lift of piecing together the entire picture may be too high.
The next time you give your product team feedback, keep the above in mind. Present information that is thoughtful, calm, and 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.