You open the feedback list before a review round and every single item reads like it can’t wait. The broken checkout button. The client’s “make the hero feel more premium” note. The typo in the footer. The three-week-old comment about mobile spacing that never got picked up. They’re not all the same kind of urgent, but on a flat list, they all look it — and the developer ends up picking whichever one made the most noise, not the one that actually matters.
The fix isn’t more discipline about which fires to fight first. It’s a ranking method that doesn’t rely on your gut every single round.
Why does every item on a feedback backlog feel equally urgent?
Because a flat list has no way to encode “this matters more,” so the human brain defaults to whichever comment is loudest or most recent. That’s not a discipline failure — it’s a known cognitive shortcut. Recency bias causes people to weight the newest information more heavily than older information of equal or greater importance, even when the older item is objectively more consequential. Amplitude’s own writeup on the bias gives the exact shape of this failure in a product team: after a cluster of recent complaints about load times, a team “shifts all its resources to boosting speed” and sidelines a planned overhaul that “months of user responses” had flagged as more important — because the recency of the speed complaints overshadows the long-standing issue. A website feedback backlog fails the same way: the comment from this morning feels more pressing than the one from three review rounds ago, regardless of which one a visitor actually trips over more often.
The often-quoted framing of this problem — “the urgent are not important, and the important are never urgent” — traces back further than most people assume. Eisenhower used the line in a 1954 address, but he was quoting an unnamed college president, not coining it himself; Quote Investigator’s research traces the likely originator to Dr. J. Roscoe Miller, then president of Northwestern University. The idea has survived 70 years because it names something durable: urgency is a feeling generated by timing, and importance is a fact generated by impact, and a flat list conflates the two by design.
What’s the fastest way to sort a feedback backlog by real impact instead of gut feel?
Score each item on how many people it affects and how badly, then divide by how much work it takes to fix — the resulting order is usually different from the order the comments arrived in. This is a scaled-down version of RICE, the prioritization framework Intercom’s product team built after noticing their own decision-making favored “pet ideas” over the ideas with the broadest reach. Sean McBride, who built RICE at Intercom, has written that without a scoring method, “it’s satisfying to work on pet ideas you’d use yourself, instead of projects with broad reach,” and “it’s tempting to focus on clever ideas, instead of projects that directly impact your goals” — Intercom’s own writeup of the framework frames the whole method as a corrective for exactly that bias.
You don’t need Intercom’s full four-factor formula (Reach × Impact × Confidence ÷ Effort) for a website feedback backlog — that’s built for comparing dozens of product bets against each other. A founder-scale version keeps two of the four factors:
- Impact — does this block a task, cause visible confusion, or just look slightly off? Rate it roughly: blocking, degrading, or cosmetic.
- Effort — is this a five-minute CSS tweak or a structural rebuild?
Plot every open comment against those two axes and the order usually reshuffles hard. The client’s “premium hero” note might be high-effort, medium-impact — real, but not urgent. The three-week-old mobile spacing bug might be low-effort, high-impact — and it’s been sitting at the bottom of a chronological list the whole time because nobody re-sorted by anything other than “when it arrived.”
The part that trips founders up most isn’t the scoring math, it’s guessing the impact number honestly. ProductPlan’s survey of product managers found the single most common prioritization roadblock — cited by a quarter of respondents — was setting priorities without solid customer feedback to back the estimate up. The fix for a website review is the same fix that survey implies: don’t guess whether a comment is “blocking” or “cosmetic” from your own reaction to it. Check it against what a real visitor would actually hit — could they still complete the task the page exists for, or not.
How do you decide what ships this round versus what waits?
Split the ranked list into three explicit buckets — must ship this round, should ship soon, and won’t ship right now — instead of one undifferentiated queue. This is the MoSCoW method (Must have, Should have, Could have, Won’t have this time), developed by Dai Clegg in 1994 and adopted as a core technique of DSDM, the agile framework now maintained by the Agile Business Consortium. A “Must have” is a requirement the project can’t ship without; a “Should have” is important but the release survives without it; a “Could have” barely moves the needle if it’s cut. DSDM’s own guidance recommends capping Must Haves at roughly 60% of total effort per cycle, on the reasoning that anything higher leaves no slack if an estimate runs long or a surprise shows up mid-round.
Applied to a website review: Must is what blocks launch or breaks a task for a real visitor — the checkout bug. Should is real and worth doing soon but doesn’t block anything — the mobile spacing issue. Could is the stuff that’s genuinely optional this round — the hero copy tweak. The bucket that actually changes behavior is the fourth one MoSCoW insists you name explicitly: Won’t have this time. Saying “not this round” out loud, in writing, next to the comment, is what stops that comment from silently re-litigating itself every time someone re-reads the list.
What happens if you never re-prioritize the backlog?
It fills with items that mattered when they were written and don’t matter anymore, and the accumulated weight makes the whole list look worse than the team’s actual output. Agile consultant Allan Kelly ran the numbers on a real product backlog and found nearly half the stories were over a year old — items he calls stale: “stories that relate to yesterday’s problems and projects, stories which people wanted last year.” His conclusion applies just as directly to a website feedback list: the existence of a big backlog of stale items makes a team look unproductive even when it’s shipping steadily, because stakeholders count every open item as still-owed work, whether or not it’s still relevant.
The failure mode is specific to backlogs that get ranked once and then just appended to. New comments land at the bottom in arrival order, never re-compared against what’s already there, and the list becomes a chronological journal instead of a ranked plan. ProductPlan’s survey of more than 2,500 product managers found prioritization ranks as the second most important skill for a product manager, behind only communication — and the reason it ranks that high isn’t that ranking is hard once, it’s that it has to happen on a fixed cadence or it decays. For a website review, that cadence is every round: before each review session starts, re-sort the whole open list, not just the new items.
How does Simpl_Markup keep a feedback backlog from turning into an “everything’s urgent” swamp?
Every comment in Simpl_Markup carries a visible status — open, fixed, or approved — attached to the pin on the exact element it’s about, so the whole team can see at a glance what’s still outstanding without anyone maintaining a separate priority spreadsheet. Because every pin lives on the page itself rather than in a chronological Slack thread, re-sorting the list by impact and effort means looking at the actual open pins side by side, not scrolling back through weeks of messages to reconstruct what’s still unresolved. That’s the same structural fix behind async feedback generally: the record lives in one visible place, so ranking it doesn’t require rebuilding context from memory first.
That’s a different shape than a dedicated bug tracker bolted onto a review process, where prioritization usually means moving cards across a board that lives outside the page the feedback is actually about — see how Simpl_Markup’s approach compares to BugHerd if you’re weighing the two for a founder-led review. None of this replaces the judgment call of what’s actually a Must versus a Could — that’s still a human decision, and a real one when a client and a developer read the same comment differently (see what to do when your developer says your feedback isn’t a bug for that specific disagreement). What a visible, per-pin status removes is the second failure: a ranking that only exists in your head, re-argued from scratch every time someone opens the list.
Next review round, don’t start by reading the backlog top to bottom in the order it arrived. Re-sort it by impact against effort, split it into Must/Should/Won’t-this-time, and make the ranked order something the whole team can see — not something only you’re carrying around.