Most product review meetings are a waste of time. I've run enough of them to say that without hedging. The format is usually the same: PM presents the work, stakeholders ask questions, someone raises a concern that should have been raised two weeks ago, the meeting ends without a clear decision, and everyone schedules a follow-up to the follow-up.
The problem isn't the meeting format. The problem is that most teams use product reviews to do work that should have been done before the meeting. Discovery, alignment, and decision-making are three different activities. Trying to do all three in the same 60-minute slot with eight people in the room is why product reviews feel like they accomplish nothing.
What the meeting is actually for
A product review is a decision-making event. By the time you're in the room, the problem should be understood, the options should be defined, and the tradeoffs should be explicit. The meeting exists to make a decision and assign ownership, not to figure out what you're building.
When teams use product reviews for discovery - when the PM is still working out the problem in real time - you get a design session with too many people and not enough context. Stakeholders who haven't been close to the work start generating ideas. The PM tries to respond to all of them. The engineers in the room get frustrated because half the ideas being discussed are technically infeasible and nobody's asking them. Nothing gets decided.
I've started sending a written brief before every product review. Not a deck - a document. A deck is designed to be presented. A document is designed to be read and thought about. The brief covers four things: the problem we're solving and why it matters now, the solution we're proposing and what we considered and rejected, the specific tradeoffs we're making, and the exact decision we need from the group. If people read it before the meeting, the meeting is 30 minutes instead of 60 and produces an actual decision. If they don't read it, at least I've done the thinking.
The pre-work that actually matters
The most important thing I do before a product review is figure out where the resistance is going to come from. Not to suppress it - to be prepared to address it.
Every significant product decision has someone who's going to push back. Sometimes it's a technical concern: an engineer who knows the proposed approach will create a race condition in the order processing flow, or that the database query pattern we're planning will fall apart at 10x current load. Sometimes it's a business concern: a stakeholder who thinks we're solving the wrong problem or moving too fast. Sometimes it's political: someone who wasn't consulted early enough and is going to make that known in the meeting.
Walking into a product review without knowing where the resistance is coming from is a failure of preparation. I try to have one-on-ones with the key stakeholders before any significant review. Not to pre-sell them on my position - to understand theirs. If someone has a legitimate technical concern, I want to know about it before the meeting so I can either address it in the brief or adjust the proposal. If someone has a political concern, I want to understand it so I can make sure they feel heard in the room.
Concern surfaces for the first time in the meeting. You either dismiss it publicly (creating resentment) or derail the meeting to address it (no decision gets made).
1:1 before the meeting surfaces the concern early. You address it in the brief or adjust the proposal. The meeting stays on track.
The meetings that go badly are almost always ones where a concern surfaces for the first time in the room. At that point, you're either dismissing it publicly (which creates resentment) or derailing the meeting to address it (which means no decision gets made). Neither is good.
The decision problem
The most common failure mode in product reviews is ending without a clear decision. The meeting runs long, people have to leave, and the outcome is "let's take this offline." This is almost always avoidable.
If you can't make a decision in the meeting, it's usually one of three things. The wrong people are in the room - either someone with decision authority isn't there, or people without decision authority are there and muddying the conversation. The decision criteria aren't clear - people are arguing about the options without agreeing on what a good outcome looks like. Or the options haven't been defined well enough - you're debating a vague direction instead of a specific choice between two concrete approaches.
All three of these are pre-meeting problems. The PM's job is to make the decision easy to make. That means doing the work to narrow the options, make the tradeoffs explicit, and get the right people in the room. If you've done that, the meeting should be relatively short.
I've started ending every product review with a written summary of what was decided, what was explicitly not decided, and who owns what next. It takes five minutes and eliminates most of the "wait, I thought we agreed to..." conversations that happen afterward. The act of writing it in the room also surfaces disagreements - if I write "we decided to prioritize X" and someone says "I didn't agree to that," better to know now than in two weeks when the work is already done.
The meeting is the easy part. The work is everything that happens before it.