The fastest way to kill a clean MVP isn't a bad designer.
It's three smart people in the same Figma file at the same time.
That was our problem on the Happier Hours project a couple weeks ago. Wireframes for Batch 2 and Batch 3 were shaping up well. Then the client team did what well-meaning teams always do when something is shaping up well: they all jumped in to help.
Three stakeholders. One file. No tracking on who'd looked at what. Comments stacking on top of comments. One reviewer would resolve a thread and another would reopen it ten minutes later. By the time the designer opened the file the next morning, half the notes contradicted the other half.
Wireframes that had been "almost there" the previous afternoon were suddenly a battlefield.
This piece is about why that pattern is so common, why the standard fixes (better tools, better rubrics, more meetings) make it worse, and the boring rule that actually got Batch 3 shipping on the original timeline.
What this looks like from inside the team
The client lead put it plainly in our weekly:
Three stakeholders were in the file at the same time. There was no tracking for design edits. Feedback was colliding instead of compounding.
That's the line that stuck with me. "Colliding instead of compounding."
Most product teams I've worked with default to parallel review because parallel review feels collaborative. Everyone gets a voice. Everyone weighs in early. Nobody is a bottleneck. On paper, it's the inclusive option. In practice, it does the opposite of what it's selling.
When three smart people review the same file at the same time, you don't get three angles on the problem. You get three competing theories about what the file is even for, layered into the same Figma comments, with no thread of accountability. The designer's job stops being "solve the problem" and becomes "figure out which feedback to honor without offending anyone."
That's not collaboration. That's politics with mouse cursors.
And it isn't a tooling problem. Figma is doing exactly what it was built to do. The problem is the ritual on top of the tool.
Why parallel review feels right and isn't
Three things make parallel review feel like the correct default, even when it's actively breaking your timeline.
First, it looks fast. Everyone is "in there working on it." Comments accumulate. The file is busy. To a founder watching from outside, that activity reads as progress.
Second, it feels democratic. No reviewer is being put ahead of another. No one's opinion is being filtered. Each stakeholder gets to be heard in their own words.
Third, it sidesteps the political work of deciding who has authority over what. If everyone reviews at the same time, you never have to make explicit the fact that one reviewer's opinion has more weight than another's. You can pretend they're equal.
The cost is that the designer ends up doing all three of those jobs alone, after the fact, with worse information than the reviewers had.
The designer is the one who has to decide which of three contradictory pieces of feedback to follow. The designer is the one who has to filter the political signal from the design signal. The designer is the one who has to ask "did you mean this or that?" across three threads with three different people on three different schedules.
You moved the work, you didn't eliminate it. And you moved it to the person with the least authority and the least context.
The Happier Hours pattern, in detail
Here's the actual mechanic we changed.
Before, the cycle looked like this:
- Designer publishes Batch 2 wireframes to Figma.
- Notification goes to the three-person review team.
- All three open the file within a couple of hours.
- Comments arrive in parallel. Pat marks a button label confusing. Theresa marks the same button as needing different placement. A third reviewer marks the entire flow as out of scope for soft launch.
- The designer opens the file the next morning, sees 30 to 50 comments across overlapping threads, and tries to triangulate what's actually being asked for.
- Comments get resolved or partially addressed. Some get reopened. The cycle repeats for the next batch.
After, the cycle looks like this:
- Designer publishes Batch 2 wireframes to Figma.
- Pat reviews first, alone. He marks what's missing, what's wrong, what's unclear, what's out of scope. He doesn't filter or diplomatize. He just gets it down.
- Theresa reviews Pat's pass. Not the wireframes from scratch, Pat's pass. She agrees, disagrees, adds what Pat missed.
- Theresa consolidates everything into a single coherent comment set with priorities marked: must-have for soft launch, nice-to-have for v1, scope-creep flagged separately.
- The designer gets one round per batch. One.
The work that used to live in the designer's head (reconciling contradictory feedback, parsing scope vs. UX vs. content, deciding what to honor) now lives in the conversation between Pat and Theresa, which happens before the designer ever opens the file.
That conversation is short. It's specific. It's structured by the file in front of them, not by abstract opinions. And it's the part of the process that was previously invisible and uncompensated.
What changed in the data
I don't have a beautiful chart here. The change was visible in three concrete places.
Comment volume on each file dropped roughly 70 percent. Not because we suppressed feedback, but because the contradictory and duplicative comments never got written. Pat and Theresa hashed them out between themselves first.
Cycle time per batch dropped meaningfully. Batch 3, which had been forecast to slip into the following week, shipped on the original timeline. Not because we cut scope; because the review cycle stopped looping on itself.
The designer's apparent stress level dropped. I don't have a metric for that, but at the end of one of our syncs, the designer said: "is it weird that this feels less like firefighting now?" It wasn't weird. It was the ritual doing its job.
For a small project, those three results justify the rule on their own. For a larger project, where you're running this pattern across five or eight active files, they compound.
The deeper why
This is the part most operational fixes get wrong. They frame design and product review as collaboration problems and reach for collaboration tools.
Better commenting. Async video review. Real-time co-editing. AI summaries of comment threads. The premise is always that the bottleneck is information flow, so the answer is more information flow.
But the actual bottleneck on most teams I've watched is not information flow. It's signal-to-noise. Three reviewers in a file at once doesn't produce more signal. It produces three voices in a hallway, which the designer then has to filter into one set of decisions, alone, with no context for the political dynamics that drove the disagreement.
Serial review works because it forces the noise to resolve before it hits the designer. Two reviewers arguing with each other in advance is cheap. A designer trying to reconcile three contradictory comment threads is expensive.
And there's a second-order benefit: serial review forces the reviewers to actually engage with each other's reasoning. Pat has to read Theresa's comments before he agrees or disagrees. He can't just paste in his own opinion and walk away. That changes the conversation from "everyone deposits their opinion" to "two people make a decision together." Which is what review was supposed to be in the first place.
There's a third-order benefit, too, that took us a few weeks to notice. When reviews are serial, the reviewers themselves get sharper. Pat learned what Theresa would catch and started catching it himself on the first pass. Theresa learned what Pat would miss and started watching for it on the second pass. The pair developed a shared model of "what a good wireframe looks like for this client" that neither of them had alone. In parallel review, you never build that shared model because nobody is reading anyone else's work. Everyone is just dropping opinions into a void and hoping the designer sorts it.
The pair also stopped duplicating each other's critique. Roughly a third of the comments in the parallel-review files turned out to be the same observation written three different ways by three different people. Once Pat and Theresa were reading each other's work, that overlap collapsed. Less volume hitting the designer is good. Less DUPLICATIVE volume hitting the designer is the part that actually moves cycle time.
One more thing worth naming. Serial review made the disagreements between reviewers visible to themselves, which they hadn't been before. In parallel, two reviewers can hold contradictory opinions about the same wireframe and never know it; they're each looking at the file independently, dropping comments, and walking away. Serial review forces those contradictions into one conversation, where they have to be resolved. A handful of design disagreements that had been quietly festering for weeks got named, argued, and decided in the first three serial cycles.
Fighting Fair in design reviews, a 7-rule playbook
If you want to install this pattern on your team, here's the version we use. It's seven rules. Steal what's useful, ignore the rest.
- One primary reviewer per batch. Their job is the first pass. They write everything they think is wrong, missing, or unclear. They don't filter themselves.
- One secondary reviewer per batch. Their job is the second pass. They read the primary reviewer's comments before they read the file. They reconcile. They produce the consolidated comment set the designer will work from.
- Everyone else stays out of the file until the secondary reviewer publishes the consolidated set. Including the founder. Especially the founder.
- Comments get categorized as content, UX, or scope. Three different kinds of work. A content edit ("change this headline") is fast. A UX issue ("this flow doesn't work for first-time users") is medium. A scope change ("we need a whole new page for X") is a separate conversation and shouldn't be filed as a wireframe comment at all.
- Priorities get marked: soft-launch, v1, later. The designer should never have to guess whether a comment is must-have for the next milestone or wishlist for the future. If the secondary reviewer hasn't marked it, it doesn't get done.
- No new reviewers added mid-cycle. If a new stakeholder needs to weigh in, they weigh in on the NEXT batch, not the current one. Pulling a third person into an in-flight review collapses the whole rule set.
- The weekly captures what's been decided. Not what was commented on, what was decided. So nobody downstream is surprised by a decision that was made in a comment thread three days ago.
These rules look obvious on paper. The hard part is that they require somebody to say "you're not in this review" to a stakeholder who wants to be. That's the leadership move. The rule is easy. The "no" is hard.
The conversation this is really about
There's a version of this article that frames it as a Figma tip. "How to run better design reviews."
The honest version is that this is a conversation about leadership inside small product teams. About who has authority over what, and when, and why. About the difference between making everyone feel heard and actually making decisions.
The default in most growing companies is to keep things implicit. Everyone weighs in, nobody is in charge, and the team prides itself on being non-hierarchical. Until something needs to ship, and the implicit politics surface as a comment storm on a Figma file.
The boring move is to make the authority explicit. First reviewer. Second reviewer. Designer. Done. Two named roles, one decision pathway, one consolidated output per batch.
It costs you the comfort of pretending everyone's opinion has equal weight. It buys you a shippable MVP.
That's a trade most founders eventually figure out they should make. The ones who don't end up running their fourth design sprint on the same wireframes, six weeks behind the original timeline, telling themselves they just need a better designer.
Where this connects to the broader pattern
This pattern shows up in a lot of places besides Figma.
It shows up in sales review. Three account executives, one deal, no clear primary on the close. The deal stalls because nobody can decide whose call gets to win the customer's attention.
It shows up in code review. Three engineers commenting on one pull request with no consensus mechanism, the author spinning for days trying to satisfy contradictory feedback.
It shows up in content review. Three executives marking up the same draft email, the writer choosing whose changes to honor based on org-chart politics instead of editorial logic.
In every case, the diagnosis is the same: parallel review of an artifact that needs serial review. The fix is the same: name a first and a final, keep everyone else out, deliver one set of changes to the maker.
I've written elsewhere about the gap between collaboration that feels good and collaboration that produces shippable work. The Pipeline Problem article is about the marketing version of this same pattern, where activity disguises itself as outcome. And The Founder Nobody Sees gets into the operating-partner version, where the person doing the unglamorous coordination work is also the person who has to install rules like this one.
Different surfaces, same underlying move: trade the comfort of parallel for the speed of serial.
What to do this week
If your design reviews feel like a group chat that never ends, run this experiment on your next sprint.
Pick one batch of wireframes. Name the first reviewer. Name the final reviewer. Tell everyone else, in writing, that they're out of the file until the consolidated comment set is published.
Run the sprint. Measure two things:
How many comments hit the designer this round, versus the previous round.
How the designer feels at the end of it. Ask them. Don't infer it.
If the numbers move and the designer breathes easier, install the rule for the next batch and the one after that. If neither moves, the ritual probably wasn't your bottleneck and you can keep looking.
You don't need more collaboration features. You need more sequence.
That's the boring rule that saves the MVP. Use it.