“If I had asked people what they wanted, they would have said a faster horse.”
This quote is very well known. It implies that people don’t necessarily know what they want when they ask for it.
Building something based on people who don’t know what they want is no bueno.
This is why many people in SaaS are hesitant to use customer feedback to inform their roadmap.
We’ve heard this saying used in a context that hits home for us specifically:
The concern here specifically isn’t these tools allowing you to get feedback. Getting feedback is always good.
The concern is that they allow you to get feedback and let a whole community chime in on it.
If you gather feedback privately, you can just tuck it away.
Afterwards, you can safely pick and choose in your own private space, and nobody will know any better.
It’s very different if you collect feedback publicly. What if someone asks for a faster horse, and everyone agrees with it?
Then you’re going to have to build it, right?
It’s about problems, not solutions
Henry Ford was right—you should definitely never blindly build what your users ask for.
Customer feedback in its most basic form is absolutely not enough for you to make good, informed product decisions.
Here’s a very important thing to remember:
What a lot of people do when they give feedback is suggest solutions.
You’re not going to know whether this “solution” really solves a problem until you identify the problem itself.
So, after gathering feedback in its raw form, your job is to jump in and translate these suggested solutions into problems.
This is why what customers ask for is not necessarily what you need to do.
Here’s an example:
Customer: I’m going to need a faster horse.
You: Can you tell me why you need a faster horse?
Customer: Because I need to get from point A to B quicker.
You: OK, I understand that problem. How about a Ford? It’ll get you from point A to B much quicker than a really fast horse would.
If you just left it at “I’m going to need a faster horse”, and didn’t ask “why?”, you would definitely be damaging your business.
God knows what you’d have to do to that poor horse to make it faster, too.
Asking the “why?” will not only help you determine what the real solutions are, but also see how many people agree with the actual problem.
Prioritization will be much clearer and produce better results.
Some suggested solutions are very clear and straightforward, and don’t need much “translating”.
For example, if people ask for a Help Scout integration, they probably want a Help Scout integration.
You still need to dig into why they want the integration and how they want it to work, but otherwise—it’s obvious enough.
Communication and discussions are key
Now that we’ve established that people asking for something doesn’t mean you have to immediately build it, let’s get into the “how”.
After getting your feedback all in one, organized place, making productive decisions is all about communication.
What tools like Canny allow you to do is very far from just being asked for a horse and making a horse.
It’s a three step process:
1. Gather and organize feedback in one place: to understand what your users’ problems are
2. Have a discussion over the feedback with your community: to understand how these problems can be solved
3. Prioritize your roadmap based on said discussion: to inform users that you’re solving their problems
Where it really comes down to solving the issue of the faster horse is the second step—discussion.
You’re able to:
- Be a part of the discussion, including asking questions
- Get your user community involved in these discussions and receive even more information about why people want what they want
Here are some examples of simple questions to ask for clarification:
- Why do you want X?
- What are you trying to achieve with X?
- How do you do Z today?
- How often do you do Z?
- Can you give me a specific example?
- Would Y workaround work?
The direct communication and discussion ability should demolish all concerns about being asked for a “faster horse”.
People can ask for it if they want. However, you have complete freedom to do any of the following:
- Build the faster horse
- Find the real problem behind it and build a solution for that
- Not prioritize the real problem because it’s not beneficial for other customers
The final choice is always under your control.
Feedback without context isn’t useful. If you create context by getting to the root issue, it’s a gold mine for product prioritization.
Don’t be scared of the faster horse
We understand that opening up feedback in a tool like Canny can be scary.
Naturally, you’re worried about what people will be asking for and whether you can provide it or not.
However, remember—your customer requests are just that—requests.
User feedback uncovers problems, not solutions.
If you get into the habit of analyzing raw feedback the way that it’s supposed to be, you’ll reveal all the actual issues. You’ll be able to solve them in a productive, informed way.
And, as an added bonus, your users will be delighted to be a part of the conversation.