How to Run a Product Review Meeting

A product review meeting is a structured weekly forum where product managers present specs, metrics, and investment rationale to the product organization before anything ships. The format that works: a hard submission deadline 48 hours before the meeting, specs presented directly rather than slide decks, a four-minute limit per presenter, a cap on total specs per session, and a named leader who owns the quality of discussion - not just the logistics. The meeting only creates accountability if the bar is real and held there every week.

The clearest version of that standard I've ever seen was at TripAdvisor, where the founder often ran the meeting himself.

Every new PM at TripAdvisor had to present at Product Review within their first few weeks on the job. Nobody told you this was a rite of passage. There wasn't even a recurring calendar event to tell you where and when to go. You just followed the crowd.

I remember my fist product review vividly. I was introducing both myself to the org, and a feature tied to TripAdvisor's newly launched hotel meta price search product. The room in was full. And sitting at the front, running the meeting, was Steve Kaufer - the founder and CEO of the company.

I got through my presentation. Then Steve asked me which OTAs were the largest buyers on meta.

I didn't know. I said so.

His reply made my blood run cold: "Aren't you supposed to know that?"

I had heard the stories before I walked in. Some PM once had left Product Review in tears. I understood why, in that moment.

Fortunately, I happened to be the first presenter that day, which meant I had the entire rest of the two-hour meeting to find the answer. That was easier said than done. TripAdvisor's multi-petabyte data store ran on Hadoop with HiveQL on top - not exactly a system you casually query while sitting in the back row of a meeting. I found a corner, wrote the query, and waited for it to run. When the meeting broke up, I walked over to Steve as the room was clearing out and gave him my report: the query I had used and the answer it returned.

All I got back was a wry smile.

That was enough. A wry smile from Steve Kaufer wasn't nothing. He wasn't there to break people - he was there to find out who will do the work.

What a Product Review Meeting Is

Product Review - everyone called it PR - was a weekly Thursday meeting that sat at the operational center of TripAdvisor's product organization. It ran for two hours, starting at 10:30am in a large conference room at the company's Massachusetts headquarters. The room was always full. And it wasn't just the room - we were a global company, and dozens of colleagues from remote offices across North America, EMEA, and APAC dialed in from whatever time zone they were in. Every team that wanted to ship something first had to stand up and defend it.

Product Review was introduced by an early VP Product, but the primary architect was Adam Medros, the eventual SVP of Global Product. Steve and Adam evolved it together in the early days. Steve was a regular presence in the beginning - and returned in force whenever something big was on the table. But by 2008 or 2009, by mutual agreement, he had pulled back from attending regularly. The reason was practical: his presence as CEO made it harder for PMs to engage honestly. They were presenting to the room, but they were really presenting to him - and everyone knew it.

That changed depending on what was in the room. When I joined in June 2013, we were in the middle of rolling out hotel meta price search - a bet-the-company product - and Steve was at the meeting every week. Later, during Instant Book, same thing. My five years at TripAdvisor put me at the center of two of the biggest bets the company made, so my personal experience of Product Review was Steve-intensive. That was the nature of those moments, not necessarily the default state of the meeting.

What never changed: the standard they both set. This was not a bureaucratic review process run by a committee. It was the founder of the company, the person who built TripAdvisor from scratch, sitting in the front row when it mattered and asking PMs whether they actually understood what they were building and why.

The bar it created was real. Not theoretical. Real.

Adam Medros, who served as SVP of Global Product, articulated the purpose of the meeting plainly in a note to product leadership - prompted by a week where too many specs arrived at the last minute:

"The purpose of product review is to raise the visibility and transparency of what the company is working on, what key goals and metrics we're pushing towards, and how we make the experience better for consumers and partners. I expect product review to generate thoughtful discussion about whether the goals in a spec matter, whether the solution is the best solution to the problem described, and whether we've captured all the potential impacts it may have on various groups and initiatives across the company."

