What should we work on next?
Alaveteli is a large, long-running project with a sizeable history of bug reports, improvements and feature suggestions – and a fairly constant stream of new ones. In short, we have ~1200 open GitHub issues (things to improve).
As a small team we’re only able to do a small fraction of the things to improve, so picking the ones that will have most impact is vital to make the best use of our time.
Prioritising this many options is impossible – and having a huge backlog is demotivating – but there are some great ideas hidden in the noise.
Sea of Possibilities
We try to ticket everything at mySociety so that we can work asynchronously and get things out of our head. This makes for a lot of tickets.
As a product manager its really difficult to see which of these are most valuable to users.
Group by Concern
Grouping issues by concern really helps to make a big initial step to reducing the cognitive burden.
Grouping issues by concern lets you at least compartmentalise all this noise so that you’ve got some “shape” to the problem. Its much easier to think “How would I make our request management features better?” compared to “Which of these 1200 issues is most important?”.
Actionable Pitches
The next step is to figure out which of these issues are ready to work on.
To do this, look for those that have a described problem and a proposed solution.
Without a clear demand then there's probably no real value in solving the problem. Issues of this nature fit in to the “Wouldn't it be nice if…” bucket. Issues titled “Redesign the X page” or “Rewrite the X” may also be a sign of supply-only thinking.
Without a proposed solution we can't make a good decision on whether completing the issue is valuable. We can't guess at how much effort is involved if we don't know what we're trying to achieve – so we can't decide whether the cost is worth it – or whether we can even solve the problem in a satisfying way at all.
Prioritise What's Core
By this point the picture should be getting really clear; only a handful of actionable issues will exist for each feature area.
It may even be obvious which to pick, but if not we can ask “What’s core?” to reduce the options further. The concern groupings we made earlier help to make this question more concrete. Some of the concerns will be the key functionality that the app was specifically made for. Others will be support features, or extras that provide some added value.
We don't necessarily have to work on “core” issues all the time, but asking this helps to give an indication of whether you'll be helping 3% or 30% of users.
Feed the Hopper
The remaining items are important – and actionable – so can be added to the hopper of ideas that may be picked for a cycle.
This process doesn’t guarantee that everything we pick is going to be the most impactful out of the whole pool of things to improve. We’ll miss some that aren’t actionable, or maybe we’ll pick some that just don’t work out as we’d expected.
What we are doing is maximising our chances of creating some value by shipping the things we choose to work on. Concerns help compartmentalise the things to improve, and make better tradeoffs when we can’t do everything we’d like. Actionable issues help avoid running in circles around an unclear solution, and ensuring the things that we work on are going to create real value for someone.
Strategy is a process that goes on 24/7, not “an event” followed by implementation. Each cycle we'll build a better idea of what to focus on by getting feedback on what we ship, and by talking to users about situations they were in when they use our tools.
– This has largely been inspired by Ryan Singer’s recent writing and talks about Basecamp’s product management process.