A customer asked me for a feature I really didn't want to build.
At first, I almost said yes immediately.
He's been using my product for a few months, pays every month, and is one of the few customers who regularly sends me feedback. The kind of customer you don't want to disappoint when you're still trying to grow.
The feature he wanted wasn't unreasonable either.
It would make his workflow easier, and I could probably build the first version in two or three days.
So I opened my code editor and started thinking about how I'd implement it.
Then I stopped.
Because I realized I wasn't just building one feature.
I'd need to add a new setting, change part of the existing workflow, handle a few edge cases, and eventually explain to other users why this option existed.
And honestly, I wasn't convinced this was the direction I wanted the product to go.
I spent the rest of the evening going back and forth.
One part of me was saying, "He's paying you. Just build it."
The other part was asking, "What happens when the next customer asks for something completely different?"
The following day, I didn't reject the request.
Instead, I asked him to show me exactly how he was working around the problem.
That conversation changed my understanding of what he needed.
He wasn't really asking for the feature itself. He was trying to solve a much simpler problem, and there was another way I could potentially handle it without introducing the whole workflow I had imagined.
We haven't settled on the final solution yet, but I'm glad I didn't rush into building what he asked for.
I'm learning that customer feedback isn't always a product specification.
Sometimes the customer knows the problem better than you do, but the feature they're requesting is just the solution they've already imagined.
How do you handle this in your own product?
Have you ever said no to a paying customer's feature request and later realized you made the right decision?
Sign in to join the discussion
No comments yet. Start the conversation!