Over at Perch we develop the product based on customer feedback. Our method of ordering features is to add the things that will make the most difference to the most people. We gather feedback from our interactions with customers (primarily this happens in our support forums) and try to shape a feature from the specific requests that will meet a more general use case. As we help customers to implement their websites we discover areas where we could do things in a better way, uncover requirements that we had not thought of. In addition, we have a feature requests area of the forum. We find that, directly or indirectly, the next thing we should be adding rises to the top. That might be due to a change in the industry, or that we have started attracting a certain subset of customers.
There is, however, a danger with this approach. In support, we typically hear from 25 percent of our active customers more than once. That leaves a lot of people whose ideas and needs may never be taken into account.
Experienced developers using our product also find places where a new feature or a refinement would have been helpful to a recent project. Rather than logging a request, they route around it and find a different way of achieving the end result. Sometimes they explain that they didn’t want to bother us as it “wasn’t a big deal. ” With the requirement solved they didn’t need support, so the fact that a useful feature had been identified never made it back to us.
In our own work, we try to use tools and services from other small companies. When we come up against something that a tool or service can’t do, our response is usually to build something on our side to route around the problem. Even as product owners ourselves we forget how valuable the feedback from other developers is. When we do remember to drop them a line with a feature request it is very well received. Sometimes we’ve had what we needed the very same day.
Our own hesitancy about interacting with developers of the products we use reminds us of how many of our customers we never hear from. It encourages us to find ways to make contact with the people who don’t readily contact us, to find out how we can better serve their needs even if they are happy with the product currently.
We try to make contact with the silent majority of our customers by a variety of means. We pose questions in our customer emails, directly contact specific groups of customers, run occasional surveys, and invite them onto beta programs for major revisions of the core product and addons. We’ve launched a Slack channel, and are seeing people show up to chat there who never turn up in our support forum. Nevertheless, we know that there are long term, committed customers who we simply never speak with.
There are lessons here for all of us. If you are a product owner, be aware that the feedback you get may not be completely representative of your customers. Be prepared to dig a little deeper and find ways to contact and speak to the silent majority. If you do not do this, you run the risk of moving the product in a direction biased towards the minority.
As for developers, next time you find yourself writing some code to route around an issue with a third party product or API, take the time to offer feedback to the product team. If you have had to write code to deal with an issue then you are in the perfect place to show a real use-case, something that we as product developers love to see. Never feel that you are bothering the product team with something you could solve yourself. We all want to make our products better, and we can only do that by having our attention brought to where the issues exist.
Source: A List Apart: The Full Feed