Teardown: three tickets that should have been one
Fragmented tickets are usually a symptom of a decision that was never made.
Three tickets, filed weeks apart by three people, describing three symptoms of one unmade decision about how payment failures should behave. Each was estimated separately. Each was correct.
How it happens
Nobody decided the retry policy. In its absence, the gap surfaced three times in three contexts: a blocked engineering ticket, a design file with unlabelled error states, and a support complaint. None of them named the underlying decision, because from inside each context it looks like a local problem.
The cost is not duplication
It is that three partial fixes get built, none of which resolves the policy, and the system ends up with three behaviours. The duplicated effort is trivial next to the inconsistency it creates.
The tell
Multiple open items whose descriptions share a noun but not a component. When the same object appears in a blocked ticket, a design comment and a support thread, the missing thing is almost always a decision rather than a fix.
Stop writing PRDs without understanding the product.
Anchor reads your interviews, tickets and docs first — then writes, citing every line.
