Craft
How to Run a Product Critique: Roles, Rules, Records
The design-crit ritual applied to a spec: who presents, how to frame the draft, which feedback is in bounds, and how findings get written down.
Most product teams have two ways to get feedback on a spec: a comment thread nobody finishes, and a review meeting where the draft is supposed to be done. Neither is a critique. The first is too thin to change anything. The second arrives when change is expensive, and everyone knows it.
Design teams have a ritual for the gap between those two: the crit. Work goes up while it is still rough, the designer says what it is meant to do, and the room critiques it against that aim. Nobody approves anything. The designer leaves with a list and decides what to do with it.
A product critique is that ritual applied to a spec. It is the cheapest point in a project to hear that the scope is cut in the wrong place, and most PMs never get one. Here is how to run it: roles, framing, ground rules, what is in bounds, and how findings get recorded.
Critique is not review
Teams that blur the two get the worst of both: a soft draft judged as if it were final, or a final draft treated as open for redesign.
| Product critique | Spec review meeting | |
|---|---|---|
| When | The draft is shaped, not finished | The draft is meant to be ready |
| The question | Does this meet its own objective? | Can we build this? |
| Output | Findings, owned by the presenter | A verdict: ship, revise or rethink |
| Who decides | The presenter, afterwards | A named decider, in the room |
| Mood | Exploratory | Convergent |
A critique produces no decision, and that is the point. Because nothing is being approved, people say the uncomfortable thing earlier, and the presenter can hear it without defending a position. The decision comes later, in a spec review meeting with its own format.
Four roles, named before you start
The presenter is the spec's author. They frame the draft, then mostly listen. They can answer a clarifying question ("does admin here include workspace owners?") but they do not respond to critique in the room. Every rebuttal costs a finding, because a critiquer who gets argued with stops offering the next one.
The facilitator is anyone but the presenter. They keep time, enforce the ground rules, and turn out-of-bounds comments into usable ones. Skip this role and the critique becomes a meeting about preferences.
Three to five critiquers, chosen for vantage point rather than seniority: an engineer who could build it, a designer, a PM from another team, and someone who hears from customers. Fewer than three and you get one person's opinion. More than five and nobody gets a second turn.
A note-taker who is not the presenter. A presenter who also types will paraphrase each finding into one they agree with.
The person who will approve the work is optional. If they come, they critique like everyone else.
The framing: three minutes, four statements
The presenter opens with four things, written at the top of the doc so they stay visible:
- Stage. Rough, shaped, or nearly final. This tells critiquers how deep to go.
- Objective. The problem, the user, and how you will know it worked. Every finding gets measured against this, so it has to be explicit.
- What you want critiqued. Two or three specific questions. "Is the scope cut defensible?" "Does the permission model hold for shared workspaces?"
- What is settled. Decisions already made, with a pointer to where they were recorded. These are out of bounds unless someone brings new evidence.
An illustration of a whole framing, for a spec about bulk-inviting members from a CSV file:
Shaped, not final. Objective: admins at large accounts can onboard a whole team in one sitting; success is fewer support tickets about manual invites. I want critique on the duplicate-handling rules and on whether a 500-row limit is the right cut. Settled: no SSO provisioning in this release, recorded in the decision log on 12 September.
Ninety seconds to read. Nothing else shapes the session as much.
Ground rules
Critique against the objective, not your taste. "I'd use a modal" is a preference. "An admin loses their place in a long file if errors only appear after upload" is a critique, because it ties to the stated user and goal.
Point at the line. Every finding names the section it concerns. If you cannot say where it lives, it is a thought, and thoughts go in comments afterwards.
Ask before you suggest. "What happens when a row matches an existing member?" invites the presenter to find the gap. "Just skip duplicates" hands them a solution to a problem nobody has agreed exists yet.
One point per turn. Go round the room, most important point first. This stops the quiet engineer's single blocker losing to the talkative PM's six minors.
Settled stays settled. Reopening a recorded decision needs new information, not a new opinion.
The presenter owns the response. Nobody leaves expecting their suggestion to be adopted. The critique is input; the presenter is accountable for what they do with it.
What feedback is in bounds
Holding this line is the facilitator's main job. Put the list on screen.
In bounds:
- Whether the spec solves the stated problem for the stated user.
- A state, case or actor the spec does not name.
- Whether the metric would move if the feature worked, and stay flat if it did not.
- Whether the scope cut is in a defensible place, and what the excluded thing costs.
- Whether an engineer could start from this, and which question they would ask first.
- Anything that contradicts something else in the doc.
Out of bounds:
- Visual or wording preferences with no reason tied to the objective.
- Solutions issued as instructions.
- Features outside the stated scope ("while we're here, could it also…").
- Copy-editing. Leave it as a comment.
- Reopening settled decisions without new evidence.
When an out-of-bounds comment lands, the facilitator reframes it rather than shutting it down. "I'd just use tabs" becomes "what problem would tabs solve that the current layout does not?" Sometimes there is a real finding inside the preference. Often there is not, and the question shows that without anyone being told off.
Recording findings so they survive
A critique that ends in a page of notes has produced a page of notes. Findings need a shape the presenter can act on, and they belong in the spec, not in a meeting doc nobody opens again.
The note-taker writes each finding as a comment on the line it concerns, with four parts:
- Where: the section or sentence.
- What: the observation, in one sentence.
- Kind: missing, unclear or disagreed, the three buckets from reviewing someone else's PRD.
- Who raised it, so the presenter can follow up.
Within a day, the presenter replies to each one with a disposition: changed (and where), declined (with a one-line reason), or open (with an owner and a date). Continuing the illustration, three findings from the bulk-invite session as they read once the presenter has replied:
Duplicates · Missing · No rule for a row that matches a pending invite.
Changed: section 5 now re-sends the existing invite instead of creating a second.
Limits · Disagreed · 500 rows may not cover the accounts that asked for this.
Open: check the seat distribution of those accounts. Owner: support lead, Friday.
Success · Missing · Ticket count has no baseline.
Changed: baseline added from last quarter's tagged tickets.
Declined findings are the ones most worth keeping. "Considered a 2,000-row limit, declined because long imports time out on the current job queue" is a decision record, written at the moment the decision was made.
What a critique does not replace
A critique is a judgement session, so do not spend it on mechanical gaps. If twenty minutes go on undefined terms and a missing error state, the questions only people can answer never come up. Run the mechanical pass first, by hand or with a tool.
That pass is the job our critique does: eleven passes, from Context Summary through Engineering Readiness and Edge Case & QA Drill to Synthesis & Final Verdict, with findings landed as comments marked blocker, major or minor, each with a suggested rewrite. It does not replace the room. It checks the document against itself; the room checks it against what people know.
When to hold one
After the problem and scope are written, before the requirements are detailed. That is when the cut can still move cheaply.
Again if the approach changes. A new approach is a new draft.
On a standing slot. A weekly forty-five minutes that any PM can claim beats ad hoc sessions: when critique is routine, asking for one stops signalling that something is wrong. A workable agenda: three minutes of framing, seven of silent reading, twenty-five of rounds, five for the presenter to play back what they heard, five to check the record. The playback catches mis-hearings while the critiquers are still there to correct them.
Critique is the review skill nobody teaches PMs, and a standing session is the cheapest way to teach it: everyone sees the moves made on someone else's draft before they need them on their own. For the solo version, see how to critique your own PRD.
FAQ
What is a product critique? A session where a draft spec is critiqued against its own stated objective, with no decision at the end.
How is it different from a spec review? Earlier, and it ends in findings, not a verdict.
Who should attend? A presenter, a facilitator, a note-taker and three to five critiquers.
What is out of bounds? Taste, mandates, wording, out-of-scope features and settled decisions.