Managing Feature Requests

I started my business as a web development consultancy, building sites for clients. As we have moved to become a product company since launching Perch, we’ve had to learn many things. Not least of those has been how to manage feature requests when the “owners” of what you are building number in the thousands rather than a single client.

When you are building a site for a client, and they ask for a feature that will be complicated or time-consuming to build, or make the UI harder to use, you can push back on it. If they then insist on the addition and are happy to pay for it, you build it. After all, it’s their project. If it adds extra complexity, they are the ones who have to live with it.

With a product used out of the box by thousands of customers, adding every suggestion is impossible. What seems intuitive to one user baffles another. Adding too many tiny features aimed at meeting very exact requirements soon leads to a complex and confusing UI and adds to the time it takes to get up to speed on the product. This is especially important with my own product, as one of our core values is simplicity. In this column I outline some of the key things we have learned while adding features to Perch over the last five and a half years.

What problem are you trying to solve?#section2

People will tend to make very precise feature requests. What they are doing is offering a solution, rather than explaining a problem. Most developers will be familiar with being asked if they can “just add a button here” with no thought to the underlying requirements of that option. When you have a product, you can expect many such requests every day.

Customers aren’t spending their spare time dreaming up ideas for your product. They ask for a feature because their project has a requirement, and so will propose a solution based on their use case at that time. To get past the specific, you need to get to the problem that the user is having. What are they trying to achieve by way of the solution they have proposed? By asking those questions you can find out the real need, and sometimes you can help them solve it right away, without having to add an extra feature.

Moving from the specific to the general#section3

Once you have a problem outlined, and you have discovered the use case of something that is not possible or is only partly possible in your product, what should you do? It’s tempting to jump in and start coding, especially in the early days of a product. You start to worry. A customer has identified somewhere your product is lacking, what if they go away? At this point you need to put that anxiety to one side, and rather than react by immediately starting to code the new feature, decide how any addition fits into the goals for the product and the needs of the majority of customers.

It is likely that if you have managed to define a more general use case, other people will have similar requirements. If you don’t know what those are yet, then add the feature to a list for consideration. At Perch many feature requests sit in our backlog as we collect more requests for similar features. We can then try and develop a feature that will solve the more general problem. It might be very different to the specific solutions suggested by those customers, but it solves problems they have all experienced.

What will make the most difference to the most people?#section4

If you have a popular product, it is easy to feel overwhelmed by feature requests. What do you do when you have a large number of valid requests that you agree would be great additions? It can feel as if whatever you do you will let someone down.

Sometimes feature requests have a natural order of dependencies—you need to add one feature to enable something else. However, quite often you can find yourself with a backlog of equally interesting, sought-after features. Which to develop first? I tend to make that call based on which of these features would help out the most customers. This approach also gives you a good response to the vocal proponent of a feature that is of use only to a few customers. You can explain that you are ordering requests based on the number of people who need the feature.

Build for your “ideal”—not your noisiest—customers#section5

In particular, I want to build features useful to those customers who fit our “ideal customer” profile. Perch has always been aimed at the professional designer and developer market. It assumes, for example, that the person building the site knows how to write HTML. We have a significant number of people, however, who dearly wish to use Perch, but who are tied to a WYSIWYG website building tool and believe Perch should support that. They can be very vocal about their disappointment that we will not build tools into Perch for “non-coders,” implying that we are wrong in turning away all of this business.

Supporting these customers through the software would make Perch a very different tool, one that would be far less appealing to the front-end developer and web designer audience we serve. When considering feature requests, we always come back to that audience. Which of these features would make the most difference to the most people in that group?

Only 25 percent of people with a Perch license ever raise a support ticket or post to the forum. Only 10 percent do so more than once. The majority of our customers are happily using the product and buying licenses for new sites without ever speaking to us. Be careful to seek out the opinions of the happy majority—don’t move your product away from something they love and find useful due to a few noisy people.

Be willing to say no#section6

While every feature should be considered, logged, and grouped with other similar requirements, it is important to remember that sometimes you do need to say no. The product needs to be owned by someone, a person or a team with the ability to decide that a feature shouldn’t be added.

Keep in mind the core problems your product sets out to solve and the profile of your target customers when making decisions about features. By doing so, you create a filter for new ideas, and also a way of explaining your decisions to customers who may feel disappointed in your choice.

Realize you are not your customer#section7

Like so many other products that have been launched by consultancies, we built Perch to scratch our own itch. Version 1 was very much the product we needed: a product for people who cared about web standards and structured content. We then had to be willing to learn from feedback. We had to accept that some of the things we thought we should decline were real requirements for the people we felt were an ideal fit for the product.

I believe software should be opinionated. We continue to promote best practices and modern web standards through the implementation of our product. We do this even when those values aren’t seen as important by many of our customers, as they really are the heart of the product. By keeping those core values in mind, digging down to the problems rather than accepting the first solution, and listening to our key customers, we continue to move forward while maintaining the simplicity we aimed for at the start.