I have sat through hundreds of executive product reviews, on both sides of the table. The format is almost always the same. A team prepares a deck, walks through it, the status bars are mostly green, a few questions get asked about the yellow ones, everyone agrees the work is progressing, and nothing was decided. That review made sense when building was slow and expensive. Building is no longer slow or expensive, and the review never got the memo.
Why the old review broke
The classic product review optimized for reassurance that a long, expensive effort was proceeding. That was right when the dominant risk was execution: if a feature took two quarters to build, you very much wanted a monthly checkpoint that it was on schedule. The dominant risk moved. Execution is now fast and cheap, so "is it on schedule" rarely tells you anything that matters. The real risks migrated upstream and downstream: are we building the right thing (judgment), is what we are building actually working (outcomes and evals), and what is it costing us to run (margin).
The five questions
Replace the status walkthrough with these, ordered so the conversation builds.
What did we learn since last time, and what did we change because of it? First on purpose. If the team learned something real, they changed something real. If nothing changed, they were reporting, not learning.
What outcome moved, not what shipped? Shipping is the cheap part. Listing what shipped tells you the team was busy, not whether the business is different. "We shipped X" gets the follow-up "and what moved because of it."
What is this costing to run? Every AI-driven feature has a marginal cost in tokens, tool calls, and compute. If nobody in the room can state it, you are making product decisions blind to margin.
What is the eval score, and which way is it trending? For anything AI-driven, the real risk is not that it never worked, it is that it worked and then drifted. No score means no answer, and "we are working on evals" is a yellow flag you should not let pass twice.
What are we willing to be wrong about here? The closer. It surfaces the actual bet underneath the work and separates teams that thought about the decision honestly from teams managing your perception.
The plain version
A product review should force a decision, not confirm that work is happening. The five questions shift the room from grading progress to exercising judgment, which is the only thing left that matters once execution is cheap. Try this at your next review: send the status async, and open the live session with question one, just "what did we learn, and what did we change because of it." The quality of the answer will tell you more about the health of the team than any deck of green bars ever did.