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.