Product Backlog Problems: Why Your Hierarchy Is Broken

I'm making a point to be careful what I allow into my backlog. If realistically we're not going to do it, it doesn't belong in the backlog. There are a lot of things I want to do that are not in the backlog because I know realistically they're just not worth it. Even with AI where you are not using your monthly token allowance, there are still a lot of things not worth doing.

Just this week I was thinking about an idea that would improve builds, let's do that refactoring. However, as I started looking into the amount of work I would require to get it done, I realized that, yes, it would be an improvement to our builds, but the cost of getting the work done is greater than the improvement is worth, and so I'm not going to go forward with it. It's too bad there are a number of annoyances that I'm going to be living with because it's not worth fixing. But that is the reality of life. I need to do things that will ultimately satisfy our customers that keep coming back and paying us more money.

Just delete stuff you’re not going to do.

A strong whiff of AI writing.

This is an ad, so it's going to be fluff, but the example use cases really stood out to me as not being very real/practical.

Right off the bat: It assumes the team has a cluttered and completely unmaintained backlog already. Even with an unmaintained backlog, Jira and other tools already have great built in tooling to help a backlog stay visually clear (priority indicator, epic tag, and the ability to make placeholder sprints for work at certain levels). The sprint planning convo suggests that the team (engineering, qa, stakeholders, more) all have a say in determining priority of the work in every sprint planning session. Where is the PM in these calls? The PM/PO brings the "what" to sprint planning. If this cycle is happening over and over again, the Product team member is weak and being given too much of a pass. The team is likely frustrated over lack of direction.

Getting into the core premise of the flight levels approach. The 3 flight levels just decompose into a backlog that can still be large, which results in the same issue this tooling set out to solve. The 3 flight levels also don’t make it very clear for stakeholders on what the team’s actually going to deliver soon vs later. That is because this model still has everything the delivery team will do just boiled down into the backlog. It's not all bad though, the priorities and value of items will be clearer. The sprint planning sessions should go more smoothly. Finally, the 3 flight levels just make me think of the common format: epic > story > task. The flight levels don't feel like any improvement on the trusted product discovery and delivery loop. A simple period for spiking and then implementing (then looping back to iterate for improvements). Discovery is for validating ideas (spikes), prototyping, proving value, defining what to be done. This discovery work is tracked at the epic level and presented in a board or jira plan on a Gantt chart. As work becomes defined, it is broken down into stories and tasks, prioritized, and moved to the backlog. Easily allowing the team to know what to execute on next.

The team in the example seems to only be able to focus on one topic at a time. Either auth or button colors. I’ve yet to find a team that can’t handle multiple priorities (fitted into capacity of course). The team may differ from what the business wants to do. This can be solved by structuring sprint capacities around percentages. Eg 75% is for attacking the roadmap (items from discovery) and then 25% for what the delivery team identifies as necessary (like button colors). I’ve found this to be effective at ensuring a team can predictably move business work forward while also carving out time to handle infrastructure or other improvements and bug fixes that don’t normally get considered at the leadership level.

The fact is, that an organization/team that cares this much about organizing their backlog already has a solution in place.

Don’t get me started on Marty Cagan’s ideas. The practices are the fastest way to burnout for a product team. Big CEO minus all of the power and reward, but all of the responsibility energy.

This is more a critique of the article and less of the product, which I don't know anything about.

Basically OKR

Submarine article.

Also, back when I was still a PM I found most these kinds of tools to be a waste of time. Tools don't solve ownership.

I found just talking directly with my sellers and engineers in the same room would solve these backlog issues.

Every project, initiative, and task needed to be directly tied to enhancing customer satisfaction or tangibly driving revenue (1-2% of ARR).

If Eng could not justify why a refactor could help customer satisfaction or topline P/L, I'd deprioritize it. If sales could not justify why a checkbox feature would satisfy the majority of our customers or help our topline P/L, I'd deprioritize it and re-prioritize the refactor.

Just demand fucking ownership from everyone - PM, Sales, and Engineering - and complex projects can be easily executed.

Ownership also means trusting the people executing but also validating - I trusted my engineers, salespeople, and stakeholders and vice versa, but I always made sure to do my homework.

Backlogs will always expand - that's to be expected - but someone must groom them and own them. That's on the PM.

Who cares what tool you use - it could be JIRA or a Excel 95 spreadsheet. Just own shit and fucking execute.

[dead]