A strong answer. “I would not start with the backlog, because a backlog is an accumulation of past requests rather than a statement of what matters now.

First month, three things. Find out what the business is actually being measured on this year — not the mission statement, the number the executive team reports. Almost every prioritisation argument is really a disagreement about that, and it is usually never made explicit.

Then find the constraint. Is it demand — we cannot sell it? Delivery — we cannot build fast enough? Or retention — we lose them after we sell it? Those point at completely different quarters, and forty backlog items will contain plausible-sounding work for all three.

Then go and look at where the work actually goes. In my experience a large fraction of engineering capacity is already committed to unplanned work — support escalations, keeping-the-lights-on, a migration somebody promised. If half the quarter is spoken for, prioritising the other half against a forty-item list is the wrong exercise; the real conversation is about the half nobody is looking at.

Then I would publish a short list — three things — with what each is meant to move and what we are explicitly not doing. The 'not doing' list is the part that makes it a decision. And I would be clear that I will be wrong about one of the three, and say how we would find out by mid-quarter rather than at the end.

On frameworks: I would use one to structure the conversation, not to produce the answer. Anyone can move a reach estimate to change the ranking, and pretending the score decided it hides who actually decided.”