Five Questions That Make a Product Review Worth Your Time

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. They walk through it. The status bars are mostly green. A few questions get asked about the yellow ones. Everyone agrees the work is progressing, the meeting ends, and nothing was decided.

That review made sense in a world where building was slow and expensive. Confirming that a six-month effort was on track had real value. But building is no longer slow or expensive, and the review never got the memo.

The short version

Most executive product reviews are status theater: a deck of green bars that confirms work is happening but forces no decision. That was tolerable when building was slow; now that building is cheap and fast, "are we on track" is the least valuable question in the room. Five questions convert the review into a decision-forcing session: what did we learn and change, what outcome moved (not what shipped), what does this cost to run, what is the eval score and its trend, and what are we willing to be wrong about. Ask these and the meeting stops measuring progress and starts surfacing judgment, cost, and risk. To make room, cut the roadmap walkthrough and anything that does not change a decision.

For the board-level version of this scoreboard, see the CPO Mandate 2026. For the cost question underneath question three, see The Product Budget Is a Compute Budget Now.

Why the old review broke

The classic product review optimized for one thing: reassurance that a long, expensive effort was proceeding. That was the right thing to optimize 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). A review built around status bars is answering a question that stopped being scary while ignoring the three that became scary.

The five questions

Replace the status walkthrough with these. They are ordered so the conversation builds.

What did we learn since last time, and what did we change because of it? This is the learning question, and it is first on purpose. If the team learned something real, they changed something real. If nothing changed, they were reporting, not learning. A team that cannot name a single change driven by new information is a team running on autopilot, no matter how green the bars are.

What outcome moved, not what shipped? Shipping is now the cheap part. Listing what shipped tells you the team was busy. It tells you nothing about whether the business is different. Force the distinction every time. "We shipped X" gets the follow-up "and what moved because of it." If the honest answer is "we do not know yet," that is fine, but say so, and say when you will know.

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. This question does two things: it surfaces waste, and it trains the team to treat cost as a product concern rather than someone else's spreadsheet.

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, then drifted. An eval score with a trend line is the only honest answer to "is this getting better or worse." 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. This surfaces the actual bet underneath the work. A team that can name what they might be wrong about has thought about the decision honestly. A team that only presents upside is managing your perception. As a bonus, naming downside is what earns a team a longer leash, because it signals judgment instead of bravado.

What to cut to make room

You cannot add five real questions to a review without removing the theater. Cut these:

The full roadmap walkthrough. You can read the roadmap async. Spending live executive time narrating it is the most expensive way to share a document.

The launch calendar. When something shipped is rarely a decision input. What it moved is.

Any slide that does not change a decision. This is the master test. Walk into the review and ask, for each slide, "what would we decide differently based on this." If the answer is nothing, the slide is theater and the time is a tax. Cut it.

The plain version

A product review should force a decision, not confirm that work is happening. The five questions (learn, outcome, cost, eval, willing-to-be-wrong) 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.

---

If you want a copy of the one-page review template I hand to teams, or a second opinion on your operating cadence, reach out on LinkedIn.

Further reading

• Marty Cagan / SVPG on product operating cadence and reviews
• Lenny Rachitsky on running effective product reviews
• Anthropic on evaluations as a first-class product metric