One thing I’ve learned from building products is that customers are terrible at telling you what to build. You speak to them. They start pitching your ideas for a new feature. Something that does X would be super useful, please build it.
So we all start to think about building it.
The risk here is that we spend two sprints building the thing, only for them not to use it. It does exactly what they wanted it to, they use it once or twice, and then they never touch it again.
You go through this cycle a few times and then you start resenting customer feedback.
You try ignoring what users say entirely and just build what you think needs to be built. Either you build it off of raw intuition, or maybe you’re copying a competitor. Either way, the results are hit and miss. Not much better than listening to customers and building features they ask for.
The thing to understand is that customers are terrible at designing solutions. The customer owns the problem. It’s our job to design the solution.
Things go sideways when you don’t understand who owns what. Listening to customers and building stuff they want is asking your users for the solution. Wrong.
Building a roadmap off of raw intuition or copying your competitors is assuming you know what the problem is. Wrong again.
Listening to customers is only useful if you manage to uncover why they are asking for something. They want X because they think X is a good solution to the problem they’re having. This may or may not be true, it usually isn’t. What important is that you understand what the underlying problem is.
If you deliver X and it doesn’t solve the underlying problem then people won’t care about it. You can deliver something completely different but if it deals with the issue then they’re going to love it.
For some reason, we all like to talk about solutions. I’m not blaming customers here, people working on product teams make this mistake all the time as well. There is just some inherent bias here and you have to actively work against it.
Talking about solutions is important. But only once you have a firm grasp of the problem. Once you understand the problem then you have to have a conversation about the best way to solve that problem. This is when you rely on intuition, and steal from competitors, and get everyone in the room to brainstorm.
So the next time a customer asks for a feature, make sure you figure out what the underlying problem is. What are they trying to solve with this fancy new feature they have come up with?
Half the time, they’re talking about a problem that you have already solved with a completely different feature.
A lot of times, the problems are not worth solving, Yes we could make this one customer happy, but it’s a minor niggle, and fixing it might mean changing something that pisses 30 other people off.
When it is something worth solving, being able to group lots of different bits of feedback by the underlying problem gives you a clear understanding of the boundaries of the problem. A well-defined boundary to the problem makes it easier to come up with a simple solution that addresses a whole cluster of feedback and complaints by adequately addressing the underlying problem.