How much detail do engineers actually want in a PRD?

A PM at a startup that had been in maintenance mode described the clash: new engineers, hired from bigger orgs, expected a perfect PRD with every edge case considered — some even wanted BA-level system-design decisions with decision logs in the spec. The PM, from a move-fast background, made tradeoffs on the fly. The result was hour-long brainstorming calls and democratic votes because nobody had written the decisions down.

This is a real tension, not a simple "the engineers are gold-plating" or "the PM is sloppy." Both sides are responding rationally to a missing piece, and the missing piece isn't more detail. It's which detail.

What engineers actually need (vs. what they ask for)

"Every edge case considered" is what they say. What they need is narrower: the decisions only the PM can make, made. An engineer can figure out how to implement a sort. They can't figure out whether a refund should reverse the loyalty points, because that's a product call. When the spec leaves product decisions open, engineering has two bad options — guess, or stop and convene a meeting. The hour-long votes aren't them being difficult; they're the system filling a decision vacuum the spec left.

The line between PRD and system design

• The PRD owns the what and the why and the product-level decisions: what should happen, including at the boundaries — empty states, errors, conflicts, the refund-and-loyalty-points question. This is non-negotiable, and it's what "every edge case" really means.
• System design — how it's built — is engineering's call, and a PM writing decision logs for it is overreach that'll be wrong half the time. The engineers asking for BA-level design in the PRD are asking the PM to make calls that aren't theirs.

So the startup PM is right that they shouldn't be writing system-design decision logs, and the engineers are right that on-the-fly tradeoffs with nothing written down is chaos. The resolution isn't "more detail" or "less" — it's the PM nailing down every product decision, especially at the edges, and explicitly leaving the technical ones to engineering.

The fix for the hour-long votes

Run an explicit edge-case pass before the spec goes out: for each flow, what happens at every boundary, and which of those are product decisions you need to make now. Make them, write them down. The votes evaporate, because the only things left to discuss are genuinely technical — which is the conversation engineering should be having anyway.