Feature Request Management

Feature requests are an important communication tool between the development team and the end user. Queries allow you to take a more sensible view of the product from the user’s point of view and identify ways to improve the user’s experience with the product.

Hello! My name is Irina, I’m a product manager at Bimeister, and I want to tell you about our experience in managing Feature requests in a B2B product.

Problem

As our product develops and the number of customers and, as a result, users increases, the problem arises of an increase in the number of comments, requests for improvement, and the addition of new functionality to the product. At the same time, such requests can be very specific and have the wording from “rename the button to …” to “integrate with our ERP system.” And while many of these queries may seem useless and time-consuming to respond to, they can have an extremely positive impact on both the product and user relationships if managed properly.

Whether you implement an idea or not, if you properly respond to the request, you will strengthen your bond with customers. And, of course, if the request is for a feature you haven’t thought of before that fits perfectly with your product’s goals and strategy, it could end up making a big difference to your product.

The bottom line is an article about how we threw out of our lives the automatic “Thank you, your opinion is important to us.” Go 🙂

A word about categorization

The generally accepted categorization of requests is as follows:

1. Reporting bugs (aka bugs): when a client notices that something is not working properly in your product

2. Improvement Request: A suggestion that could make the current feature a little better

3. Request for new features: ideas for completely new features that can be added to your product according to the client

It is important to keep these three categories of requests in mind in order to choose the right way to process them.

Accepting requests

The first step to correctly build a request processing system is to determine a single point for collecting requests. And here it is necessary to expand this thesis a little. When we tried to identify all potential sources of query data, we got the following set:

1. Requests from active users

2. Requests from the product development / implementation team who care about their product (and we all do)

3. Inquiries based on the results of demonstrations for potential customers, carried out in conjunction with our Sales & Marketing department

It turned out that even with such a number of sources, the wording of requests is strikingly different and depends, among other things, on the type of activity of the requester. Simply put, everyone looks at the product “from their own bell tower” and is not always able to correctly convey their need in a way that is understandable for the development team.

Accordingly, it became obvious that the first step for us would be to create a single point of collection of requests and standardize their descriptive form.

Our colleagues from the technical support department, who are on the first line of defense, help us a lot here. Together with them, we have created a single form on our online portal, which the user must fill out when making a request. It contains the following main fields:

Request categorization

After receiving requests in the described format, technical support already has enough information to determine their category.

Bug reports are immediately submitted to the bug backlog for resolution, in accordance with the regulatory deadlines.

Other categories of requests are submitted to the product team for analysis.

Request Analysis

Query analysis in my team is done by business analysts. They conduct refinement studies in order to determine the following parameters:

1. Sufficiency of information in the request. If necessary, we contact our colleagues from technical support / with the author of the request to clarify more detailed information

2. Category: improving or adding new functionality

3. Existence in the roadmap (in general, an open roadmap allows the client to understand where our product is going and helps to formulate more targeted requests that correspond to the goals of the product, rather than random ideas that cause overload)

4. Frequency of requesting specific functionality to determine its demand

5. Gap level with the current state (this is where the classic fit-gap analysis comes to the rescue)

6. Estimation of labor costs for implementation

7. Impact on key metrics

Then, all this information is transferred to the product manager, for the final decision on the request.

It should be noted that in our practice, this analysis does not take much time. On average for the product, we receive 15 requests for improvement or new functionality per week, which take approximately 3 man-hours to process.

As a result, we are preparing an honest response to the author of the request, where we indicate the approximate implementation timeline if the functionality corresponds to the roadmap or we decide to add it there. Otherwise, we also honestly answer that we are not ready to implement the request.

Conclusion

In conclusion, I would like to give a few statistics:

· 720 requests for improvement or new functionality were received during the year;

After grouping similar requests, 305 remained;

· 149 of them received a negative response to the author of the request;

· for 113 matches were found in the roadmap;

· 43 were added to the backlog to test product hypotheses.