There are two types of people: those who maintain a zero-inbox email policy and those that let their inbox get out of control. And while the two may bicker on which system is best, there isn’t much of a difference when it comes to productivity.
When it comes to product backlogs, the zero-inboxers take the win. Product backlogs are commonly a dumping ground for every idea, story, feature request, bug fix and task related to product, and not surprisingly, they can become pretty unwieldy and difficult to manage if not handled properly.
But slimming down a product backlog is not as simple as addressing each item as it appears: Different items take varying amounts of time to address and have different levels of urgency. Built In talked with five companies on how they align their product backlog items with overall business vision and how that helps prioritize levels of importance.
Tips for Cleaning up your product backlog
- Know what problems you're trying to solve
- Prioritize projects with the highest impact
- Allow product team more ownership over projects, enabling more to get done
- Limit who can make additions to the backlog
- Utilize the RICE method
Alignable
Phillip McKee
PRODUCT MARKETING MANAGER
What parameters do you have in place to ensure your product backlog is manageable and that its items truly belong there?
It’s critical that we prioritize the projects with the highest impact. Our backlog system, housed in Notion, keeps us on task and in the groove. We created templates for our backlog cards so anyone from any team can fill them out. The templates force the creator to dig deep into their idea. They perform research and chat with team members so we can justify and prioritize the work at hand, which keeps the backlog filled with fully-fledged ideas. During backlog grooming, we have all the information we need to make a call and get going.
Throughout our product planning process, we bring stakeholders in every step of the way.”
How do you prioritize the items that make it to your product backlog?
We look at all the potential work with stakeholders to decide what we think will drive us closest to our company objectives. The idea list is shortened to the highest impact items, then further fleshed out into what we call “epics.” Each epic gets its own team of engineers, product managers and product marketers. Since epics are so project- and goal-driven, prioritization comes easy through a biweekly grooming meeting with the epic’s team.
How do you categorize backlog items?
For everything unrelated to quarterly epics, we empower everyone from all corners of the company to add tickets to the backlog. We take the ideas that need to be prioritized into a grooming meeting with stakeholders from product marketing, product management, customer support and engineering, and play a round of prioritization poker. Everyone is armed with a deck of cards and we score ideas based on their estimated size and impact. Then using a weighted shortest job first (WSJF), we divide the impact score by the size score, which results in a WSJF score and a stack rank of the highest ROI work.
What stakeholders do you include in the backlog prioritization process?
Throughout our product planning process, we bring stakeholders in every step of the way. First and foremost, at the beginning of each quarter, the whole team is involved in what initiatives the company focuses on. Then, we have kickoff meetings with all the stakeholders to decide how we’ll measure success and get there. These stakeholders typically include the team that will be doing the work, members of the executive team and anyone relevant to the work being done.
We also have everyone on the team give weekly TL;DR (too long, didn’t read) updates on what’s happening in their neck of the woods and invite comments and suggestions.
Beyond Finance
Shaila Kuchibhotla
VP PRODUCT MANAGEMENT
Kuchibhotla and her team at Beyond Finance follow the RICE method for prioritizing product backlogs. At the fintech company, each item in the backlog is attached to what business objective it will later solve, which then determines importance.
What parameters do you have in place to ensure your product backlog is manageable and that the items on there truly belong there?
As an organization, we’ve defined a set of key business objectives to assess what’s important. Every feature request or idea that the product team gets is evaluated through the lens of customer experience and how it ties to those business objectives.
We’ve also streamlined our intake process to allow the product team more ownership over what work gets done and when. Requests from stakeholders are organized in a single place and reviewed by the product team on a regular basis to decide what gets added to the backlog.
Throughout the process, it’s important for the product team to consider what problems we’re trying to solve or what outcomes we’re trying to achieve with each change we make, and how that ties back to our business objectives.
How do you prioritize the items that do make it to your product backlog?
We are working towards leveraging the RICE framework for product prioritization.
For each item in the backlog, we outline the primary business objective we think it will impact and assess the following factors to determine priority.
THE RICE FRAMEWORK
- Reach: How many users will the feature affect in a given timeframe?
- Impact: How much of an impact will the feature have on users or business objectives (e.g. low, medium, high)?
- Confidence: How much confidence is there in the estimations of reach and impact? (i.e. Is there data to support these numbers or is it more intuition?)
- Effort: What level of product, design and development effort is needed for this feature (e.g. low, medium, high)?
What other stakeholders do you include in the prioritization process, and how do they help inform decisions around what to prioritize and when?
We work with marketing, sales, operations and legal to better understand their requests, the problems they’re trying to solve and the constraints they have. We also have a monthly roadmap review with these stakeholders to provide visibility to our product strategy and priority.
These conversations give our stakeholders the opportunity to review how we’ve prioritized things and discuss whether we’ve accurately represented things like reach or impact. They may present additional data to show that something is more impactful than we initially thought it would be, making the case that it should be a higher priority.
We also partner very closely with the technology team to evaluate feasibility for different features or ideas and discuss possible solutions to support the product initiative. This helps us get an accurate estimate of the effort required as we prioritize. Ultimately, the decision on priority is made by the product team — in alignment with business objectives — but input and feedback from other teams are important and help us build an effective product roadmap.
Inspirant Group
Sam Pourkermani
DIRECTOR OF DIGITAL TRANSFORMATION & PRODUCT DEVELOPMENT
To prioritize product backlogs, teams need to share an understanding of the business vision and company goals. At “unconsulting” firm Inspirant Group, Pourkermani said that business vision is defined by asking about customer and business needs, broad features and future business potential.
What parameters do you have in place to ensure your product backlog is manageable and that the items on there truly belong there?
To promote the goal of addressing a customer’s needs, while also aiming to deliver higher-quality products or new features faster than their competition, a product backlog should be comprised of three types of work.
First, product or “business” features and bug fixes that address specific customer needs. Second, enablement features, such as work needed to “enable” or support future business functionality or improve development and quality. And third, technical debt and maintenance, such as refactoring code and other activities that optimize agility and speed to market.
Teams can use their shared understanding of the broader vision and goal to continually optimize delivery speed to make decisions about what is appropriate for the backlog. In addition to having a clear and common understanding of the vision, a team also needs a mechanism and process to manage the filtering process. Tactically, a team can use a Kanban board to implement a set of policies to govern the decision-making process used to filter which items get added to a backlog. Attention should also be paid to regularly balance the backlog with an appropriate amount of product features, enablement features and technical debt work to optimize ROI and maintain agility as well as high performance.
How do you prioritize the items that do make it to your product backlog? Do you use a specific model or method for categorizing and prioritizing these backlog items?
Though we vary and adapt prioritization methods based on the context, we always ensure the approach brings objectivity to the decision-making process.
One method that we frequently use and recommend is to sequence work to optimize economic outcomes. We tend to prefer this method because of three reasons: time is a non-negotiable resource; resources are generally finite or limited, such as budget or people; and third, the primary goal is to deliver the maximum value and quality to customers in the shortest sustainable timeframe.
In practice, we use a formula to calculate the value-to-cost ratio of each item in the backlog relative to the rest. For cost, we use the story point of the feature. For value, we use a combination of the following three elements: assumed financial benefit of the item, timing impact and context.
The key is to determine the value of each item relative to others in the backlog. This approach is very similar to WSJF (weighted shorted job first), but we adapt it based on our context.
What other stakeholders do you include in the prioritization process, and how do they help inform decisions around what to prioritize and when?
Our rule of thumb is to always collaborate with three groups of stakeholders: those who are most knowledgeable about the value of the features being prioritized; those who are most versed in the value of enablement features; and those who are closest to the effort of the items.
Each group enables us to determine both the value of a feature as well as its cost. This, in turn, enables us to calculate the value-to-cost ratio for each feature in order to sequence them to optimize economic outcomes.
Flatfile Inc.
Flatfile is looking to bring on more engineers this year, but as a lean team, Head of Product Randy Wiafe emphasizes the importance of prioritizing certain product features based on the effort they take to build. In order to do so, Wiafe said employees rely on the RICE framework, using impact, effort and greater-goal alignment as parameters for reducing backlog.
What parameters do you have in place to ensure your product backlog is manageable and that the items on there truly belong there?
We first ask ourselves what problem we are trying to solve. When it comes to product development, it shouldn’t be about individual feature requests. Looking at requests through the lens of the problem that has been identified helps narrow down the backlog.
We also think about our overall North Star goal, which is to create a one-click import solution. Will this feature or request contribute to that overall goal? We can use that goal to help determine if an item should truly be in the product queue.
Those four factors help product managers determine the features that should be included on the roadmap.’’
How do you prioritize the items that do make it to your product backlog?
At Flatfile, we like the RICE method to help us evaluate and prioritize backlog items. The RICE method stands for reach, impact, confidence and effort. Those four factors help product managers determine the features that should be included on the roadmap.
We typically pay closer attention to impact and effort. As a relatively small team, we want to prioritize features that will have the biggest impact on our customer base or potential prospects. If we can develop a feature that will pull in more potential prospects to take a look at Flatfile, that should be prioritized. A small team means we’re stretched thin. And while we’re hiring more engineers in 2020, we need to think about how much effort it will take to build a certain product feature.
What other stakeholders do you include in the prioritization process, and how do they help inform decisions around what to prioritize and when?
Several team members are involved in determining product priorities. I talk to our customer success department weekly to better understand our customer base and determine how big of a priority a feature needs to be to keep customers happy and engaged with the product. I also need to understand the customer use cases, as those tie into product requests.
I talk to sales team members to get a sense of the requests coming in from prospects. Are there patterns? Are there product features that could more easily move deals along? Engineering employees obviously need to be involved in order to properly scope out time commitments. I frequently involve our CEO to talk through priorities with him.
IntelePeer
Senior Product Manager Shaughnessy Speirs has noticed that fellow professionals in her field can be easily frustrated by the inevitable backlog software development creates. But Speirs herself believes that the mess can be generative, if monitored closely. At Intelepeer, Speirs said she moves projects to the backlog only when she and her team are sure they want to explore them further.
What parameters do you have in place to ensure your product backlog is manageable and that the items on there truly belong there?
My backlog definitely gets messy, which I don’t think can be completely avoided. At the beginning of 2020, I essentially declared backlog bankruptcy by starting a new Jira project and archiving the old one. Software development is a messy business. That often frustrates product managers, who tend to want to make chaotic things orderly. But I believe that the mess can be generative. The key is to tend to it. Regularly fertilize it with good ideas and new details and pull weeds.
I’m always trying to get better at it, but I generally don’t think it is a good use of time to over-index on keeping the backlog orderly.
That said, I do think it is good practice to limit direct access to the backlog itself. Instead, gather good ideas through a separate channel and move them to the backlog only when you want to explore them further. We don’t have an open backlog. I collect the ideas myself through conversations, emails and support tickets that get referred to me. At some point soon, we will open up a feature intake form so that we can collect specific details about the use case and the value.
Software development is a messy business.’’
How do you prioritize the items that do make it to your product backlog?
My favorite framework to use for prioritizing is a simple value-complexity matrix (also called impact/effort) that graphs items visually by value and complexity into quadrants that become “do now,” “do next,” “maybe do,” and “don’t do.”
I don’t think you really need to use a framework to do this. At IntelePeer, we are constantly calibrating on business or customer value and engineering or design difficulty in real time.
User story mapping is another valuable exercise I’ve used to dissect a big, abstract problem into activities and finally, stories. Prioritizing iterations focuses our efforts and allows us to create a thin slice of functionality across the entire breadth of a problem.
What other stakeholders do you include in the prioritization process, and how do they help inform decisions around what to prioritize and when?
Customers are the most important part of the equation. We try to talk to our customers directly as much as possible. But as an enterprise B2B product company, we also depend on our sales and customer success teams to help us understand what problems our customers are facing. How much will this feature reduce the time that agents spend on the phone? How much will it reduce the time it takes to build or change our communications flow? How much will it improve the usability of our phone menu or our SMS chatbot from an end-customer perspective? We want to look at how the feature will impact our customers’ ledgers and their customers’ happiness.
Of course, complexity is an important part of the development equation. We call on teams like development, engineering, security, legal and operations to understand what it will take to architect, build and launch a secure and compliant offering. All of these factors inform whether and when we choose to take on a project.
