Specs
Do you actually need a PRD for this?
Half the team writes a spec for every feature. The other half put everything in the Jira ticket. Both are right sometimes — and the disagreement is the tell.
Three threads, one question. One PM argued no unit below a release needs a full PRD. Another gave up on docs entirely and puts everything in the Jira ticket — and reports no drop in output. A third is frustrated that engineering wants a full spec for a fix where the what and the why are obvious. They're all describing the same decision: when is a PRD worth it, and when is it ceremony?
The honest answer: it's a risk decision, not a rule
A PRD is insurance against misalignment. The question isn't "is this big enough for a PRD" — it's "how expensive is it if we get this wrong, and how likely is that?" High cost of being wrong, or high chance of misinterpretation, earns a spec. Low on both, the Jira ticket is fine and the PRD is theater.
Most of the disagreement comes from applying a single rule to a spectrum. "Always write a PRD" wastes time on obvious fixes. "Never write one, just use tickets" works right up until the change touches three systems and nobody wrote down the edge cases.
When "it's obvious" is the trap
The PM who said the what and why are obvious — the HSA app doesn't track where funds were spent, the fix is to track it — is usually right that the problem is obvious. But "obvious problem" and "obvious solution" are different things. The edge cases hide in the solution: what about pending transactions, refunds, partial spends, multi-currency? Engineering asking for a spec isn't bureaucracy. It's them saying "the problem is clear, the behavior at the boundaries isn't, and we're the ones who'll have to guess if you don't write it down."
The middle path: scale the spec to the risk
- Trivial, low-risk change — a well-written ticket with clear acceptance criteria is the whole spec. Don't gold-plate it.
- Obvious problem, non-trivial behavior — skip the narrative, but write the edge cases and the boundary behavior. That's the part that's actually unclear.
- New feature or cross-system change — full spec, because the cost of misalignment is real and the gaps are many.
The "PRD vs. Jira ticket" debate dissolves once you stop treating it as binary. The document isn't the point; the right amount of pinned-down decision is. Sometimes that fits in a ticket. Sometimes it doesn't. The skill is calibrating, not picking a side.
- A PRD is insurance — write one when the cost or likelihood of being wrong is high.
- An obvious problem doesn't mean an obvious solution; edge cases hide in the behavior.
- Engineering asking for a spec usually means the boundaries aren't pinned down.
- Scale the spec to the risk instead of treating PRD-vs-ticket as binary.
Right-size your specs in Cadenly
Cadenly's staged pipeline lets you go as deep as the risk demands — a quick spec for the obvious fix, a full flow-and-gap pass for the change that touches everything.
Start free →