The Most Confident Person in the Room Is Setting Your Roadmap
Someone says customers keep hitting this, with total conviction and no numbers. Nobody can check it in the next thirty seconds, so the room defers and it gets built. That's how most prioritisation actually works.
Sprint planning. Someone says it plainly:
“Customers keep hitting this. It’s the number one complaint.”
Everyone nods. It goes in. It gets built.
Nobody asked how many customers, or over what period, or whether “number one” was a count or an impression. Not because the room is credulous — because checking would take twenty minutes, and the meeting is happening now, and the person said it with total conviction.
You’ve been on both sides of that. Sometimes you were right. Sometimes you were repeating a thing one loud customer said in a call three weeks ago.
Confidence is not evidence, but it wins the same arguments
Prioritisation is supposed to be about impact. In practice, most of it is settled by whoever states their case most definitively in a room where nobody can check.
That’s not a character flaw in your team. It’s an artifact of where the numbers live. The error data is in Sentry. The behavioural data is in PostHog. Both are one login and several clicks away, and neither is open during planning. So the choice is between someone’s confident recollection right now and an accurate answer after the meeting has ended.
Recollection wins, every time. It has to — a decision is being made.
The cost isn’t usually a disaster. It’s quieter than that: you build the thing the confident person raised, and the thing that was actually hurting more people stays in the backlog, unmentioned, because it never had an advocate in the room.
The fix isn’t a dashboard nobody opens
The obvious answer — “we should look at the data more” — has been tried by every team that’s ever had this problem. It fails for the same reason the data wasn’t there in the first place: looking is a separate action, taken by a busy person, at exactly the moment they’re least likely to take it.
What works is the number showing up where the decision is already being made, without anyone deciding to go and get it.
Where Spectr helps
Connect PostHog or Sentry to a project and the errors your users are actually hitting appear next to the plan — occurrences, how many distinct users, when it was first and last seen. PostHog adds survey verbatims and feature-flag rollout state. It’s read-only; everything deep-links back to the provider to act on, and no person-level records are stored.
That’s the dashboard half, and it’s the less interesting half.
The part that changes arguments is that this evidence gets folded into the next spec sheet or requirement Spectr writes — with dates attached. So a requirement can be written against:
Sentry, as of Aug 7: 412 occurrences across 38 users in the last 30 days.
instead of “customers keep hitting this.”
That single change moves the conversation. A dated number is checkable. Someone can disagree with it, look it up, and come back with a better one. A vibe can only be out-argued by a stronger vibe, which is how you ended up here.
It also cuts the other way, which is the part worth wanting. Sometimes you pull the numbers and the loud thing genuinely is the top issue. Now you know, everyone else knows, and the person who raised it has something better than their reputation backing them up.
What this is really about
Not replacing judgement. Most product decisions can’t be settled by a count, and the ones that can are usually the boring ones.
It’s about making sure the room is arguing over the same facts. When the evidence is dated and visible, the discussion moves to what we should do about it — which is the part that needs your team’s experience — rather than whether it’s happening, which never needed a discussion at all.
The most confident person in the room should still get to make their case. They just shouldn’t win it by default.
Spectr pulls read-only error, feedback, and rollout data from PostHog and Sentry into each project, and cites it — dated — in the specs and requirements it generates from your meetings. Free tier available. Try it at spectr.pm.
