How to run a product review that doesn't waste everyone's time

Most product reviews are status updates wearing a decision-making costume. The room fills up, slides are walked through, comments are made, and everyone leaves without having resolved anything that couldn't have been resolved in a shared doc. The reviews that actually move products forward share a specific structure — and it starts before anyone enters the room.

What a product review is actually for.

The purpose of a product review is to make decisions — specifically, the decisions that require the people in the room to be in the same room. That sounds obvious until you sit in enough of them and realise that most reviews don't make decisions. They share information. They surface concerns. They generate action items that get assigned to the PM to "follow up on" and are never heard from again. The calendar event says "Product Review." The actual meeting was a briefing with questions.

Products rarely stall because a team lacked information. They stall because a decision that required sign-off from two senior people was never structured as a decision that required sign-off from two senior people. It floated in the roadmap as a "TBD" or a "pending alignment" and continued floating, sprint over sprint, until someone got frustrated enough to force it. The product review is the mechanism to prevent that. When it doesn't work, the drift resumes.

The reason this matters structurally: product reviews are expensive. Get five or six senior people in a room for an hour and you've spent the better part of a working day in aggregate payroll. That cost is only justified if the meeting produces something those people couldn't produce asynchronously. Information can be shared asynchronously. Decisions — the kind that require reading the room, testing a recommendation, and getting explicit commitment from the person who has the authority to change it — usually cannot.

The meeting most teams are actually running.

The typical product review goes like this. The PM has prepared slides. The slides cover what shipped last sprint, what the metrics show, what is planned for the next sprint, and a list of "open questions" at the end. The meeting starts with the PM sharing their screen. Senior people scroll on their phones for the first five minutes while the PM walks through last sprint's output. Around minute eight, someone asks a question about a metric that the PM doesn't have the answer to. The PM says they'll follow up. More slides. More questions. At minute forty-five, the most senior person in the room glances at their phone and says "we're almost out of time — can we take the remaining items offline?" The PM says yes. The meeting ends. Nothing was decided. The "open questions" slide was never reached.

This is not a pathological case. This is the modal product review in most companies. The PMs who run it are not incompetent — many of them are quite good. They were simply never taught that a review has a specific structure, and that deviating from it produces exactly this outcome.

The core failure is that information-sharing and decision-making have been mixed into a single meeting format that serves neither well. Information can always be shared more efficiently in writing. Decisions require structured discussion. When you mix them, the information-sharing expands to fill the available time, and the decisions get crowded out.

The prep that changes everything.

The single highest-leverage change to a product review is mandatory pre-reading. Not optional pre-reading. Not "here are some slides if you want to look at them." A one-page document that goes out at least twenty-four hours before the meeting, which attendees are expected to have read before they walk in.

The pre-read has four components. First, the current state: what is the metric or outcome being reviewed, and where does it sit relative to where you expected it to be? One paragraph, with numbers. Second, the decision: what specific decision does this review need to make? Not a discussion point. A decision — with a verb, an object, and a deadline. "Decide whether to prioritise checkout redesign or order tracking for Q3, with a final call by end of this week." Third, the options: what are the realistic choices, with the tradeoff for each option stated plainly? Avoid straw-men options that only exist to make the preferred option look good. And fourth, the recommendation: what does the PM think the team should do, and why?

That last element — the recommendation — is where most PMs are reluctant. They are nervous about being wrong in front of senior leadership. They would rather present options and let the room decide. This is a mistake in both directions. It makes the PM look like a facilitator rather than a product leader. And it makes the room work harder than it should — because the PM has more context than anyone else in the meeting and is in the best position to give a recommendation. The room's job is to stress-test it, not to derive it from scratch.

The three questions every review must answer.

Every product review, regardless of the team's size or stage, should produce clear answers to three questions before the meeting ends.

The first: what have we learned since the last review that changes our understanding of the problem? This grounds the meeting in reality rather than planning fiction. Products that have shipped something almost always surface something unexpected — an adoption pattern that differs from the prediction, a feature being used in a way that wasn't intended, a segment responding more strongly than expected. The review is the moment to name what was learned and decide whether it changes anything. If the answer is "nothing, everything is on track," that's acceptable but worth scrutinising — it's rare that a week or two of real-world product data produces no surprises.

