Beta testing has many different moving parts. With so many pieces, it can be difficult to keep everything in perspective. We’re putting together a series that looks at the roles of different activities and functions in beta testing so you can make the most of everything beta has to offer. This first post will look at the important, but often misunderstood, role feature requests play in beta.

What are Feature Requests?

Feature requests is the term used for feedback you collect from your testers about functionality they would like to see in future versions of your product. Feature requests give testers the chance to voice their opinions about how the product could be improved upon or more useful to them. They also give you insight into customer requirements and can help with product planning. The timing of beta, however, makes feature requests tricky, and leads to some of the common misconceptions about the role of feature requests in beta.

The Challenges of Feature Requests

Many testers and people outside the industry believe that beta is a place where customers can build a laundry list of ideas, each of which should be seriously considered for implementation in the final release.

Since beta is often the first opportunity customers have to use a product, the collection and implementation of their ideas seems like a logical step. The truth is that this is rarely the case, for three reasons:

1. It’s too late.
2. The most obvious reason feature requests are challenging is simply the timing of beta. Generally beta testing happens very late, often weeks prior to release. In most scenarios beta testing is intended to be a final test of the total performance of the product, often with a focus on quality. While many things can be changed after beta (bug fixes, documentation changes, marketing message tweaks, support strategy), the product should be at or near feature-complete when it reaches beta, thus allowing you to truly test the customer experience. This can make it nearly impossible to include the requested features without seriously delaying the release of the product.
3. It’s your job, not your customers’, to innovate.
4. To loosely quote Henry Ford, “If I asked my customers what they wanted, they’d have said a faster horse.” While a bit overused, this quote is a polite way of illustrating that it’s your job to define the future of your product. Unless there are very few of them (e.g. enterprise B2B), your individual customers can’t tell you what’s best for the whole. They simply don’t have a wide enough view to do so. It’s your job to maintain a clear picture of your broader audience, market placement, costs, and so on. This will help you envision and create the best product possible.
5. It’s generally not a big enough sample.
6. Unless the frequency of a request is overwhelming (i.e. the majority of your beta testers claim they need something to buy your product), chances are that the ideas collected in your beta test aren’t a clear indication of the will of your entire audience.

How to Use Feature Requests in Beta

If feature requests are so challenging, why ask for them at all? Feature requests can still play an integral role in the development of your product and the success of your beta test, even if they won’t substantially impact the product currently being tested.

1. Feature requests are inspiration.
2. Feature requests in beta provide the earliest available customer feedback regarding the feature design of your product, from people who’ve actually used it. This information can be used to influence future revisions of the product, which you may already be working on.
3. They send a positive message to your testers.
4. While you likely won’t be implementing their ideas this time around, the consideration of your testers’ ideas enforces the level of importance you put on their contributions. This will improve engagement rates which generate other feedback (bugs, etc.) which will be more immediately actionable.
5. Small features may be worth considering.
6. Not all feature requests are huge. Sometimes people will make requests for tiny changes that improve the product in major ways. Sometimes these are difficult to see as a designer or simply didn’t appear in your context. Sometimes features that only take an hour or two of work can have a very positive return.
7. High frequency should be considered.
8. Frequency is the key to collecting feature requests in beta. From time to time we see an overwhelming prevalence of a single idea in a beta. While this isn’t necessarily a sign that a pivot is needed, it’s definitely worth looking into, for future revisions if nothing else.

Feature requests can be a great way to connect with your customers and understand what they need from your product. As long as you consider the long term role feature requests can play in your product development cycle, you can avoid the frustration of feature requests and use the feedback from your testers to inspire a stronger, more appealing product.

Soon we’ll be writing a post on how feature requests are used in the Centercode platform to achieve these goals. We’ll also be looking at the roles other activities play in beta. If there’s a certain subject you’d like us to tackle, or something you think we missed, please let us know below.

For more beta best practices, visit our resource library!