Requirements
PRD mistakes that cause rework
Most rework is born in the requirements, not the code. Here are the PRD mistakes that reliably turn into wasted engineering weeks — and how to avoid them.
When engineering burns a week building the wrong thing, the post-mortem usually points at the code. Look earlier. A Carnegie Mellon study found 60–80% of development cost goes into rework, and most of it traces back to the requirements. Here are the PRD mistakes that reliably cause it.
Vague requirements
"The system should be fast." Fast how? For whom? Under what load? Ambiguity doesn't disappear — it gets resolved by whoever builds the feature, often differently than you intended, and you find out at review. Every vague requirement is a deferred argument plus the rework to settle it. Replace adjectives with specifics: "search returns results in under 300ms for the 95th percentile."
No success metric
Without a measurable target, you can't tell whether the feature worked, so you can't learn, and you'll rebuild based on opinion next time. "Improve onboarding" gives you nothing; "cut onboarding time from 5 to 3 minutes" gives you a verdict.
Hidden assumptions
Every PRD rests on assumptions — about users, data, behavior. The dangerous ones are the unstated ones, because engineering inherits them silently and builds on sand. Surface assumptions as explicit open questions. "Assumes users have verified emails before this flow — confirm" is a gift to the team; the same assumption left implicit is a future bug.
Silent edits
Changing a requirement without telling anyone is how two teams end up building different products. Version the document, communicate changes, and when you adjust priorities or add requirements, assess the impact on work already in flight. Requirements evolve — that's fine — but the evolution has to be visible.
Smuggling in solution design
Specifying how to build it (schemas, frameworks) in the PRD over-constrains the people best placed to make those calls and ages badly as implementation details change. Keep the PRD on the what; let the spec own the how.
- Vague requirements are the top cause of rework — be specific or expect interpretation drift.
- No success metric means no way to know if the build worked.
- Silent edits split teams; version and communicate every change.
- Solution design in the PRD over-constrains engineering and ages fast.
Try the PRD workflow in Cadenly
Cadenly catches these as you write — flagging vague sections, missing metrics, and contradictions between steps before they reach engineering.
Start free →