How I prioritise small requests alongside project work

Recently, I changed the way I prioritise new work requests and projects. Here’s what I’ve started doing.

Prioritising the product backlog

JIRA is our central system for development requests. There’s one project for smaller requests: the “BAU” as I call it, which is anything that takes 2 days dev time or less. Except for urgent requests, which we will drop other work to look at, anything in JIRA is allocated a business area via a custom field.

Each week, I export a list of all open tickets, filtered by area. One or two people in each area indicate their Priority 1 and Priority 2 tasks, and those go into the queue. We also prioritise our internal work, such as changes to the core product, and improvements to our technical stack.

We won’t complete all of the prioritised tasks every week – but it allows us to see what the priorities are.

I believe it’s important for all areas of the business to be included in the prioritisation process. Nobody should feel that their area is being ignored. Allowing each business owner to define their priorities can prevent this issue.

Prioritising the projects

Instead of starting yet another spreadsheet, for projects I decided to use pen and paper. I ordered a stack of 1000 plain white 5×3 record cards and a pack of Sharpies.

I started by writing one project on each card, and laying it all out on the table (literally). Staff involved in the meeting can see all the known projects, ask what they are, and identify anything that may be missing.

Once all projects are defined, we agree what’s the next priority. This makes it very clear which project will be worked on next – and also what won’t be. Showing the number of projects can make it very clear if there’s a capacity issue. There’s only so much resource, so we can’t work on every project simultaneously.

Does it work?

As this is a very new process I’m trialling, it’s too early to say how effective it is. I’ll write a follow-up post on this.

6 pitfalls with user feedback

Getting feedback from users can be an invaluable way to determine how your product is viewed by its audience. But it’s important to understand some of the pitfalls with user feedback before you start allowing comments to shape your product strategy.

1. Not everyone likes change

There’s a running joke that whenever Facebook changes something, people are up in arms for a week or two – maybe not even that. After that initial period, we get used to the change. Sometimes, negative feedback may be purely down to the fact we don’t like change. If you’re going to ask for feedback, don’t do it immediately after a big release.

2. People are more likely to give negative feedback

Negative feedback can be a good way to measure if a recent change has annoyed users. Unfortunately, a lot of people won’t give any feedback at all – including those who are happy with a change. Don’t take negative feedback to mean you need to reverse a recent change.

3. One-off comments may not help anyone else

If one person asks for something, don’t jump on that task immediately. If it’s a good idea and you can make a change as a result of their feedback, it’s something to consider. However, if you react to every comment without considering if it’s right for the product, you may end up with a product with a sprawling feature set, and that pleases an extremely narrow group of users – the most vocal ones.

4. New designs need time to bed in

A new design can attract a lot of comments – most of them are purely down to opinion. Issues such as elements overlapping, fonts being too small, or scaling not working across different screen sizes are important things to fix. Beyond that, aesthetics shouldn’t be up for debate.

5. People don’t know what they want

If you ask 100 users of your product what they want from it, the collective feedback may be a laundry list of missing features. In fact, your best change could be something that nobody even thought of. You are in control of product strategy – find things that people didn’t even know they wanted. Make the product quicker and easier to use.

6. Surveys can help – but be careful what you wish for

A user feedback survey can give you a limited set of feedback on the questions of your choosing. But don’t ask for things you don’t want to do. “Should we build an app?” is a pointless question if you have no intention of building one.