The #1 job of a Product Manager is listening to their customers and being their voice internally to help drive internal priorities. But what happens if the customer wants a feature done in a certain way or offers specific product advice, that you’re unsure will scale?
This is a question I’ve been grappling with throughout my career, and though I don’t have a silver bullet to solve this problem, I’ve devised a few strategies to help me better understand the why’s of customer feedback and create a process on how I work through customer inputs.
Customers are intelligent — they are inherent subject matter experts in their line of work, and have obviously put some thought into what they need from you. It’s important to remember that they’re offering feedback and solutions because they see a void within our organization they want to fill, to help us help them. It’s important for us to acknowledge that and help them through it.
As a Product Manager, it’s our job to be the voice of the customer, and it’s only fair we take their requests and ideas into consideration. However there are often situations where a customer wants something added, that we make happen, only to discover that it can’t scale across other customers. There’s a few factors that cause this, and a few methods I’ve found helpful to keep things Product focused.
Outsourced Ideation
This happens fairly regularly — PMs are busy people, and often we don’t have the time to thoroughly research every feature request. Customers on the other hand have plenty of time to think about the drawbacks of our product and often present compelling cases on features to be added. This makes our lives easier and we duly add it to our work boards. The catch here is that the customer is thinking of the solution that will fit their business, not your customers. What we’ve effectively done is outsource our job to our customer. This works fine for them and us right now, but can cause issues later when other customers want a similar outcome, but have different processes. Arguing against this one is really challenging when you only have one customer request, but the stakes are a lot higher with one data point.
There’s a few ways to address this, the obvious one is to conduct our own due diligence on the feature, though this might be impractical given our workload. The other option is to send out “feature feedback”, where customers can see what’s being proposed and discuss it. The argument against this is customers often don’t engage, or try change the solution to their narrative. Finally, you could also try looking at what competitors or the wider Industry has done — this is perfect for some markets, but the biggest risks are it dilutes your competitive advantage, as your feature is basically identical to the next one.
The Loudest Customer
This is another very common situation, where the customer is loud enough (monetarily or feedback wise), that the Product Team is forced to act. In the pressure of the situation, it can be tempting to just build what the customer wants, and prevent more heat on your back (coming both internally and externally at this point).
It’s important to recognise that loud doesn’t always equal right, and it’s not possible to make every customer happy, no matter how loud they are, or how much revenue they contribute. It’s important to acknowledge baseline revenue and customer success, but it’s our obligation to ensure the products we build fit in with our company strategy, scale well, and work across a range of our customers.
Tackling this requires a bit of finesse, and I’ve found that it’s often quite constructive to push back to the customer and work with them to meet on even ground — customers get it when you explain your reasoning in plain words, or the compromises you’re making to suit others, they know you’re a SaaS company, they just want to be let down lightly when they can’t get what they want exactly.
An 1% Feature
The 1% feature is a term I’ve coined to describe customer requests that add a negligible amount of work to your team to build, but is completely custom for them. This is an easy trap to fall into, because it’s seen as an “easy win”.
I often find these 1% Features to be the most dangerous, because we tend to be more callous about them and don’t think too much about the future. Unfortunately chances are another customer will want something similar later on, and we’ll be tasked to re architect, or extend the feature to suit them.
This may not be a bad thing however, and though it’s not ideal, the initial sunk cost is negligible, so starting from scratch again isn’t a big deal — kind of like temporary footpaths while the good one gets built.
Customer Processes
Every customer has their own unique business processes, and everyone claims theirs is best practice. They’re mostly right — it is for them, and that’s why they’re successful. The bad news other companies just like them are equally successful and probably do something totally different. Imagine both of them are your customers, want the same end goal, but propose different ways of accomplishing it!
In the case of two roads, one goal, I like to propose both solutions to both customers and see how they come back, it’s often pleasantly surprising when both agree on one thing, amusing when both swap sides, and frustrating when both stand their ground.
Ultimately it’s usually a losing battle to try change a customer process, and it’s often better to come with up with a scalable technology pattern that’s extensible and can go down different paths to arrive at the same outcome.
Final Notes
Finally, it’s important to remember that customers giving feedback and voicing their ideas on how the product should work is a great thing — it means they’re engaged, committed, and have faith that we’ll improve their product, and it’s a responsibility we need to truly accomplish.