The PM Vision

Handling the Avalanche of Feature Requests


Have a product in customers’ hands?

Get ready for an unending river of feature requests!  A common problem among product management professionals is how to handle requests from clients and prospects in various market segments, along with strategic initiatives.  “They’re all good ideas!” Handling feature requests combines several distinct problems:

Do you track feature requests?

Product managers get requests from clients, prospects, sales engineers, implementations managers, other product managers, the competition, and more.  It can be a full time job just to track requests. As a product manager who has kept customer requests in a spreadsheet, there is a better way.

Jason Fried is correct when stating that important requests will keep coming up, I believe you need to track them anyway.  The reason is that it’s important to be able to communicate with those requesting a feature at design time, in order to make sure you solve their problem in the best way.

Additionally, beyond a certain scale, product talks to fewer and fewer customers, and the support and services teams scale–so it’s harder to get a sense of how frequently a request comes in.

It’s also interesting to watch trends–what areas get more requests over time, what items come in from the most customers, etc.  That doesn’t mean, however, you should spend valuable time doing the tracking. That’s where tools like UserVoice come in. The primary objective of tracking and comparing requests in a list is to find the most important ones to work on next.  UserVoice allows your constituents to vote on the ideas, such that those with merit rise to the top.  You can outright reject ideas you’ll never do, note those that you’re considering for future work, and acknowledge those you’re not sure what to do with yet.

What’s your problem?

Product managers are problem solvers, not order takers. To analyze a feature request, product managers should always probe for understanding of the underlying problem to be solved, or job to be done.  Enhancement requests are suggested implementation options for how to solve specific needs.  Once the need is identified, other options often emerge. This is illustrated by an anecdote told by Kristy McKnight of Central Desktop:

By examining user requests in greater depth (as opposed to immediately reacting to them), the company discovered details that could more holistically impact the product strategy for each of its target verticals.

Since you won’t ever build 80% of the requests you’ll get, you won’t have to create an implementation plan for those, but it’s wise to try to understand the underlying problem driving as many of the requests as possible.  So regardless of where or how you track requests, giving them some air time in the brain is a wise choice for your product.

How do you prioritize the changes?

Now that you’ve had chance to evaluate the needs behind the requests, you can start considering the specific changes you’ll actually want to make to your product(s) — if any — to solve the underlying problems. Assuming you have some product or portfolio direction, the work to address enhancement requests splits into three buckets:

  1. Ideas that don’t fit with the long term vision for the product at all.  These receive a polite rejection.
  2. Many, many good ideas that you might do someday.  These are usually acknowledged but sit in the “someday” bucket.
  3. A few ideas which map to the area of the product that needs work next, or the next most important problem to solve.

There may be a revenue projection to consider, as some additional features solve problems that people are willing to pay more to solve.  We’ll cover revenue projections in a future post.

You might categorize requests by the problem they ultimately help to solve, or by area of functionality within the product.  You can look at those groupings to see which areas get the most requests.   Further, when it makes strategic sense to enhance an area of the product, you can then review all the suggestions for that area and attempt to address the underlying problems at once.

Chances are, you have a persona or personas in mind for whom you’re designing.  You’ve got some idea of their problems and what it’ll take to solve them.  Are you selling them one or more products, or a single solution composed of one or more products in your portfolio? Which feature requests are you receiving related to the pieces required for the solution(s) you’re selling?

Once prioritized, you’ll want to communicate your plans in a roadmap that doesn’t tie you to specific dates.  We’ll cover more on prioritization using the Kano model and others in future posts.


TL;DR: Find out why your clients are asking, and ensure you can dig in later.  Prioritize!