Every product manager knows that everyone has an idea on how to make the product better. It doesn’t matter whether it’s a user, an engineer, a sales rep, or the CEO, everyone has an opinion, and it’s the role of the product manager to sort through all these ideas and align them with the needs of the business.
The problem is, there are too many ideas, and how do you keep a track of them all without your backlog being swamped or them being recorded in an inaccessible way?
The answer is a Feature Request project.
This is a place that sits away from your backlog which is the home of all ideas. It doesn’t interfere with the work being done by the engineering teams, unless you as the product manager choose to prioritise the work.
And it’s quite easy to set up.
Create a place to store the requests
(Note: you’ll need the help of a Jira Administrator for this one)
From the Jira Administration menu select Projects and then click on Create Project. You’ll then be presented with a selection of the types of project you might want to use. For the purposes of this a Scrum project is fine. Give your project a name so that you, and everyone who accesses it, knows it’s the place to put Feature Requests.
Within your project you’ll then have a Board, which will be the place that you’ll be able to view and manage all the feature requests.
Create a way to group the requests
Within Jira there is the concept of Epics, which are groupings of individual items into a larger collective. For the purpose of our Feature Requests we’ll use Epics to define particular areas of our product that people might be giving us requests for. For example, Online Sign Up, Customer Profile, or Analytics.
When the feature requests are submitted they’ll be dropped into one of the epics so that it will be grouped alongside all the other requests that are in that area of the product. If you want to see all feature requests relating to online sign up, simply click on the Online Sign Up epic.
Gathering the requests
The aim with gathering the requests is to ensure that they all end up in the same place, so you only have one place to manage them. For anyone who has access to your Jira project then they should be encouraged to add their feature requests directly into your Feature Request project. This saves you lots of time doing the admin, and it also encourages others to review the existing feature requests so that you can try and avoid duplicated requests.
Of course, not everyone will have access to the Jira project, so you need to ensure that for these people, whoever is the recipient of the request knows that it will need to be added to the Feature Request project. So if the CEO emails you with a request, you create it in the Feature Request project. If a customer emails the support team, then the support team create it in the Feature Request project.
Over time the list of feature requests will grow and become a valuable asset for the product team.
Review the requests
Of course, if all these people are adding feature requests then the list can get quite long, and without some regular reviews it can get quite wild. That’s why it’s important to put aside time every week to review what’s changed in the request list.
To make this easy you should create some quick filters to help you access the new information. These filters are:
- New requests — requests that have been created in the past seven days
- Requests without epics — requests that have not been assigned to an epic
- Requests without labels — requests that have not been given any labels (see more information on labels below)
From your board you should go to the board menu and select the Configure option. You will then need to head to the Quick Filters page, where you can configure your filters.
For new requests you need to use the query: createdDate >= -7d
This will show you any request where the date it was created is greater than seven days ago. You can change the 7d to however many days you want to check back through depending on how regularly you are reviewing your requests.
For requests without epics you need to use the query: “Epic Link” is EMPTY
This will show you any request that hasn’t been assigned to an epic within your project.
For requests without epics you need to use the query: labels is EMPTY
This will show you any request that hasn’t had any labels assigned to it.
When you Go Back To Board you’ll now see these quick filters at the top of the board and you can use them to get a quick view of what needs your attention.
Label the requests
We often want to break down our feature requests by more than just the area of the product that it relates to, and that’s where labels come in. There’s flexibility within the labels system to allow you to create labels for anything, but some that might be useful are:
- Customers — which customers have requested the feature
- Benefits — what kind of benefit will the feature deliver
- Complexity — how big a piece of work is the feature likely to be
When it comes to customers, being able to tag a request with a customer’s name means that you’ll always be able to see what requests relate to that customer and you can communicate back to the customer when the feature progresses through the process.
With benefits you can add labels such as speed, insight, or flexibility, so that when the business decides to focus on a particular goal such as ‘making the product faster’ then you’ll be able to head to the feature requests and view all the requests with a benefit of speed.
For complexity we’re only talking about a ballpark estimate of the size of the work, in a small, medium, large sense, not a full days or story points estimate. If it’s the addition of one new field in the online sign up form then it’s a small, but if it’s integrating with a third party application then it’s large. This comes in handy when you need to bring in a small piece of work for a team that have finished their scheduled activities, and you can quickly find all the small requests that might be given to them.
You can even add quick filters for each of the labels if you want to really quick get access to the requests you need.
Progressing the requests
When the business decides that there’s a specific priority, you are now free to access the large warehouse of ideas that have been collected over time and which are organised in a way as to enable you to find exactly what you need.
The way you progress the requests that have been selected for development will vary depending on your own development process, but you could:
- Move the request from Feature Requests to your development project
- Clone the request and move the clone into your development project, whilst closing the original request and marking it as having been selected for development
Give it a go
Why not give it a try, or if you’ve got other ways in which you keep track of all the incoming feature requests then let me know.
Rob was a professional soccer player, and cinema manager, before moving into software development 20+ years ago. He was a founding team member at startup Ormsby Street, heads up the product team at Qudini, and speaks and writes on product, teams, productivity and communication.