What is a product backlog?

The Product Backlog is a list of all the features that you need and acts as the only source of product demand changes. The product owner has to take care of the content, availability and priority of this to-do list that we call Product Backlog.

The backlog is a list which is continuously updated and maintains only the preliminary and well-known requirements. It evolves based on the product development environment. The factors that affect the backlog are changes in relevance, competition, and market shifts. Backlog can have list of features, use cases, user stories, improvement, and bug fixes made to future releases.

A product backlog is a list of tasks required to meet the strategic plans of the product road map. The backlog is about turning that sky-high thinking into actionable tasks, including how-to and by whom. While the product roadmap is big-picture, presenting high-level goals and strategies intended for a CXO audience, a product backlog is the nuts and bolts to-do list, writing (arguably) for those who carry out the bulk of the work — product and development teams.

What is product backlog tasks?

Product backlog tasks can vary a lot across teams. Those following scrum may refer to ‘user story’. This puts product backlog tasks into the perspective of the end-user. For example:

“As a (user type) I want to (what they want to accomplish) so that I can (the result they want to achieve).”

However you frame them, product tasks can include:

• Bug fixes
• Feature and Infrastructure updates
• New features
• Updates to existing functionalities
• Reducing technical debt
• Refactoring

Why prioritize your product backlog?

The problem with product roadmaps is they are not meant to be conclusive. It should be flexible to change according to other things which are happening. For example, a new product enters market and you might want to complete some feature earlier than expected to combat the competition.

Such prioritization can also happen around events such as conferences where some features would be essential to have.

But the challenge is when tasks keep getting pushed below the list, and the product manager struggles to review and organize them in relevance and priority. A good product backlog should be well-structured, organized for ease of understanding, and aligned to the company’s strategic needs.

Techniques for prioritizing your product backlog

1. Impact-effort matrix

In the impact-effort matrix you plot the tasks on a matrix with two axes – effort and impact. It’s a good exercise where you can involve stakeholders as you get an opportunity to pit the different priorities against each other.

2. Stack Ranking

In stack ranking, you take the list of items and rank them from most important to the least important (bottom of stack). The major advantage here is you are always delivering the best value and your team’s focus is also not wasted on low value effort. And another benefit is the ease of using this approach. But like everything, there are some downsides – your priorities will almost always be determined by intuition.

3. The MoSCoW method

The MoSCoW method is best used for prioritizing things in terms of High/Medium/Low

These can be classified as:

• Must have: these are critical tasks which are ****essential to the current delivery timeframe to be successful. If even one ‘Must-have’ requirement is not completed, the delivery is considered a failure.
• Should have: Important but not essential for delivery.
• Could have: these tasks are good to have but not necessary and are to be prioritized once other things are completed.
• Won’t have: these are the least important tasks.

‍The downside of MoSCoW method is that it doesn’t help you choose if you, for example, have three tasks in the ‘Must have’. Plus, it’s easy to see new builds prioritized over refactoring if refactoring is always delegated to the ‘could have’ or ‘won’t have’ categories.

4. Weighted Shortest Job First

The weighted-shortest-job-first’ (WSJF) method is used in agile to prioritize tasks based on the lean product development principle. This is achieved by figuring out the Cost of Delay by the time taken to complete the tasks.

There are different mathematical ways to frame this, but think about what a company will lose if something is not completed. The task that if not done results in the most significant loss — this could mean financial and reputational, loss of subscribers, an inability to upsell a related product or bottleneck such as a task delaying multiple releases. There will be some subjectivity, but perhaps less than trying to understand what task is the most important to whom.

Quantifying cost of delay can be challenging. Those good at it consider how cost of delay changes over time. They commonly use these standards:

Linear — For every day we do not deliver, we lose some money. A common example of a linear cost of delay is money lost due to competitors already having a feature that you don’t.

Fixed date — If we don’t deliver by a certain date, it’s too late. An example: let’s imagine you’re making New Year cards for 2019. If you don’t deliver them before the end of 2018, the cost of delay is very high. In fact, delivering afterward, in January or February, makes no difference — it is too late!

Intangible — We can delay for now at minimal cost, but eventually it could become expensive. A good example is the cost of delay for fixing a few bugs or refactoring your code. You can skip today, but over time it will make other improvements more expensive and can cause the cost of delay to increase exponentially.

Expedite — It must be done immediately or the cost of delay will grow radically. An example of an expedite feature is a severe bug that renders your product useless to all your customers.

The cost of delay categorization will often give you a good idea of what should be done first.

5. Prioritize based on context

One of the easiest ways to understand user behavior, including user flows and user pain points is data. By analyzing data like hours spent on development of certain tasks, quality issues and value created, you can do prioritization. This model is only recommended if you have a good understanding of the problem and your users.

6. The Kano model

Under the Kano Model, features are categorized based on needs and expectations of users. There exists different versions of the Kano model. The original, categorizes items using five thresholds: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse.

Must-Be – These are expected by your users. These are features that won’t WOW them. They are taken for granted.

Attractive – These features make users happy when included, but do not disappoint them even when not present.

One-Dimensional – These are the features that make users happy when present, and also unhappy when not found.

Indifferent – These don’t have any impact on user’s satisfaction levels. An example is refactoring parts of your code so that it’s easier understand. This has no direct value to the user, but it will make life easier for your team in the future.

Reverse – These features make users unhappy when included, and happy when not included. An example is, you may implement high-security features requiring an extra step to login. If your users do not value the enhanced security, they might find it annoying.

Templates of Prioritization Frameworks

1. RICE (https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/)
2. Value X Effort (ask team to write)https://hygger.io/blog/lean-prioritization-approach-ongoing-pm-issues/
3. MoSCoW (Add a list and change value) Give users feature and they can drag drop (https://www.productplan.com/moscow-prioritization/?ref=https://product-frameworks.com)
4. Weighted Scoring by Own Criteria (https://danielelizalde.com/product_management_scorecard/)
5. ICE (https://blog.growthhackers.com/the-practical-advantage-of-the-ice-score-as-a-test-prioritization-framework-cdd5f0808d64) (https://university.hygger.io/en/articles/2288376-ice-scoring)

Further reading

1. https://medium.com/hackernoon/6-prioritization-techniques-to-make-you-stop-working-on-the-wrong-stuff-646cc6429edc
2. https://productschool.com/blog/product-management-2/prioritization-techniques-product-managers/
3. https://zapier.com/blog/prioritize-task-list-methods/

Conclusion

If your product backlog tasks are turning into a long queue, it’s time to apply some prioritization techniques. Like we discussed, there are different ways to go about prioritization. And no, prioritization is not a perfect science, but what’s important is to get started. With some practice, you’ll discover which method or combination of methods work best for your product, team, and market.