Most software businesses receive plenty of feature requests through conversations with account managers, customer support tickets, and even social media. While most feature requests originate from a real pain point, they may be half-baked solutions to the real problem. Therefore, it's essential to understand the problem before jumping to a solution.
As Rob Fitzpatrick wrote in The Mom Test, "You aren't allowed to tell [customers] what their problem is, and in return, they aren't allowed to tell you what to build. They own the problem, you own the solution."
Let's take a look at what's wrong with many feature requests, why customer support tells a better story, and how to create the right feedback loop to keep your product on track.
Customer support provides the best signal to guide your next features. Click To TweetWhat's Wrong with Feature Requests?
Henry Ford once said, "if I had asked people what they wanted, they would have said faster horses."
Customer feature requests arise from a real problem or frustration, but they're not always the best solution. For example, Basecamp received numerous requests for Gantt charts to visualize projects. However, Basecamp's business model is to simplify project management. As a result, customers would be better off learning its approach.
Other problems with feature requests include:
- No context. The customer may suggest a feature that's not really important for them (e.g., not a serious ask).
- No specifics. Feature requests may not be specific enough to understand the real problem facing the customer.
- Bad fit. Feature requests may not fit with the product vision, like the Basecamp example above.
- Too niche. A feature request might target a niche use case that doesn't apply to other customers.
- Better solutions. There may be an existing solution or workaround to solve the customer's problem.
In short, many feature requests are solutions that have an ambiguous or non-existent problem. Rather than accepting them at face value, product teams should try to understand the underlying problems facing a customer before thinking about a solution. In many cases, the best solution doesn't look anything like the original feature request.
Customer Support Tells a Better Story
Product managers should have regular conversations with customers, but customer support should always have the most contact with customers. Customer support fields questions and listens to complaints every day, trying to solve problems and close tickets as quickly as possible. As a result, they have the most knowledge about common pain points and challenges.
Unfortunately, many customer support teams are focused on closing tickets as quickly as possible rather than understanding customer problems. By shifting the mindset from solving to understanding, you can capture common problems and come up with creative solutions. For instance, you try the “five whys” technique to narrow down problems before solving them.
In addition, customer support teams should follow up with customers to collect feedback. For instance, if a workaround fixed the problem, the team might want to follow up to ask if the workaround was a satisfactory resolution or if it’s still inconvenient. If there’s a common problem area, customer surveys can also help identify if many users experience the same frustration.
Many companies separate customer support and software development after reaching a certain size. As a result, developers have less context into how customers actually use their software and what problems they face with it. Product managers attempt to translate feedback into feature requests, but there’s often a lot lost in translation.
Creating Tighter Feedback Loops
A better approach is building customer support into development workflows by encouraging developers to take on some customer support shifts or involving customer support teams in product-level discussions. By involving everyone in customer support, you can build a culture centered around the customer and solving their problems.
An example continuous feedback loop. Source: UseResponse
Many companies are hesitant to force engineers into customer support roles due to the high opportunity cost. In addition, some engineers prefer to avoid talking to customers. However, there's growing evidence that talking to customers can help improve products by keeping everyone on the same page and promoting more empathy.
There are several benefits to encouraging developers to take on some customer support tasks:
- Big picture. Developers can develop a better understanding of how customers use their products rather than just translating faceless feature requests into code.
- Better service. Developers have in-depth product knowledge, enabling them to quickly answer questions or even fix simple problems on the spot.
- Quality code. Dealing with customers often means debugging code that they didn't write, helping them find opportunities to improve in the future.
- Soft skills. Talking with customers involves empathy, communication, and other soft skills that may be neglected if they spend most of their time writing code.
- Onboarding. New developers taking customer support shifts can quickly develop a better understanding of the product and customer before contributing any code.
You can involve customer support teams in early product discussions to ensure that new features address real problems. For instance, if you use behavior-driven development (BDD), a customer support person might be part of the “Three Amigos” team that discusses new features and builds the specifications for their implementation.
The Bottom Line
Most software businesses are inundated with feature requests. Rather than taking them at face value, try to understand the customer's underlying problem before thinking about a solution. Or, even better, get the entire organization involved in customer support to improve empathy and guide the development of future functionality.
If you're looking to level up your software, Sharkbyte provides everything from roadmap development to team augmentation to full-service development to bring your ideas to life.
