At the beginning of 2020, Senior Product Manager Shaughnessy Speirs said she essentially declared “backlog bankruptcy.” Doing so involved a task that many in her position might consider cathartic, stressful or both: starting a new Jira project and archiving her old one. Product backlogs are notorious in tech communities for becoming dumping grounds for certain requests across a business, leaving PMs with organizational to-do lists on top of their day-to-day work.
Speirs believes that fellow product managers and engineers should be more open to letting a backlog, well, exist. Instead of losing sleep about organization, she prioritizes certain feature requests in a few different ways. First, her team at IntelePeer limits direct access to the backlog itself, allowing employees to see only what has been agreed upon as most important. Second, she relies on large-scale frameworks like the value-complexity matrix, which shows the potential value of a product feature alongside the complexity of implementing that feature. It’s a method that Colorado-based Head of Product Randy Wiafe also uses and recommends.
At data importer Flatfile, Wiafe measures a task’s importance in terms of its overall reach, impact, confidence and effort, as outlined by the RICE framework. Within that measurement, which plots risk and reward in a similar structure, Wiafe further prioritizes impact and effort to maximize efficiency.
“As a relatively small team, we want to prioritize features that will have the biggest impact on our customer base or potential prospects,” Wiafe said.
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.
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.
