The types of Product Backlog friends knocking at your door — and how to greet them

Stephen Carrey-Chan
6 min readJun 2, 2023

Company growth stage matters

The bulk of my product management career has been with technology companies in the scale-up stage, and my biggest gripe with the majority of the product books and articles out there romanticizing the “right way” to go about product development is that they fail to address how to effectively adapt and compromise these academic product principles based on the growth stage of the company in order to yield successful results. Too often have I seen a bright-eyed and bushy-tailed PM join a new team and preach how product gets done, reciting the Marty Cagan and Melissa Perri’s of the world (younger me is guilty of this), only to get rejected like some foreign entity from the organization’s immune system. This is why I personally loved Michael D. Watkin’s “The First 90 Days” so much — he addresses the different types of environments an employee can step into, and how to adapt their 90-day strategy accordingly. That mindfulness of the stage (and its correlated cultural environment) is huge.

“The 20 Most-Read Books by Top Product Managers” from the Product School, 2023
“The 20 Most-Read Books by Top Product Managers” published by the Product School (March 2023)

My goal with this article on product backlog intake categories is to help guide product managers on how to mindfully manage and execute against their product backlog in the scale-up environment. This breakdown won’t cover 100% of all scenarios in a generalized format (maybe not even 50%), but I hope this conceptual layer of the kinds of ideas and requests that can land on your backlog from every direction will help inspire the actions you take when pulling a project from backlog to roadmap execution. With the right mindset, any reluctance can turn into an eager embrace of the backlog candidate, maintaining a strong sense of ownership and ready to play an active role in the project’s success.

“Hey, I know you. Come on in!”

Backlog candidates come in all shapes and sizes

One thing I know about scale-ups is that they vary in terms of their familiarity with more contemporary product management and their inclination towards product-led growth. You may have senior leader stakeholders who think it’s their job to come up with the solution for what the technology should solve for the customer. Your researcher or designer may have uncovered a compelling opportunity worth exploring from a series of user interviews. You might be the new hire PM and just inherited a multi-phased whale of an initiative to help drive home. My point is that there’s no one shoe-size-fits-all approach to handling these different incoming candidates that you accept into your backlog.

My point is that there’s no one shoe-size-fits-all approach to handling these different incoming candidates that you accept into your backlog.

When trying to apply a universal discovery approach on different backlog priorities

Types of backlog candidates (and PM expectations)

We’ll start with covering four common kinds of backlog candidates with this first batch (based on popular demand, I can share more in another article). Understanding the type of backlog candidate you’re considering can help align you with your product director/executive and close partners on the expectations of how you’ll add value and approach the prioritized candidate as a product manager, staying true to the mantra of maximizing business outcomes with your finite time and resources.

Candidate #1 — New problem & needs further validation

  • Candidate has been vetted at a high-level by your senior product leader (or you) and they have determined that there are sufficient business/customer signals that warrant looking further into to help the team determine whether the problem is valid and/or worth solving now.
  • This is the first time you’re seeing this problem in your product backlog.
  • The initial requestor or your leader may or may not already have some proposed tactics for your consideration/testing/analysis. This is completely fine. Unless it’s clearly articulated, do not take these proposals as prescribed mandates.
  • If the problem is disproved with convincing evidence from your deeper investigation, you should escalate these findings to your senior product leader and the initial requestor with your recommendation to hold off.
  • If the problem is validated from your efforts, you can take the problem further into evaluative discovery and solution experimentation with your cross-functional product team.
  • The saying “prioritization is about choosing what problems not to solve” is what this backlog candidate is all about.
  • Possible outcomes: Problem disapproved → hold, problem validated → prioritized, problem refined → pivoted approach
Tim Herbig does an excellent job articulating how to prioritize problems based on multiple factors.

Candidate #2 — New problem & needs discovery

  • Candidate has been vetted at a high-level by your senior product leader (or you) and they have confirmed the root causes of the problem(s) with substantial business/customer evidence that warrants further discovery on how to effectively solve the problem.
  • Put another way, the candidate has gone through problem discovery and is now at solution discovery.
  • This is the first time you’re seeing this problem in your product backlog.
  • There may or may not already be some proposed solutions or approaches from stakeholders for your consideration. Again, unless clearly articulated, these should not be interpreted as prescribed mandates on your part.
  • You and your cross-functional product team are strongly encouraged to think of other options to consider.
  • Possible outcomes: Validated hypothesis → scope definition, no actionable findings yet → warrants further exploration or a priority pivot
A really nice depiction from Tim Herbig on the Product Discovery process.

Candidate #3 — Defined subsequent work of larger initiative

  • Candidate is a pre-defined subset of a larger set of work. The problem validation and discovery has already been done with sufficient team, customer and stakeholder buy-in and support.
  • If you were not part of the initial conception and definition of this project, you are still encouraged to clearly articulate the specific problem/opportunity, the desired outcomes, and why this subsequent milestone is worth prioritizing sooner over other trade-offs.
  • You and your cross-functional product team are strongly encouraged to continue to test the project’s concepts against real customers to keep mining additional insights that will help refine your scope and approach. In the off chance, you may come across some unexpected findings that are worth escalating to the senior stakeholders.
  • Possible outcomes: New learnings → adjust / pivot scope, no new learnings → proceed with the current execution plan

Candidate #4 — Pre-determined company commitment

  • Candidate is a major company bet and investment to make something happen and will involve (or is already involving) multiple cross-functional teams in this big effort.
  • Your PM focus should now shift your mindset towards adapting and integrating with the “moving train”. Become a team player and help however you can to steer this train to the best possible future.
  • To help steer, the PM role should continue to be customer-focused with clarifying the real problem to solve or goal we’re trying to achieve, maintaining strong alignment across parties on that goal, identifying and mitigating risks, and maximizing finite resources through targeted scope and containing timelines.
  • Possible outcomes: Plan looks good → proceed with current execution plan, plan has some gaps/unknowns/assumptions → define mitigation tactics, clarify objective → refine scope to be more targeted against objective (shorter timeline & feedback loop).

Concluding (for now…)

If you’re a seasoned product manager who’s also been out in the field of the scale-up environment, what do you think about these backlog candidate categories? I’d love to hear your take and feedback.

The recommended mindsets and actions are intentionally kept vague for the product manager to determine how they might tactically go about ingesting and executing against a backlog candidate that they’ve prioritized with their team. Now that you have some names to put to some of the product requests that hit your doorstep, you’ll start to develop your own style and approach handling these different guests.

Did you like this post? Follow me now to see more stores like this — including my future article on the product brief to help product managers understand and exercise ownership over the problems and opportunities presented to them from various sources. I constantly seek to learn, so comments and feedback always welcome.

--

--

Stephen Carrey-Chan

Director of Product, Growth @ The New York Times Wirecutter || +12 years in product management experience