Many life skills are a mixture of art and science. Two of those in my life have been live audio production engineering and, more recently, software product management.
From the time I was in 6th grade until well through college, if there was an opening behind a sound mixer, I was trying to find out how to fill that seat. There was no venue too small, band, too giant, or system too hodge-podge; I was glad to have the opportunity to manage the audio product. The live audio engineer is the closest thing a concert has to a conductor in a symphony. Both take multiple signals and inputs and coordinate them into one cohesive and entertaining sound picture.
The high-level version of audio engineering is very scientific. There are ranges of sound wavelengths that you want to accentuate or deaden for specific instruments. There are measurements for the amount of pressure people can withstand at each of those frequencies, called decibels. There are straightforward ways to layer sound, set up speakers, ensure coverage, and more. But the artistry is between the guidelines. Strictly how the snare drum pops, the kick drum thuds, the cymbals crash, the lead guitar screams, and the bass bumps are left up to the audio engineer.
The fine line between artistry and science is where many complaints are levied and misunderstood. Anyone who has run audio in a venue where they might interface directly with patrons, a church, a school, or a small music festival, has heard the same feedback. “It’s too loud.” There are a few things to remember when receiving this feedback as an audio engineer.
- Their feedback and experience are valid
- Their vocabulary is limited in how to express audio
- They are sharing their experience, not critiquing your work
“It’s too loud” is almost always synonymous with “the sound I am hearing is painful” and rarely a statement of the overall volume. Instead of scoffing or breaking out an SPL meter to show the current decibel reading, which will undoubtedly mean nothing, the audio engineer can find out more by asking questions. Where is this patron listening from? What precisely are they noticing? Is there a specific time when it’s too loud?
Our ears are attuned differently, and sound in a space is far from uniform. These questions can go from an unsolvable problem, as the volume rarely fixes it without a massive quality dip, and turn into more minor adjustments. The lesson may be that the guitar is squealing toward the front of the house or the lower speakers in an array are too loud. Multiple fine adjustments can reduce the “too loud” complaint while sometimes increasing the volume.
The further I get into my product management career, the more similarities I see with my experiences with folks saying something is “too loud.” Users of our product rarely have the comprehensive vocabulary we have for our product, and we need to be willing to dig deeper into what they are asking. There are three patterns I have seen with user feedback that can result in building the wrong thing if not asking the right question.
If all you have is a hammer
The most common is when a customer asks for a specific solution in a part of the existing product. You must ask to dig into the problem to determine whether this is a limited use case but a broader version is already in the plan. It’s essential to dig deeper into the questions and find the problem the user is experiencing rather than just listening and implementing their solution.
During my time at Crossbeam, a standard version of this was that everyone wanted more report functionality. Reports were the only way users could, on their own, dynamically filter their data with numerous fields and partners. After talking to many customers who wanted new features on reports, we understood an entirely new concept, profiles.
Allowing users to create templated versions of what they wanted to filter for exports was much more valuable than bolting on a complex system of filters and sorts for their reports. Speaking of solutions.
Customers who want to see their ideas in the product
Anyone who’s worked on the product has seen it. Customers want to avoid digging deeper and only want to discuss their specific solution. There are many underlying reasons here, but the pattern I notice is that they want to see their idea make it into the product. As we learned before, the underlying question is why they want to.
In my experience, customers feel unheard and undervalued in the feedback loop. An idea being in the product is equivalent to being heard in the customer’s mind, and failing to see it in the product reinforces the notion that they aren’t a part of the process. This customer experience is why communication is essential for product managers. You want to ensure the customer is heard and understood and ultimately loop back when newly delivered features solve those underlying problems. These trust-building exercises will help customers to be more willing to describe their problems and less focused on getting their solution in the product.
They don’t know
Ultimately, this is the most common. Customers have feedback but need to know what it is and how to describe it. It’s like when you taste something that you cooked and aren’t sure what you left out, but you know it’s just not right.
This feedback is frustrating for product folks but even more frustrating for the customer, who knows there is a problem and can’t describe it.
In these instances, I like to schedule a time to walk through what they are discussing and go in-depth. Let’s talk about each step and see where the frustration starts so we can develop some language around it. Ultimately, the customer doesn’t have to have the right words so long as the product manager here’s the correct feedback.
In all of this, and my experiences as a product manager, I like to try and remember that sometimes “too loud” means “painful,” and we have to figure out the underlying problem. If we can fix those customers’ pain points, they’ll be happier and trust our product leadership as we move forward.