That was the official statement. My version is simpler: if you couldn't explain what you were building, why it mattered, and how you'd know if it worked - in plain English, in front of the SVP of Product or CEO - you weren't ready to ship it.

How to Structure a Product Review Meeting

The Cadence

The Format

The currency of the meeting was the "spec." Every team submitted a specification document to a shared email alias with hundreds of recipients. The spec laid out the goals, the approach, the key metrics, and the potential impacts on other teams and users.

Each presenter got four minutes - a visible countdown timer kept you honest. You walked through the actual spec document, not a separate slide deck. That detail mattered: it kept the conversation anchored to the artifact that would actually govern what got built, rather than a sanitized summary of it.

The rule on late submissions was non-negotiable: "If you miss that deadline, do not send it late. You can email me and ask to have it added to the agenda, but you should probably expect the answer to be no." Adam also asked to be cc'd on draft specs 24 hours before they went to the alias - not to gatekeep, but to spot cross-team impacts before they became public surprises in the meeting.

Ravi Mehta, who ran consumer product and was my boss when I joined - later my peer as I moved up - raised a practical problem early on that anyone who has managed a review process will recognize: volume was wildly inconsistent. Some weeks brought three specs. Others brought sixteen. The two-hour format could handle neither well - three specs left the meeting feeling thin, and sixteen meant the ones at the end got a fraction of the attention they deserved. Ravi proposed a ten-spec cap, filled on a first-come-first-served basis. The logic was right and the team adopted it. The queue created an incentive to move fast and plan ahead.

Supporting Structures

The meeting was recorded. A PM - often one of the MBA rotational hires we cycled through the program - served as the meeting scribe, and within 24 hours sent a recap summarizing what was discussed, what decisions were made, and any action items that surfaced. Good development experience for early-career PMs, and it meant the institutional memory of the meeting didn't live in any single leader's inbox.

Running parallel to the live meeting was a lighter-weight track called Virtual Review - specs circulated by email for async feedback without taking up floor time. It was fine in theory. In practice, the temptation to route anything slightly uncomfortable to Virtual Review was constant. The rule was that anything with significant engineering effort, or anything that meaningfully touched user experience, belonged in the room. But the enforcement of that rule depended on the leader's willingness to pull things back from VR when they deserved real discussion.

One persistent gap was cross-pillar visibility. TripAdvisor organized its product work into pillars - Hotels, Attractions, Restaurants, B2B - each a semi-autonomous business with its own team, roadmap, and P&L accountability. The weekly spec review gave everyone detailed visibility into individual features but not into the overall trajectory of each pillar.

At one point the PR leader flagged this directly: "One area we consistently get feedback around is visibility of cross-pillar roadmaps to the broader teams." The proposal was a 10-15 minute roadmap sharing slot - objectives for the quarter, KPIs being targeted, features planned. No required template. An acknowledgment that the meeting solved for feature-level transparency while leaving the strategic layer opaque.

Three things Adam later told me he always considered central to the meeting. First, full transparency: every new hire was told that anyone could be on the spec distribution list and anyone could come to Product Review. It was not an approval meeting. The goal was visibility, not gatekeeping. Second, speed of improvement: Product Review was the fastest path to strengthening a spec. A PM building a piece of content without building the tool for the content team to manage that content would hear about it in the room, and fix it that week. No checklist, no long discovery process. Third, norming: when marketing and product, or product and sales, were wrestling over something, the meeting put the conflict under the lights rather than letting it fester and go political. It wasn't always comfortable. But it was more productive than the alternative.

The Calibration Problem

Here is the honest thing about Product Review: we never fully solved the calibration problem. But we didn't have to. The ritual achieved 90% of the value it was designed to produce. Perfect is the enemy of done.

Steve's version of the meeting was intense. That was appropriate for what Steve was trying to build - a culture of accountability where PMs understood they were stewards of user trust and company resources, not just feature factories. If you came in underprepared, you felt it. That was the point.

