Project Management

Project Management Central

Please login or join to subscribe to this thread
Gathering and Managing Feature Requests
Weighing between sending out periodic surveys company-wide and creating a large chatroom of interested users, we chose the latter option for the gathering of feature requests for a recent product we've rolled out for beta-testing.

Turns out, as a product matures, so too the volume and frequency of inbound requests for ideas, etc which is wonderful. What's a good way to manage these? Ultimately we do our best to raise tickets for each and invariably, you start to get duplicates (especially if your users are savvy enough to do so on their own).

It gets even more complicated when bug reporting also goes through the same channel (sometimes you can't tell the difference).

Any advice? Do share your experiences. Would love to learn from you.
Sort By:
In one case we tracked all their incoming requests by tickets. In another case and which is manageable for both the parties, we had them add their ideas in a shared document - OneDrive, for instance. Periodically we were reviewing this document and picked the business-priority items for future improvements.
There are two aspects to this:

1. Organizing and communicating the backlog of requests
2. Prioritizing a backlog of requests

The former is more of a mechanics issue - pick a tool based on your needs, import the requests and provide a means for requestors to pull info out of it.

The latter is much more challenging - there are numerous methods for a product manager to prioritize what comes next - buy a feature, prune the product tree, WSJF and many many others. Picking the "right" option for your context will take some time and you may not get it right the first time.

Kiron
Jonathan

What you describe is one of the main reasons people lose faith in developments ability to deliver. You do not say whether you are using an Agile framework or not but lets assume that you do. The most important, and difficult, part of the prosess is the ability to say no. If every 'legit' requirement is popped onto the backlog we end up where we do not want o be - stakeholder end up waiting for months for their requirement to surface. You could then also end up with a situation where you cannot trim the tail which result in a larger amount of support issues, meaning a lower velocity, menaing the 6 months wait gets longer, meaning .........

It is very important to manage the size of your backlog by doing first pass prioritization where some request will not make it onto the backlog. Something like MoSCoW helps.

Please login or join to reply

Content ID:
ADVERTISEMENTS
ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events