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.

Article Continues Below

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.

8 Reader Comments

  1. This article hit the exact issues faced by startup founders with handling feature requests. The solutions given are very good. I would like to see more articles on product development. Keep up the good work.

  2. Thanks for sharing Rachel, especially for reminding us to be careful to seek out the opinions of the happy majority. So often we forget…

    At Microconf Europe you mentioned your ideal customer could be a freelancer as well as an agency. Can you share some thoughts on these different audiences from a ‘ feature request’ perspective?

    thanks again and keep up the great work!

  3. I Agree with you on this, despite having disagreed with you to try to force your hand via twitter over youtube video’s in perch for a client that was using Perch in 2012;

    I think when “owning” a product it would be more beneficial if more businesses tried to define a space, rather than trying to setup TESCO’ish brands with no real meaning and no added-value or core-user-group, but I also think you have to be pretty brave and recognise it can sometimes be even harder to gain traction if certain influential clients that bring the money regard you as an enemy of innovation… As the article says it is a balance!

  4. Wonderful summary of the challenges of transitioning from consulting to product development while preserving your ideals and learning how to listen to customers but not overreact.

    Here is how we use Trello to handle some of the mechanics described in your article for our product, Cognito Forms:

    – Registered users can submit feature requests through the product at any time (which they frequently do).

    – Our support team triages the requests, making sure the feature is not already supported in some way, and if not, records the request on our Trello idea board.

    – Our users, or anyone in general, can view the idea board and up-vote and comment on proposed features.

    – Periodically, we will “clean up” the list of ideas, performing the “generalization” step you suggested to translate these very specific requests into “features” that accommodate the need in the most general way.

    – Before starting new release cycles, our development team will review feature requests (including our own) and sponsor features we agree are important based on customer feedback and our own sense of what is possible based on where we are.

    – We then promote these features to Next Up and In Progress swim-lanes on the board to let ourselves (and everyone else) know what the plan is.

    – Since we let our customers know when their ideas are placed on the board, they frequently will subscribe to the board for updates and therefore always know when “their” features are receiving attention and are nearing production.

    Overall, we have been pleased with this approach (which we “borrowed” from the Trello team)! Thanks again for the excellent post!

  5. What you say about handling customer’s request is so familiar. We try to take the time to dig into the odd feature requests because there usually is a underlying problem and very real problem that should be addressed. Often the solution – as the article says – can be something quite different from what the customer suggested. Which is natural given that the customer doesn’t have intimate knowledge of how the software works or what possibilities the framework offers.

    It can be tricky to find the core problem as the customer can be impatient and not overly keen on spending more time on discussing, and for the support people it can be easier to just label the requests as “weird, won’t fix”.

    But doing the digging really pays off, we have number of examples on how it gave us new insight in the way customers used our products and thus enabling us to improve on a more fundamental level than just bugfixes.

  6. This is a very interesting topic to tackle. It’s a delicate balance between managing user requests and stakeholder requests. I think part of the role of a UX Designer is to be able to advocate for the user while managing expectations and disappointments.

    You can’t please everyone…

    Great writeup, thanks!

  7. Great article – thank you for sharing!

    This was a massive problem at our last Software-as-as-Service business. We had no idea who all the feature requests were coming from – churned users, free triallers, big paying customers, small customers…?

    Understanding who is requesting the feature is a massive deal. We built to solve this problem.

    We also enable software companies to dial in development effort so you can see the value that a feature will add to your product mapped against the development effort required.

    Here’s some of the other problems Receptive addresses:

    Measuring which requests come from the most valuable accounts
    The big spreadsheet of requests never keeps up with this, or gets updated when users have churned.

    Managing the “long tail” of small improvements
    Every SaaS vendor knows the “big wins”, the top 3 missing features that are deal-breakers for many leads. We called them “embarrassing feature gaps”. The tough part is identifying the small fixes would make your customers happier without taking weeks of development effort.

    The kid in the candy store problem
    If you ask your customers, they would like almost everything from your backlog of feature ideas. You can’t act upon this feedback until your customer has prioritised. Un-prioritised lists of “wants” are almost worthless the product manager. We built a system to encourage customers to prioritise, which in many cases surfaces some surprisingly small features that make customers much happier.

    Its so important to concentrate on what your paying customers want, to help you get to product/market fit as fast as possible. You need to filter out ideas from trial accounts and churned users, and consider those segments separately.

    Keeping customers informed about new features that they actually care about. This involves a lot of searching back in emails etc, which is really time consuming and you are likely to miss someone.

    Existing tools to handle customer feature requests are basically forums with “me too” voting. Great for transparency, and I’m sure they help consumer brands to get feedback, but they don’t add a great deal of value for SaaS product managers. The product manager is the decision maker, SaaS businesses aren’t democracies.

    Really passionate about continuing to build a brilliant product that helps others. We all have limited development resources so we help answer the question “What is the highest-impact thing I can work on right now given my limited resources, whether that’s people, time, or money.”

    Would love to hear everyone’s thoughts on this.

    Thanks everyone 🙂

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA