We’ve all seen them. Product Backlogs that are long, unruly and chaotic. Untameable beasts that everyone from the Product Manager to the Development team prefer to avoid. Such Product Backlogs create a sense within teams that no matter what you do, you are actually not making any progress towards your goals. You end up not sharing the backlog with anyone else because the mess is embarrassing and you know that only you will (somewhat) understand it, creating a thorough lack of transparency and alignment within the company. You as Product Manager (PM) or a Product Owner (PO) have completely lost track of what’s important because of the sheer mess in your backlog and so you’re winging it when it comes to prioritization.
Sound familiar? That’s because it can happen to even the best Product teams, however if this sounds like your backlog, you need to take action as soon as possible. Having a well-organized and groomed Product Backlog is a non-negotiable if you want to be able to prioritize strategically and efficiently.
Below are 3 strategies to help you regain control over your Product Backlog:
1. Become a Gatekeeper
Though the Product Backlog should be accessible to anyone in the company, it is not for anyone and everyone to edit. In any Product organization, the PM/PO should be the gatekeeper of the Product Backlog. Having one person responsible for managing the backlog ensures that everything that is added is done so in a standardized and consistent way and that there is not duplication. Essentially, you are making sure that the ‘mess’ isn’t created in the first place.
This does not mean that you should limit input into the Product Backlog. In fact, as a PM/PO, you should welcome diverse ideas from as many sources as possible from the Development team to the Marketing or Customer Care team. However, you should create a process through which ideas can be added into the backlog only after your review.
One way to do this is by having team members fill out a form to submit ideas for review. The form should contain certain key pieces of information, like what type of impact that idea is likely to have (ie is it a revenue generating idea, or a retention increasing feature?) and whether that impact can be quantified in any way. For quantification, you can ask for a case study or research that shows how a similar feature impacted another company, or even whether they think the impact of the idea would be high/medium/low. It would be overkill to ask for a full-fledged business case at this point, and the idea is not to create such a complicated and drawn out process so as to deter people from submitting ideas. However, you want to make sure that ideas that are submitted have been well thought out before they end up in the Product backlog.
Once you receive a well fleshed out idea, you can go ahead and add it to your Product Backlog.
2. Categorize each item in your Product Roadmap
Items within your Product Backlog should be labeled & categorized in a way that gives the reader all the important context around that idea, within one glance. Teams can use different combinations of labeling, depending on their needs, however the most common labels or categories that are generally attached to each backlog item are the following:
- Time horizon: will this feature be prioritized within a certain time period (this quarter, this year, etc) or not?
- Topic or Product area: is this feature related to the Checkout flow? Or is it related the Search functionality?
- Goal: How will this feature move the needle? Will it impact revenue, conversion rate, retention or any other metrics?
- Impact score: is the impact generated by this feature likely to be high, medium or low?
You should not have to read a detailed description of a backlog item to understand the context, priority or impact of a backlog item. Instead clear categorization using the above labels can help give users all the information they need in a quick, scannable manner. The Product Backlog should also ideally be filterable and searchable using these labels. Filtering and search functionality should be available regardless of where your Product Backlog lives, whether that’s a Google spreadsheet or a roadmapping tool like Aha or ProductBoard, though these tools certainly make organizing and sharing your Roadmap much easier.
3. Integrate Product Backlog Maintenance into your Process
Create processes and rituals that ensure your Product Backlog stays organized. For example, it should be a regular part of your routine to groom your Product Backlog at least once every 2-4 weeks. It may be overwhelming at first, however the more often you do this, the less time it’s going to take you. You should regularly be removing ideas that are no longer relevant (ie ideas related to features that have already been killed or legacy code that no longer exists).
Ideas should also be regularly moving from your backlog into sprints. If an idea is in a sprint and your Product backlog at the same time, your process has broken down somewhere. However you choose to manage your ongoing tasks, it should be clear to everyone in the company which tasks are in progress and which are not.
It’s also important to have a process around bugs. There’s a debate to be had around whether bugs should be a part of your Product backlog or not and there’s no right answer. From the customer’s perspective, whether it’s a bug or a missing feature that prevents them from achieving a specific outcome is irrelevant, which points us towards storing both in one Product Backlog. However, from the perspective of users inside the business, a long list that contains bugs or defects with existing functionality and also a list of new features can be very confusing and extremely difficult to manage. I have always been on the side of storing bugs in a separate list from the Product Backlog, and having a set process around how much time per sprint will be dedicated to new ideas, and how much time will be dedicated to bugs and/or technical debt, in which case every sprint will have two sources of input, the bugs list and the Product Backlog. However if this is not the case, then at the very least, bugs should be clearly labeled as such in your Product Backlog.
You should also be splitting your backlog into multiple backlogs, if required. For example, if you are working as a Product Manager at a very large company that has several Product areas, then you should be maintaining a Product Backlog for each. It’s pretty hard to imagine a company like Apple for example, having all of their ideas (and bugs…shudder) in one backlog.
__________________________________________________________________
The key thing to remember is that Product Backlog management is not a one-time task but an ongoing process that requires diligence and consistency. Following the above strategies will ensure that your long, but organized Product Backlog becomes an asset that works in your favor and helps you to prioritize strategically and effectively, rather than an embarrassing mess that you hide away from the rest of the company.
__________________________________________________________________
I’d love to know your thoughts on the above strategies! If you have any questions or feedback, let me know by leaving a comment below.
For more strategies around effective Product Backlog management and prioritization, take my course!
Leave a Reply