Creating new features for your SaaS product is exciting. We hope that what we’re spending time building will be loved by everyone, but far too often it isn’t.
On this topic, have you experienced any of the following?
- After releasing a new feature, customer enthusiasm is flat
- Customers simply aren’t using that feature
- You’re convinced that you are building around customer problems
When it comes to conversations about further developing your product, customers will make a lot of feature requests. This is a good thing. It shows a demonstrated interest in your product. However, if you don’t build your product development process the right way, this can turn into an anti-pattern that jeopardizes the long-term success of your product.
In most of these instances, you’re building around customer wants instead of needs. These two are not be treated equal. However, to the untrained ear these requests can sound awfully similar. You need to know how to differentiate them from one another and prioritize only that which matters most.
If your team hasn’t done an exercise in prioritizing customer feature requests (in a while), then it’s time to revisit your strategy here. Every product is different, but a successful product development pattern should emerge at any product company – needs are prioritized for development and wants are disregarded.
You want to listen to the words coming from your customer in raw format. Let them describe their requests in great detail. Don’t interrupt them because this is a great exercise for learning. However, once they are done sharing, you need to proceed forward with a strategy that will enable you to effectively differentiate a need from a want. If you are continuously building ‘wants’ into your product, then you will begin down a path of a fatal anti-pattern in product development – you will drive your product away from your market.
Regardless of how convincing the case your customer may make – business decisions aren’t made around wants, they are made around needs only.
So what can you do to make sure these anti-patterns don’t make their way into your product organization?
Differentiate needs from wants
There’s nothing stopping a customer from coming up with lots of great ideas. However, just because something sounds like a great idea, doesn’t mean that it is (looking your way pets dot com). Instead, focus on the problems experienced by your customer that made them come up with these ideas in the first place.
If your customer can’t give you great detail about the problem that this new feature would solve, then it is likely not as high of a priority as it seems. They may ultimately come to this conclusion themselves when speaking with you. When asking for these details, it’s not uncommon for customers to share with you something along the lines of, “..well it’s not really that big of a problem for us.” or something to that extent. If you’ve gotten a response like this, then you’ve asked the right questions and saved your product company more than just time and money.
Ask for examples
Real problems have real examples. Get as specific as you can with your customer. How does that problem impact their life? Does it cause them to lose time, money or both? The more a problem negatively impacts your customer, the farther they will go to solve that problem because solving it is a critical need.
Don’t stop at one example, get as many as you can. Get examples from others throughout the organization. A large problem in one area of an organization may or may not affect other areas of the company. This will help you better understand the true scope of the problem.
What is the cost of doing nothing?
Don’t be afraid to ask this question to the customer. Let them help you understand what happens if they don’t do anything. Will their world come crashing down or will they be minorly annoyed? Those two categories mean very different things when it comes to needing that solution in your product. Make sure you know which one it is so you don’t fall victim to an anti-pattern that drives your product away from your market.