But there's a line between a meeting that demands preparation and one that generates fear. It was rare - but there was a rumor of a PM once leaving Product Review in tears. Repeated enough times that it became part of the lore of the meeting. I don't think anyone should be crying at work. That's not what accountability looks like at its best - it looks like clarity, not cruelty.

When we softened the format over time, we fixed the fear problem and created a different one. A gentler Product Review is much easier to game. Vague specs slip through. Big claims go unchallenged. Teams learn that the bar has dropped and they calibrate accordingly. The meeting stops serving its purpose.

I joined TripAdvisor as a Director, a participant in the meeting like everyone else. When I reached VP level I became part of the small group shaping it alongside Adam, and I ran it a few times. By that point, two things were true simultaneously: Adam was deliberately softening the edges of the meeting, and I had become an unapologetic, born-again disciple of Steve's approach. I felt it was important to bring the rigor back. To make it clear that Product Review meant something.

I wasn't asked to run it very often. Another VP took the reins, introduced the walk-on music, added a GSD award - "Get Shit Done" - to recognize strong execution each week, and started ending each session with a round of applause. He made a lot more friends than I did. I stand by the quality of outcomes that come from the harder version of the meeting. Results over relationships when the two are in tension - that's not a concession I'm making. It's the hill I've chosen to die on, and the lens through which I run my advisory practice today.

The goal is to challenge the work, not the person. Steve was brilliant, and his version of the meeting reflected his intellect and his standards. Not everyone who runs a version of this meeting is Steve Kaufer or Adam Medros.

Concept Review: The Product Meeting That Catches Bad Investments Early

By the time a spec arrived at Product Review, the design was essentially locked. Engineering had scoped it. Design had comped it. The LOE was committed. The meeting was reviewing implementation details when the higher-value conversation - should we do this at all? - had already been foreclosed.

Eventually, we introduced Concept Product Review to pull that conversation forward. A concept doc was deliberately incomplete: a business case, key success metrics, early wireframes. No final copy. No pixel-perfect designs. No LOEs. The room's job was to pressure-test the investment thesis before resources were committed.

Concept presenters faced the same four-minute limit. That constraint generated debate. The argument for it was that brevity forces clarity. If you can't explain the strategic case for this investment in four minutes, the problem isn't the time limit. The argument against it was that complex concepts couldn't be done justice in four minutes - some things are just genuinely complicated. We compromised on structure: one minute for context and objectives, two minutes for specific examples with visuals, one minute for open questions that still needed resolution.

The early results were mixed. Notes from the first concept reviews were candid: the concept docs were fine, but the presentations were too general to generate useful feedback. "Very general isn't very useful" was how the post-meeting notes put it. Getting PMs to present strategic thinking rather than execution detail turned out to be harder than it sounded. Most PMs were trained by their experience with regular Product Review - which rewarded specificity and preparedness on implementation - to be very concrete. Asking them to zoom out and present a thesis rather than a plan required a different set of skills.

We kept working on it. The concept was right even when the execution was imperfect. The deeper problem was that most PMs had been trained by years of spec review to be concrete and tactical - specificity was how you survived that room. Asking those same PMs to stand up and present a strategic thesis, in the same room, under the same clock, was asking them to override muscle memory. That's a harder ask than it sounds. The best version of Concept Review is the conversation you want to have with a PM before they've wired their identity to a specific solution - but getting there requires coaching the instinct out of them first.

Why Product Review Accountability Is the Point

Product management is about accountability. Not accountability to a product manager's own judgment or preferences - accountability to users, to value creation, and to business results. Those are the only three things a PM is actually directly responsible for. Everything else is in service of those three.

Product Review operationalized that accountability. If you were staffing a project, you were spending the company's money. If you were running an A/B test, you were running an experiment on real users. Product Review was the moment where you had to explain, in plain language, what you were doing with those resources and what results you were trying to produce. If you couldn't do that - in front of the CEO, in front of your peers, in four minutes - the project probably wasn't ready. Maybe the thinking wasn't sharp enough. Maybe the case for the investment hadn't been made clearly. Maybe there wasn't a good case at all.

