The backlog is lying to you.
"Decide what to build next using a framework that cuts through noise and stakeholder pressure."
Why this exists
A backlog without a decision framework is just a wishlist. It grows forever, never reflects reality, and gets prioritized by whoever complained last. We make trade-offs explicit so that priorities reflect user impact instead of stakeholder volume.
Operational Flow
Run weekly reviews: Every Monday, the product lead reviews the top 20 items in Linear. Archive anything untouched for 60 days. Do not punt it or save it for later.
Score before debating: Score candidates on user impact (1 to 5) and effort (1 to 5). This stops the loudest voice in the room from winning by default.
Apply a cooling period: Hold new client requests for 48 hours. Confirm receipt, then review them after two days. Half the time, the urgency disappears. The rest is usually real.
Fix bugs first: Any bug affecting over 5% of active users jumps the queue. Fix existing software before building new features.
Assign one task per engineer: Split attention kills throughput. A team of four engineers working on four separate tasks ships slower than a focused team.
Maintain a 'not now' list: Write a one-sentence reason for every item declined this sprint. Review this list monthly. Sometimes market needs shift.
What good looks like
- Sprint planning where the team explains why item three is ahead of item four based on evidence instead of intuition.
- A client gets an update stating we are building their feature next sprint, or explaining why we are not.
- A new engineer understands current priorities from the backlog without needing a thirty-minute walkthrough.
What NOT to do
- Don't let a feature request skip the queue because a client seemed annoyed on a call. Log it, score it, and let the process run.
- Don't score everything as high impact to avoid difficult cuts. Low scores are useful data.
- Don't run sprints where every engineer has a separate focus. That is chaos, not parallel development.
Everyone thinks they know how to prioritize. They do not. The common failure is having no shared framework, which forces every planning meeting to start from scratch and get resolved by whoever yells loudest. We have shipped features that moved no metrics because they felt important, while ignoring bugs that damaged retention. Both mistakes cost more than the planning meetings that would have prevented them.
Legible trade-offs are the goal. When you deprioritize an item, give the requester a real reason. Tell them it scored a 2 on impact against a 4 on effort, and that we have three higher-scoring items. That is a respectful answer, not a bureaucratic one. It proves you actually evaluated the work. The backlog is not a promise queue; it is a hypothesis queue. Run the right hypotheses in the right order.