The second: what is the decision we are making today, and who is making it? Every review should have exactly one decision as its primary agenda item. One, not three. If you have three decisions to make, run three reviews or run one review with three tightly-scoped agenda blocks. Trying to make three decisions in one meeting reliably results in making zero decisions well. And the decision must have a named owner — the person whose call it is, on the record. "The team decided" is not an owner. "Priya decided, with input from Finance and Design" is an owner.

The third: what are we not doing as a result? Every decision to do something is implicitly a decision not to do something else. Making that tradeoff explicit is what turns a decision into a strategy. If the review decides to prioritise checkout redesign for Q3, the review should also name what is being deprioritised as a result — and that name should be in the meeting notes, agreed, so that it doesn't get re-litigated at the next review by the person whose initiative was cut.

Why most reviews produce no decisions.

The structural reason is that nobody is accountable for producing a decision. The PM runs the meeting. The meeting agenda says "product review." But the PM often doesn't have the authority to decide unilaterally, and the senior stakeholders haven't been primed to come ready to decide. The meeting becomes a discussion that ends when the time expires. Discussion is not a decision.

The fix is to name the decision-maker before the meeting, in the pre-read. "This review will make a recommendation on X. The final decision will be [name]'s." When the decision-maker knows they are walking into a room to decide, they prepare differently. They read the pre-read. They arrive with questions already formed. They don't spend the first twenty minutes catching up on context they should have read the day before.

There is a related failure mode: the review is structured so that agreement is impossible because the options aren't real options. "We could either build the full redesign or do nothing" is not a real choice. Real options are specific, internally coherent, and genuinely defensible. "We could ship the checkout redesign in six weeks with the current team, or we could ship a lighter version of the order tracking improvement in three weeks while we hire one more frontend engineer" — that's a choice with stakes. It can be disagreed with. It requires a real decision.

Reviews that present false options aren't really seeking a decision. They are seeking permission. The PM has already decided and is using the review to get sign-off while maintaining the appearance of consultation. This is not malicious — it is usually the product of fear. Fear that if the real options are presented, the senior team might choose the wrong one. The cure for this fear is better pre-reads and more regular reviews, not permission-seeking masquerading as decision-making.

• 01
  Circulate a pre-read 24 hours before, and expect it to be read. The first five minutes of the meeting are for questions on the pre-read, not a walkthrough of it. If you're walking through it, you didn't send it early enough or with enough expectation that it would be read. This single change recovers twenty minutes per review.
• 02
  One decision per review. If you have three decisions, run one review with three tightly scoped blocks or schedule three reviews. Trying to make three decisions in sixty minutes reliably makes zero decisions well. Scope the agenda to the decision, not to all the things you could discuss.
• 03
  Name the decision-maker in the pre-read, before the meeting starts. When the owner knows they are walking into a room to decide, they prepare differently. "The team will decide" is not accountability. "This call is Priya's, with input from Finance and Design" is accountability. It changes the meeting from discussion to deliberation.
• 04
  PMs must give recommendations, not just options. Presenting three options and asking the room to choose is facilitation, not product leadership. The PM has more context than anyone else in the meeting. Give a recommendation, with reasoning. The room's job is to stress-test it. That's a much more productive use of senior time than deriving a recommendation from scratch.
• 05
  End every review by naming what you are not doing. Every decision to do something cuts something else. Name it on the record in the meeting notes so it doesn't get re-litigated at the next review by the person whose initiative was deprioritised. "We chose X, which means Y is not happening in Q3" — stated, noted, done.
• 06
  If no decision was made, cancel the recurring invite. A review that consistently produces no decisions is a status update meeting running under false pretences. Either restructure it with a pre-read and a named decision, or replace it with a written update and give everyone the hour back. The meeting is not sacred — the decision is.

Frequently asked questions.