When it comes to product development, the customer is seldom right.
One of the hardest things to action when building a SaaS software product from the ground up is handling new feature requests from your customers. If you are forging new ground with a brand new product and are trying to find product market fit; this is especially true. No one has walked this path before, and you are left scratching your head as to whether what one customer asks for is shared amongst others, or if it is simply consulting work for just one customer.
The easy path to travel is taking any early feedback from a customer and actioning that directly, particularly if you haven’t many customers onboard. Your natural instinct is to treat support requests as quickly as possible .That’s what every startup guide tells us right? Iterate quickly based on customer feedback. Fuck that. Here be dragons. A world of pain during testing and a settings page as long as your arm awaits that particular approach unless you take direct early customer feedback with a pinch of cynical salt. Iterate quickly with features refined from qualified customer feedback is the more sensible advice. Side note — saying no is ok too, particularly if you don’t want your product to go down a particular road.
I’ll not trot out some tired, ill-quoted Henry Ford faster horses quote to support my argument but I definitely err on the side of visionary product development as opposed to always giving customers what they ask for. This comes with experience as well as the painful lesson of over-engineering your product for one customer at a time and then having to develop something that they can all share between them. Often you need to step back and think deeper. Is this obviously shared by my other customers, or will be? Is there an underlying feature buried in here that needs dug out with additional customer follow up?
Technical founders are often poor at digging into the details through phone calls and customer interviews before implementing new features. Feature requests offer the perfect opportunity to talk directly to your customers and talking to your customers is a gold mine of opportunity.
It is important to develop the ability to look beyond the original request, find the true root of the problem the customer has found with your product and try and develop something which has both meaning for you overall product vision. In turn you will solve the problem better than they originally suggested.
For example, I’m sure you’ve had customers ask for additional interface elements. A new button here, a filter option there. It’s common for them to think in terms of buttons and actions and in terms of placing it within the interface that is sitting in front of them — you have to go deeper to understand the underlying business value for them ‘why’ this is necessary, and indeed if that interface destination is the best place to solve the problem inside your product. 9 times out of 10, there’s a better way to achieve the customers goals without actioning their feedback verbatim.
If they ask for an additional text field to describe a product better, you have to ask why it is important for their business to make that distinction? Are they trying to reach a new audience with your product for example? If they ask for additional filters in a search, should you be building another page specifically for that customer segment? If they complain that a page needs information removed, do they need more filtering options or is there a sensitivity with the data? You get the picture. For technical founders particularly when faced with talking to customers or writing code most will chose the path most trodden. Writing code. But talk you must. Your product’s survival depends upon it.
