On this page:
Why are we doing this?
We get many feature requests and suggestions from our users. We are using the Feedback Project, and its voting system, to manage this. We do this for two reasons.
Firstly, the voting system allows us to make informed decisions about which items we should work on. This allows us to use our resources most effectively. For example, if a user proposes a small change, the feedback project and the voting system allows other users to engage with each other and vote. This, in turn, allows us to easily gauge user interest in particular features. The voting system gives us a sense of which issues would satisfy the most users, and we can direct our development efforts accordingly.
Secondly, and perhaps more importantly, the voting system gives more transparency into the process for our users. Previous to this, requests were hidden from other users. If a user found that their suggestion was not implemented, they had no window into our decision making process. The open nature of the feedback project changes this in that users can see requested suggestions and can see the process through which their ideas can be brought to fruition. They can also actively engage with each other and build up support for particular items for users that share common needs.
This is common practice in other software markets, see Atlassian for example.
How do suggestions become Feedback items?
The Support team reviews your suggestions and feature requests along with the Product Manager and comes to a decision.
One of three things can happen:
- "That's an interesting idea and it's super easy to implement, let's do this right away!"
- "That's an interesting idea, let's put it in the Feedback project to see if other users are interested."
- "That's an interesting idea but it's not currently in line with our product roadmap. We may reconsider this in the future but for now, we will not implement this."
How do we choose?
Each Product Manager will choose highly voted issues that are in line with the thematic elements of a particular release. The decision for choosing a particular issue is based on the number of votes and the number of different clients that express interest.
So, how do we choose? Here are a few examples of guidelines we are using:
- More votes is good, this is obvious. The high number of votes raises an item naturally to our attention.
- Having a good spread of votes across a range of clients and industries/sectors is also good. For example, having seven votes from seven different clients is better than having seven votes from seven different employees of a single organization.
- If an issue is of interest for a particular theme then this may be implemented even if the number of votes is low.
Of course, there is some nuance in the final decision making process. The ideas explored above give a sense of the general guidelines that we will be striving to follow. If we decide to change our guidelines, we will update this document and will inform users of this immediately.
This leaves the issues that do not have a high number of votes and that are not tied to any of the themes from our roadmaps. For these issues it is less likely that they will be addressed. If the issue is of a high interest to you then please contact QPS to discuss alternative solutions.
The top votes issues are regularly reviewed and we strive to resolve a target number for a particular release. For example, at least 3 out of the top 10. Another example of an internal target that we use is to satisfy a specified number of Feedback items within a year, over the span of a number of releases, for a particular product. As QPS and our clients gain more experience with the Feedback project and process, we will likely adjust our targets. We will always strive to make our targets transparent to users. If issues are in the top and will not be done in a reasonable time then this will be updated/commented in the issue.
As issues are decided for an upcoming release, the Product Managers may set the "Fix Version" on any given case with the future release version. This will signal to those that voted on the case that we are planning to implement that feature in a future release that is coming soon. The Product Manager might add a comment in the case to give an update to the Voters and may also engage in conversation with them in the Comments section.
Once a feature is implemented, the Product Manager will update the status of the case as Closed to indicate that it has been implemented. This can happen long before the release date, but we do this to give information to Voters right away that a particular item has been satisfied and that they can count on it definitely coming in the marked release version. The Product Manager may include screenshots or short demo movies in the case as well.
Lastly, for cases where there are zero votes, we may decide to Freeze the Feedback item. We do this to keep the list of items of interest as short as possible, so that it is easier for users, and us, to peruse the list to find particular items. We typically notify a user in their original support case that it has been converted to a Feedback case. If the user has not voted on their own suggestion after one month, we remind them. If there is still no vote one month later, then we freeze the case. The cases are still available to review, comment on and potentially re-open, but they are not included in the main dashboard elements of open cases that are actively being voted on.