You spent three weeks on a PRD that got ignored

A PM told a painful story. Finance had wanted better AP tooling for a year. The PM finally got it on the roadmap, spent three weeks embedded with the finance team, and wrote a thorough PRD. In sprint planning, the tech lead read it, looked up, and asked if they'd checked what already existed — then pulled up three tools in four minutes that covered most of the spec, two with APIs they could integrate in a fraction of the time. The ticket went to the backlog. Finance didn't care how it got solved; they just wanted the problem gone.

The PM's own conclusion was the right one: the question "should we build this at all" came from engineering in sprint planning, and it should have come from them six weeks earlier. A related thread — a PM whose PRD wasn't kept current and who got escalated when a requirement quietly slipped — is the same lesson from the other end: the expensive spec failure happens before or after the writing, never during it.

The miss was sequencing, not effort

Three weeks of work wasn't the problem. The work was good. It was just solution work done before validation work. The PM validated that finance had a problem — true, for a year — and skipped validating whether building was the right response to it. "Is this a real problem" and "should we build a solution" are different questions, and the second one is cheap to answer early and brutal to answer in sprint planning.

The cheap checks that would have saved three weeks

• Does a tool already solve this? The four-minute search the tech lead ran is a check you run before scoping, not after. "Build vs. buy vs. integrate" is a validation question, not an engineering afterthought.
• What does the customer actually want — the feature, or the outcome? Finance wanted the problem solved, not a custom build. When the outcome matters more than the artifact, integration usually wins, and you find that out by asking, not by speccing.
• Is the "why now" strong enough to beat everything else on the roadmap? A year-old low-grade frustration that no existing tool fixed is a different priority than one three SaaS products already solve.

The reframe

The lesson isn't "write specs faster" — a faster bad-sequence still ends in the backlog. It's "validate the should before you spec the what." A short validation pass — real problem, no existing solution, outcome worth a custom build, priority over the alternatives — costs a day and saves the three weeks. The spec was never wasted because it was slow. It was wasted because it answered "how" before anyone confirmed "whether."