Optimise your Backlog Prioritisation with Product Goals and Strategy

Managing and prioritising the Product Backlog is one of the crucial tasks of a Product Manager, yet it’s often fraught with challenges. Within an agile environment, the Backlog emerges as a meticulously ordered list of Product Backlog Items (PBIs), representing the team's pending tasks. These items span various categories, with new product ideas, bug fixes, and enhancements ranking among the primary types. In this blog post, I will be zooming in on new products ideas. The goal? Introducing a fresh take on prioritisation, one that comes with clear benefits.

Why prioritisation?

Let's start with an obvious truth: your company's time and resources are limited, so it's crucial to use them wisely. Often, the amount of work waiting to be done far exceeds what your development team can handle at any given time.

The natural response is to prioritise those product ideas based on the value they bring. However, things get tricky in complex environments with multiple stakeholders. Each might have their own idea of what value means.

Numerous prioritisation frameworks exist, including (R)ICE-framework, Kano model, Moscow, etc. However, despite their popularity, they come with their own set of drawbacks when put into practice.  

• While these frameworks rely on formulas with quantitative factors like future revenue, estimating these factors can be tough. Different estimators may assign different priorities, offering a false sense of security.
• Furthermore, these frameworks often fail to provide clear reasoning behind why a certain idea was prioritised. This becomes problematic when the Product Manager needs to communicate these decisions to various internal stakeholders such as executives, marketing teams, and development teams.

A better approach

What I prefer is a framework where the Product Manager prioritises new product ideas based on the overarching Product Strategy and specific product goals. While numerous authors and practitioners in Product Management have discussed this framework, Roman Pichler stands out as a key figure in advocating for it.

Now how does it work? There are 4 levels: each level becomes more concrete and has a shorter time span as you navigate from top to bottom. Let’s dive in!

Let’s start with the Product Vision. The Product Vision is a short, inspirational statement that explains how our product benefits users. It remains valid for years and guides our work with a sense of purpose."

Google’s vision is “to organise the world's information and make it universally accessible and useful, empowering people with knowledge.” And Amazon’s vision is “to become Earth’s most customer-centric company, providing customers with the ability to easily find and discover anything they might want to purchase online."

On the next level, you find the Product Strategy. The Product Strategy details the company’s actionable plan to achieve its vision over the next few years. It includes specifics such as the company’s unique value propositions, target customer segments, potential risks, and more.

Prioritising ideas in alignment with the Strategy ensures that the product delivers substantial value to customers and has a greater chance of fitting well into the existing market. This, in turn, increases the likelihood of user adoption and success. While strategy is briefly mentioned here, it's a broad topic that could be explored in a separate article."

The third level is the Product Roadmap, which typically spans one year and provides a visual, high-level overview of upcoming developments for the product. Traditionally, the roadmap consists of a list of specific features, that limits flexibility or agility.  

In this alternative approach, the Product Manager commits to achieving a set of Business- and User Goals by specific milestones. The understanding with company executives should be that the product team has the autonomy to create and roll out features iteratively.

When evaluating a new idea, the product team considers how well the new product aligns with the strategy and how it will help us achieve the goals we've committed to for our users."

If the team discovers a better or more cost-effective idea to achieve a goal along the journey, they should have the flexibility and autonomy to pursue this new idea. Ideally, the product team also uses concrete metrics, such as KPIs or OKRs, to track the product's success and make necessary adjustments.

As we delve into the product backlog level, it becomes acceptable to be specific and enurate the actual features. In an agile way of working, these items may be termed as Epics or User Stories, depending on the granularity of the work in your Backlog.

Actually, the backlog doesn't aid in prioritising new ideas; instead, it reflects the outcome of our prioritisation efforts.

Advantages of the framework & final takeaway

Firstly, the prioritisation framework based on the Product Strategy and concrete product goals offers a clear rationale for decision-making. This clarity simplifies the communication of priorities to stakeholders and nurtures a shared understanding of why certain product backlog items are prioritised over others.

Secondly, it empowers product teams to make more autonomous decisions. During the refinement of a specific user story, analysts and developers can opt for implementation choices that best align with the goal. The same principle applies when making UX design choices.

Finally, by applying this approach, your company can avoid the pitfall of becoming a Feature Factory, where quarterly success is solely measured by the number of features or story points delivered. In contrast, the teams are directed towards achieving outcomes and goals established by the company. This enables product teams to consistently deliver the appropriate features, addressing user problems and enhancing their experiences, thus enriching their lives!

Interested in discussing what you just read further? Let's chat! Feel free to connect with me on LinkedIn.