A fair review starts with the same standard

Accelerator review often fails before the first score is given. The team enters the room with a story, the reviewer enters with a private standard, and everyone mistakes energy for evidence. A fair review starts by naming the claim under review in plain language: who has the problem, what behavior proves it, and what would make the team change course.

That shared claim matters because founders do not need easier questions. Easier questions create false comfort. The useful version is a harder question asked clearly enough that the available evidence can answer it. A team with thin proof should know exactly which part is thin: the customer segment, the repeated behavior, the willingness to pay, or the delivery path.

The standard should stay stable even when support changes. A first-time founder may need more time to prepare the interview trail. A technical team may need help translating product velocity into customer learning. A non-native English speaker may need a slower review cadence. None of those accommodations require lowering the bar for proof.

The opposite is also true. A polished founder should not receive extra credit for sounding investable when the evidence is vague. Fluency can hide missing work. The job of review is to separate strong people from strong proof, because programs that confuse the two reward performance instead of learning.

A useful review ends with a narrower next move. Not “talk to more customers,” but “find three budget owners who tried to solve this in the last ninety days.” Not “improve the deck,” but “replace the market-size slide with evidence of repeated urgency.” The clearer the standard, the less theatrical the feedback becomes.

Fairness, then, is not softness. It is consistency. Every team should know what claim is being tested, what evidence counts, and what support is available without changing the standard. That is how review becomes an operating instrument rather than a personality contest.