A product manager reconciling stakeholder feedback on a build spends most of the week arbitrating between people who do not disagree. Two notes that contradict each other were, more often than not, written about two different states of the same screen. The reconciling work is locating the state each person saw, and only then weighing the opinion.
Feedback arrives without the thing it was said about
The standard round works like this. A link to the build goes out on Tuesday. By Thursday the thread holds a note from the head of sales saying the pricing page is too dense, one from legal saying it omits a required disclosure, one from the founder saying it looks fine, and one from a customer success lead saying the button at the bottom does nothing.
Read the notes again and notice what none of them carries. Not one says which pricing page: the build has been deployed three times since Tuesday, and two of those deploys changed the pricing layout. Not one says which role was logged in, which plan the account was on, or whether the reviewer was on a laptop or a phone. The note about the button does not say what the button did when it did nothing, because a customer success lead has no reason to open a console.
A stakeholder is asked for an opinion and returns one. The context that would make the opinion checkable was never requested, so the manager receives four verdicts and zero observations. Contradiction is the natural result of that arrangement, and it is the arrangement rather than the stakeholders that produces it.
Four kinds of contradiction, one of them an argument
Before arbitrating, sort. Most pairs of contradicting notes fall into one of four kinds, and the treatment differs for each.
| Kind of contradiction | What happened | What resolves it |
|---|---|---|
| Same element, different build | The layout changed between the two reviews | The deploy log, and a re-review of the current state by whichever reviewer saw the older one |
| Same element, different conditions | One reviewer was on a narrow viewport, a different role, or an empty account | The conditions, captured or asked for, and a look at the element under each |
| Different elements, same words | “The header” meant the page header to one person and the table header to another | Pointing at the element, so the note is anchored to a thing rather than to a noun |
| Same element, same conditions, different view | A genuine disagreement about what the product should do | A decision, taken by whoever owns the acceptance criteria, and recorded |
Only the last row is the kind of contradiction a manager is paid to resolve, and it is the rarest of the four. The first three dissolve once somebody establishes what each reviewer was looking at, and they consume the most meeting time precisely because they get argued as though they were the fourth. Two directors defending incompatible positions about a table that rendered differently for each of them will not converge, because both are right.
The sort is worth doing in the open. A reply that says “these two were looking at different builds” ends an argument in one line. A reply that says “let’s discuss in the sync” schedules it.
Build, account and viewport are never in the note
The conditions that separate the first three rows are not exotic. The one that catches teams most often is the build itself. A preview environment that redeploys on every push to the branch is the right place to collect stakeholder feedback and the wrong place to assume two reviewers saw the same thing. A reviewer who opened the link on Tuesday morning and one who opened it on Wednesday afternoon reviewed different software, and neither note records which.
After the build come the account and the data. Stakeholders review as themselves, which means as an admin on a fully populated demo account, and the complaint from customer success about an empty state comes from having looked at the product the way a new customer would. The viewport is next: the head of sales reviewed on a phone between meetings and the founder on a wide external monitor, and the density complaint and the “looks fine” verdict describe the same page at two widths. Then the browser, which changes fewer things than people assume.
A round that does not record these variables cannot tell a different opinion from a different condition, and the manager ends up carrying that distinction in their head, per note.
The acceptance criteria are the other half of the frame. A stakeholder note that contradicts a criterion agreed before the work started is a request to reopen the criterion rather than feedback on the build, and it belongs in a different conversation.
Collect against the element, not in the thread
The fix follows from the sort. Feedback anchored to a specific element, on a specific build, under recorded conditions, arrives already sorted into the first three rows or the fourth. Feedback typed into a thread arrives as an opinion with the sorting still to do.
Anchoring means the reviewer points at the thing on the live page and writes the note there. The note then carries the element as a selector and a box on the page rather than as a noun, so “the header” stops being ambiguous, and it carries the page, the viewport and the browser without the reviewer being asked for any of them. A review session is built for this: the stakeholder clicks the element on the live page, the note is stored against that element rather than against a noun, and it lands on the board in the same Received queue as a tester’s bug. The build and the role are the two conditions a page cannot report about itself, so the round supplies them: one link per deploy, one review account per role. What the manager then reconciles is a set of notes that each say what they were looking at.
The second half is what stakeholders see afterwards. A director who filed a note wants to know what happened to it, and a thread is a poor place to answer, because the reply to one director’s note is visible to the others and reads as a verdict on it. A client portal answers that per director: each sees the stage their own note has reached, the text they wrote and the replies the team chose to show them, while the sorting notes and the priorities stay on the team’s side.
Anchored feedback still needs the sort; it makes the first three rows visible rather than making them disappear. A stakeholder who prefers to reply to an email will keep replying to the email, so the collection method has to be as easy as the thread it replaces or it gets bypassed in week two.
A genuine disagreement is settled by whoever signs off
The fourth row remains, and the process does not own its answer. The person who can settle a genuine disagreement about what the product should do is whoever signs off, and that decision cannot be delegated downward to the manager collecting the notes. A manager who resolves it anyway has made a product decision on somebody else’s authority, and the sign-off that follows is a formality performed on a build the signatory did not choose.
Time is the other limit. A note anchored to an element on a preview build points at something that stops existing when the preview is rebuilt. The reconciling, and especially the re-review that settles the first row of the table, has to happen while the build the stakeholder saw is still the build being served. A round left to run across a week of merges accumulates notes about software nobody can look at any more, and those notes get resolved by asking the reviewer to look again, which is the round starting over.
So the collection method decides the shape of the reconciling. Ask for opinions in a thread and the manager spends the week discovering which page each opinion was about. Ask for notes against elements, on a named build, and the week goes on the one row that was ever a real argument.