The weekly cadence created something else: a forcing function for the organization's collective thinking. When you know you'll be standing up every Thursday to account for your work, you think more carefully about your work. You ask yourself the questions you know will be asked. You stress-test your own reasoning before someone else does it for you. That habit of thinking - not just the meeting itself - is what changed people.

I've seen product review processes that were too soft to generate that effect. The questions were gentle. The feedback was encouraging. The bar was unclear. Those meetings consume two hours every week and leave no deposit. They create the appearance of accountability without the substance. The same pattern shows up in every meeting format that loses its teeth over time - the ritual survives but the standard doesn't.

The TripAdvisor version, at its best, created the substance. It was uncomfortable sometimes. The OTA question I couldn't answer taught me something I never forgot: you are accountable for knowing the business you're building for. Not just the feature. Not just the user experience. The business.

Steve didn't say that to be cruel. He said it because it was true.

The version of Product Review I'm most proud of wasn't Steve's version or mine. It was the one that Adam's direct reports built together - a half-dozen of us VPs and Directors who had all been through the fire and had opinions about how to run it better. Great outcomes. No crying. Real optimism about the work and the people doing it. Steve set the ritual in motion and established what it needed to stand for. But Adam was the one who opened it up to the right people and let them shape it into something more productive than what any one of us would have built alone. That collaborative refinement is probably the part of the story that gets overlooked, and it shouldn't.

I'll say something I believe strongly: TripAdvisor's Product Review is one of the single biggest reasons Boston produced a generation of genuinely exceptional product leaders. The discipline of preparing for that room, week after week, year after year, built something no PM training program or coaching engagement can replicate - a recurring, high-stakes test of your thinking in front of the people whose judgment mattered most. You either rose to that standard or you didn't. The PMs who came up through it are running product organizations across the industry today. That's not a coincidence.

"If you couldn't explain what you were building, why it mattered, and how you'd know if it worked - in plain English, in front of the CEO - you weren't ready to ship it."

Cheat Sheet for Running a Product Review

The weekly cadence - Monday: send call for topics - Tuesday EOD: hard cutoff for spec submissions - late means next week, no exceptions - Wednesday: publish agenda with specs attached so people can read before they arrive - Thursday: two hours, same time, same room, every week

The meeting itself - Present the actual spec document, not a slide deck sanitized for the room - Four minutes per presenter - brevity forces clarity - Cap total specs per session (10 is a reasonable ceiling) - first-come, first-served queue - Record the meeting; distribute links same day

Supporting roles - Assign a junior PM or rotational hire as scribe - they send the recap within 24 hours; it's also good development for them - The PR leader owns the quality of discussion, not just the logistics - this role matters

The parallel tracks - Virtual Review for genuinely non-controversial continuations; protect it from becoming an escape hatch for things that deserve real discussion - Concept Review upstream for strategic bets - before engineering scopes, before design comps, before anyone has committed their identity to a solution

The standard - The deadline is real or it isn't - pick one - If a PM can't explain what they're building, why it matters, and how they'll know if it worked, the project isn't ready - Challenge the work, not the person - but challenge it - Cross-pillar roadmap visibility doesn't happen automatically; build in a recurring slot for it

The thing that kills it - A leader who treats the meeting as a formality - Softening the bar until the meeting becomes a status update with applause - Letting Virtual Review absorb anything that feels uncomfortable to defend out loud

The meeting doesn't work because it's on the calendar. It works because the person running it decided the bar was real and held it there every week. That decision is the whole thing.

Parts of this post were developed with input from Adam Medros, who ran Product Review at TripAdvisor. Adam's leadership shaped how I think about product and accountability - Product Review was the training ground, and he was the reason it worked. You can find him at adammedros.com.