Jonathan LeeBusiness Development Manager| Symphony Communication Services LLCSingapore, Singapore, Singapore
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. Saving Changes...
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. Saving Changes...
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 Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
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. Saving Changes...
