At the risk of losing half the readers, let me say something controversial: most items in your product backlog are useless.
After spending around 20 years working with digital products, we at yuj have realized that most items in product backlogs are of low value because they are added without proper validation or rigorous questioning. A product backlog is often treated as a dumping ground for features, driven by the whims and fancies of various stakeholders. This bloated product backlog has serious implications for Product Owners, clients, users, and the organization itself.
But it’s not all doom and gloom. A huge product backlog signals inefficiencies in the processes, so it’s an opportunity to improve processes and positively impact all the stakeholders involved.
In this article, we will cover –
- Implications of Product Backlog
- Factors leading to a huge product backlog
- Finding ‘hidden gems’ in product backlog
1. Implications of Product Backlog
Consider the plight of Michael, the Chief Product Officer at a large enterprise. As he glances at his JIRA interface, he sees 263 pending items. His team feels demotivated by the constant additions to the backlog. They are also fed up with the relentless tight deadlines they can never seem to meet.
Michael’s vision for the product has gone for a toss. The product is now bloated with features, and with the pending items, it will only get worse. The most disheartening part? Michael knows that most of the features they are developing will likely never be used by the end-users, leading to a significant waste of time, money, and effort.
“We are very busy. But are we making any meaningful progress?” is a question he asks himself.
Being busy vs. making meaningful progress
It’s not just Michael, though. 37.9% of product managers feel their backlog is disorganized. According to Pendo’s feature adoption report for 2019, 24% of features are never used, and 56% are rarely used.
Sadly, the Product team has KPIs such as “Product Backlog Size,” which measure whether the team has completed the action items expected in the backlog. This focus on vanity metrics like these forces Michael and his team to concentrate on staying busy rather than making meaningful progress. Instead of delivering value, they find themselves stuck in a cycle of completing low-value tasks just to show that they are moving forward.
2. Factors leading to a huge product backlog
A good question to start diagnosing this problem would be: How do we end up in this situation?
How do so many low-priority items make their way into the product backlog?
There could be many reasons, but I’d like to share the important ones we have encountered.
A. Low-quality user-research
This is the biggest culprit that allows low-value items to creep in. Without proper user research, we don’t have a compass to guide us. We lack a clear understanding of our users’ dreams, desires, and problems, leaving us directionless. Our product backlog fills up with features that don’t address real user needs, as we are merely guessing rather than making informed decisions.
B. Missing prioritization
As mentioned above, prioritization is a big problem. Without proper prioritization mechanisms, a large number of features end up on the list. This lack of prioritization leads to a bloated backlog filled with low-value items that do not align with the product’s strategic goals.
C. Stakeholder influence
Different stakeholders (executives, clients, team members) push their priorities to be added to the backlog. Often, these requests are accepted without thorough validation or alignment with the product strategy.
D. FOMO
A common reason for adding new features to the product backlog is the fear of missing out. Statements like, “Oh, our competition has added this new feature. We need to add it too!” drive many decisions. While sometimes this might be valid, in many cases, the competition operates in a different context than your organization.
3. Finding hidden gems in the product backlog
The world isn’t black and white. While I have criticized the huge volume of low-value items in the product backlog, one cannot deny the presence of genuinely valuable features within it that can make a significant impact and drive the product forward.
How do you distinguish between low-value items and essential features? Here are a few recommendations we make to our clients:
A. Interim User Research
One exercise that helps is going back to the users to understand their desires and problems. While this method might seem like an unnecessary hurdle that increases time and cost, investing in it is worth it. Interim user research gives you a fresh perspective and helps you see how many of the items in the backlog are actually low-value items disguising themselves as ‘important’.
This exercise realigns the project strategy and reduces the product backlog.
B. Rigorous Prioritization Mechanisms
If prioritization is the problem, how do we fix it?
We recommend our clients prioritize based on these parameters:
1. Monetization of the business
How much will a particular feature contribute to the client’s revenue?
2. Usefulness to the users
How useful is a particular feature to a user, and how will it impact their life?
3. Wide applicability
How broadly applicable is the feature across the user base?
C. The two-track approach
Introducing a two-track approach can balance immediate development needs with long-term strategic goals. This method involves maintaining separate tracks for ongoing development (Track A) and backlog management or exploratory work (Track B).
Track A (Development Track): This track focuses on implementing features that have been prioritized and are ready for development.
Track B (Exploratory Track): This track is dedicated to user research, validation, and grooming of backlog items to prepare them for prioritization and eventual development. The two-track approach helps in ensuring that we don’t miss out on anything critical.
To Summarize:
Most items in the product backlog are low-value items that wouldn’t make any meaningful contribution to the product. A huge product backlog is often a sign of inefficient processes, especially in the research phase. It has implications for team morale, product quality, and, ultimately, the resources needed by the organization.
We can use interim user research, rigorous prioritization mechanisms, and the two-track approach to fix this issue and uncover the product features that would genuinely add value.
