πŸ’¬ Collecting feature requests from users

Collecting feature requests provides a valuable source of ideas and feedback from the people who matter the most – your users and customers. A feature request workflow becomes a pipeline of information that helps you build winning products and create delightful experiences for your users.

πŸ™‹β€β™‚οΈ Feature requests – a goldmine of ideas and feedback

A feature request is essentially an idea submitted by your users for a new feature or functionality they would like or need to improve their experience with your product. While most commonly found in technology and software businesses, feature requests can be useful for pretty much any business – they provide a way for your users or customers to literally tell you what they want. Feature requests also allow users to feel like an active participant in the product, providing them with a sense of ownership over the product that helps further cement user loyalty.

So, if you don’t have a process for collecting and managing feature requests, you could be missing out on a goldmine of user feedback, ideas and experiences that underpin a winning product. The good news is a feature request process is easy to set up and run, and now even easier with our feature request workflow template.

This is a pretty simple workflow: there is a form which acts as an online portal where you can display your current roadmap, as well as allow users to submit feature requests.
When a feature request is submitted, two things will happen. Firstly, it will record that feature request as a new record using the built-in database in Workflow86.
It will also send a Slack message notifying the team of the new feature request:
So there you have it – a simple and easy to set up feature request workflow you can use to keep users posted on your feature roadmap, as well as capture feature requests. There is also lots of room for further extension using other components such as the API Export component to make a POST request to your ticketing system.

πŸ™‹β€β™‚οΈ How to prioritize feature requests

Of course, how you handle feature requests is also important and not all user feature requests should be implemented or implemented right now. Prioritization is key to ensure that you are hitting the right feature requests that will deliver the most value for the most users. Here are our tips for how to handle feature requests.

πŸ” Dig into the problem

Sometimes users will suggest features or make requests which might not be the best solution to the problem they are facing. At the end of the day, users are responsible for identifying problems and issues and you are responsible for creating the solutions. So we always take time to dig deeper into what is the underlying problem behind a feature request. For example, a user might suggest a feature such as “I want to

🚩 Prioritize based on urgency and impact

Prioritization is key when handling feature requests – proper selection of what features to work on and when to work on them. One of the frameworks we find super helpful is the urgency vs importance matrix. This matrix looks at any feature according to two variables: its importance and its urgency.

Importance is a measure of impact. How much impact and value would this feature create, and for how many users? A feature that is low impact only delivers small improvements to the user experience. A high importance feature is one which delivers a massive improvement or capability that would unlock or add value to many users. Importance should also be considered relative to your key metrics. For example, if your key metric is to improve user retention, a feature that improves user retention is more important than one that does not.

Urgency is a measure of timing. it answers the question of when to do something. Inevitably, you will accumulate a list of really good features and ideas, but you can only handle so many at any given time. Urgency helps determine what you should be working on right now, and what can wait for later down the roadmap.

Using this matrix, features which are important and urgent are prioritized first. As the matrix below suggests, important and urgent means we should be working on these right now. Features that are important but not urgent are being planned out and technical requirements researched and set – these will be the features we will be working on next. Features which are not important but urgent (which might include as minor fixes or non urgent technical debt) are usually delegated to a later sprint, or to anyone in the team with spare capacity. Finally, features which are not important and not urgent are be eliminated entirely from our roadmap.Β 

Sign up for free now πŸ‘‡

To try out these features and more, create a free Workflow86 account now