At the earliest stages of product development, gathering as much feedback and input as possible is a high priority. Current users, potential customers, competitors, and even friends and family can contribute meaningful feedback. However, all feedback is not created equally. Sifting through the feedback and implementing the right requests requires weighing and prioritizing based on the source of the feedback.

One of the pitfalls I see founders and early product development teams fall into is over-valuing the requirements of potential customers. When a potential customer says, “I’d love to buy the product… if it only had XYZ feature,” the worst thing to do is to make that. It seems counterintuitive, but if a sales conversation has taken this turn, the most likely outcome is that it’s not a good fit. Potential customers are looking for an easy way out of the question of why they won’t buy.

It’s tempting to do whatever it takes to secure early customers, but adding features to satisfy one potential customer is a high effort for short-term gain and detracts from more meaningful improvements. Potential users frequently ask for things that are a low priority. And, if there’s no signed contract, there’s no guarantee that the potential customer will buy the product once the feature is added. Sometimes people use missing functionality as an excuse when the truth is the budget for the tool never existed in the first place or has since been slashed. For all you know, the last requirement of a potential customer could be nothing more than a carrot on a string serving as a buffer between you and the hard truth that they are simply not going to buy your product.

There are plenty of times when the suggestion is well intended and the potential user really believes their feature request will make the product better. Exercise caution if you decide to implement that feature request. Someone who has never used your product can’t really know how to make it better. Even if the features sound like a good idea, get used to the idea that you could be wrong. In these scenarios, take a highly iterative approach to feature development. What’s the smallest possible improvement you could make? Keep it small, simple, and agile as you may need to adjust course midway through or multiple times.

A similar approach can be taken for larger organizations where sales teams are involved. Features are rarely sourced from feature requests but a case can be made for implementing certain small, short-term improvements. In this situation, the sales representative has a vetted and established relationship with the potential customer so there’s less risk. Still, not every sales request is worth acting on. Product and sales should make a list of the top 5-10 highest priority requests each quarter.

Listen to the needs of your heaviest users instead

Prioritize features based on who is asking for them not how frequently they are asked for. Current customers can provide more relevant feedback than potential customers as they are already using the product and are better equipt to understand its limitations than someone who has never used it. The heaviest users of your product will give the best feedback. These are the users who have found the product’s edges. They know what works well and what doesn’t. They have felt the joy of having something just work and the frustration of trying to troubleshoot for hours, maybe even days, with no solution in sight. The heaviest users are the ones who have most likely submitted issues and pull requests proposing code modifications that might solve the problem they are experiencing. The ability to contribute back to the product is one of the greatest benefits of open core products.

After filtering up the best feedback from the heaviest users, weigh feature requests according to effort versus value. Low-effort, high-value improvements are prioritized over high-effort, high-value features. Stability comes from growth so the quicker you can ship improvements, the better.

Ask your community to help

To be efficient with capital, build with the community. Once you’ve decided which feature requests to act on, plant seeds by shipping a small minimally viable change (MVC) and asking the community to help mature it. This is one way to operationalize user feedback and test the feasibility and overall impact of the change without diverting internal engineers from the product roadmap set by the company.

Shipping functionality that is incomplete to expand the scope sometimes goes against instincts. However, planting those seeds even in an incomplete state allows others to see the path and contribute. With others contributing, iterations happen faster. You can have a long tail of categories that are at a minimal maturity that don’t get investment until they show traction.

While MVCs come with a low level of shame they allow the wider community to contribute and people to express interest. It is much more common for people to contribute to categories that already exist rather than suggest something entirely new. People who care the most are using it and just want it to work better. They rarely add scope.

You control your product roadmap

Ultimately, the product roadmap is created by the company, not the users. It’s the product team’s job to determine the product scope and which features fit into that scope. The entire product scope is defined by the product team and roughly 90% of the features will come from them as well. The other 10% will come from customers, potential customers, or sales requests.

The product scope defines the end result: what will this product do? The product scope is made up of features and functionality. A company may have a single product scope defined but there are many ways to implement the features and functionality. Product scope is developed through research and testing, primarily done by the product team. Ideas for features and functionality can come from a wide variety of sources. Users, contributors, and potential customers shouldn’t be adding scope.

Final thoughts

Feedback is critical to product development but not all feedback is equal. Heavy users will give you the best feedback and you should invest a lot of time in understanding how they use the product and what limitations they are running into. Potential customers are not that familiar with your product—the quality of their feedback is bound to be lower than users. Potential customers who are using a missing feature as a reason for not buying are probably not a great fit. Don’t listen to the last objection.

Open Core Ventures

Don't listen to potential customers "if only…