Task prioritisation: how I balance between bugs and features

I recently visited a meetup with two product managers. One – from Skyscanner – avia-tickets aggregator, second – from Atrapalo – marketplace restaurants. To the question "What do you think is the most important thing in the product manager's job?" both of them answered: 1. Say "No", 2. Prioritise tasks.

I'm still mastering the skill of saying "No" :) but I'm happy to say a lot about task prioritisation.

The job of our product and developers' team circles around Jira tickets. Each of them has its type: bug, task or feature. Bugs and tasks can be set by everybody who has access to Jira (us, managers, some specialists etc). Features can be put only by me. I also try to review bugs and tasks in order to make sure they are decent.

We divide bugs into critical and non-critical. Critical is a bug that blocks the main flow for a significant number of users. We don't have formal criteria yet - use common sense. E.g. if none of the German customers can pay, or if payment notification emails are stuck in the queue – it's a critical bug.

Critical bugs are solved by a highest priority. When we see such a bug, we drop everything and fix it.

Non-critical bugs – everything that is painful but doesn't block the main flow or affects only a small part of the audience – have a high but not highest priority.

We try to have not more than 10 open bugs. First, even non-critical bugs damage the brand reputation and the trust of customers towards the product and second, for managers who report bugs it's important to see that we do close them fast. Thus, when they notice the system behaving weirdly – they tell us. If we don't fix bugs - people stop to reporting them and don't give any feedback at all.

We call "tasks" anything that doesn't require development and deploy. E.g. change the copy, redirect URLs, make extractions from the DB etc. They have the lowest priority. We do them when we have time or if a requestor asks persistently.

In the same way as bugs, tasks live in a separate list. We try to have not more than 20 open tasks. Developers don't like to do them because they are boring and not creative.

Lately we have way less tasks because we integrated the data visualisation system
Tableau and now anybody who wants an extraction from DB can open it and look for themselves. Actually this Tableau instrument made a great difference for the company and the product team. If you want – I can tell more about it :)

Features are the things I'm working on most of the time.

I divide them into two parts:

For the main conversion funnel features I have around 30-40% of time. The other 30% is divided between other features. It doesn't make 100% in a sum, I know :) It's because we also have bugs, tasks, refactoring and the remaining technical debt.

Let's go ahead. One set of tasks is usually more important than another one. For example organic traffic is crucial for us hence SEO tasks always have a high priority. It means that I give about 20% of time to SEO tasks and divide the rest between other issues.

For each group, I have a list of issues that come through competitors' analysis, brainstormings, clients' and teammates' ideas, analytics etc. These issues are prioritised according to big company goals and quarter objectives, plus using intuition and common sense. So basically I always work with 5-10 issues from the top of the lists.

After that the list is scored using ICE-score methodology looking back at our North Star Metric. Every issue gets three values, each from 1 to 5:
I – Impact – how much the change will affect our KPIs, e.g. we expect that the change will improve the conversion rate by 1%,
C – Confidence - how sure we are that it will work, if we have a strong reason to believe in it, e.g. the feature is a market standard or results of customer surveys show that they suffer without this feature,
E – Ease - how easy/fast it is to implement the feature, how many hours of development we need.

Then we summarise all three values to get one ICE-score number for every issue. Then we sort issues by this score, take ones with the highest priority and take into development... well, almost.

Actually, if the issue has a highest ICE-score number it doesn't always mean that it'll be implemented in the near future. I'll come back to this soon.

Selected issues go to Jira, I assign them the "New development" type. All issues of this type are shown on our Kanban board.

In theory, everything is perfect – we plan ahead a quarter, selected issues go to the backlog column "ToDefine" where I try to keep around 10 issues. I take one at a time from the top, work it through with stakeholders. If needed - we do research, test a prototype, make a design. Then I define all the details for developers, move the issue to the "ToDo" column where I try to keep not more than 5-7 issues in order to see all of them on one screen. Guys take issues one by one, move them to "InProgress" and then to "Done".

However, in real life not everything is that linear. Sometimes issues in "ToDefine" column are reordered and/or something can creep in the middle. It's fine because the business is alive.

Plus, short-term planning requires considering A/B test queue. It's a bottleneck. I can test only one feature at a time and it takes 1-2 weeks. So the issues that need to be tested can go to production one after another with a 1-2 week interval. It doesn't make sense to deploy them more frequently - they'll simply get stuck in the queue. On the other hand, less frequent deploys are not effective because they would lead to the wasting of an expensive resource.

Sometimes it happens that one task blocks another one. E.g. we implement an advance search engine Elastic and until we finish it doesn't make sense to change anything in the boat searching process on landing pages. Sometimes the issue is blocked by external factors, e.g. marketing guys haven't prepared a content yet. We have to be agile, block the issue for now, reorder other issues in order to win time.

Sometimes it happens that an issue loses its relevance or its priority suddenly decreases. E.g. if we are not capable of implementing an Early Booking discount before Christmas – it doesn't make sense to do it at all until next season. It's better to focus on something else that brings value right now. If you do tasks only because "we promised to do it 3 months ago and still haven't delivered" - you are becoming a hostage of your promises, never deliver on time and always feel guilty.

By and large, I adhere to the following principles: