On our UserVoice site, feature requests and suggestions usually sit somewhere between two extremes:
- Enable me to do something that is currently impossible to do
- Make it slightly easier to do something that is already currently possible (if annoying) to do
As a software publisher, we have limited resources, and we can't act on every single suggestion. Prioritising which suggestions to act on is important, but it can often seem random, especially when items with very few votes are implemented before items with many votes. Should prioritising features be driven purely by votes? Or should it be a judgement call?
When deciding which suggestions to act on, I think that there are a number of factors to consider:
- How many people want the feature, and how much they want it (votes)?
- Are there acceptable workarounds?
- How difficult/ideal are the workarounds?
- How difficult the feature is to implement?
- What are the ongoing costs of supporting the feature?
- How long are we going to get benefit from the feature?
Three examples
To illustrate, here are three suggestions on the Octopus Deploy UserVoice site:
- Schedule deployment of a release (18 votes)
- Select multiple environments to deploy to (40 votes)
- Bring back support for Internet Explorer 8 (3 votes)
When you deploy a release in Octopus, the deployment currently executes immediately. The first suggestion would mean that users could specify a time for the deployment to start. It might look something like this:
The current workaround would be to either come into the office at 2 AM, or to have a scheduled task that may or may not run at 2 AM that uses our API or command line tool to trigger a deployment.
The second suggestion is to make it so that instead of selecting one environment to deploy to, we'd allow multiple to be selected:
The workaround for this is simply to deploy to one environment, come back to this screen, and choose the next environment, and deploy again. Or to use our API or command line tool and specify multiple environments to deploy to.
The third suggestion is self-explanatory - bringing back support for IE8. Currently we only support IE9 or above.
Which of these should we do first?
The first two suggestions are probably about the same difficulty - either of them could be done pretty quickly. They are also very isolated features that aren't going to affect many other features in the product. Once we build them, and add some tests to make sure they work, these are the kinds of features we can forget about. I like these kinds of features.
"Multiple environments" has more votes than "Scheduled deployments". But the workaround for "Scheduled deployments" is a lot less ideal than the workaround for "Multiple environments". So on balance, we'd probably implement "Scheduled deployments" first, even though it has half the votes.
What about IE 8 support?
This is an interesting one. First, it's very difficult; we use a number of libraries that also don't support IE8 nicely, so we'd have to fix that. Then, we'd have to test that all/most of the application was usable before we can say that we "support it".
But a feature like this comes with ongoing costs: any time we implement a new feature, we're also going to have to test it with IE 8. Unlike the other two, we can never "forget" about this feature. And it's a lot easier to write an integration test that ensures that a scheduled deployment happens at the right time, than it is to automate browser acceptance testing.
The workarounds for IE8 are also interesting: workarounds exist (upgrade IE, get a different browser). But for reasons largely driven by costs (or politics), the workarounds, though easy, aren't deemed acceptable for all customers. If I'm being honest, I find myself having less sympathy when a workaround exists but is rejected for these kinds of reasons, than if the workaround is just difficult (coming into work at 2 AM for example).
And then there's the fact that IE8 market share is shrinking; we could spend a week adding support for it, plus additional time testing each feature we add/responding to bug reports about IE8 problems, and then in 6 months no one will need it anyway.
For this reason, I decided to mark the IE8 suggestion as declined. It's not just lower priority than the other two features; it's actually a negative feature due to the ongoing support costs and eventual obsolescence. I could leave it open to avoid hurting the suggester's feelings, but the reality is, even if it had 50 votes, we're just never going to do it.
I'd love to know: do you agree with this reasoning? What other factors should be considered when prioritising features? Should popularity of a suggestion be the key driver?
