I Wrote 40+ PRDs in a Year. Here's What Made 3 of Them Actually Good.

I used to think a good PRD was one that covered every edge case. Turns out, that's exactly what makes most PRDs useless.

At Sonic Linker, I shipped our core AI product in 3 months. At Finvestfx, I managed requirements for 20+ enterprise treasury teams who all wanted slightly different things. I've written PRDs that got built in two weeks and PRDs that sat in backlog hell for months.

The difference wasn't how detailed they were. It was whether they answered one brutal question: why does this specific thing matter more than everything else we could build right now?

The Problem With Most PRDs Is They're Just Feature Descriptions

Here's what I used to do. I'd talk to a client, hear their pain point, write down exactly what they asked for, add some acceptance criteria, and call it a PRD. Done.

Then engineering would build it, we'd ship it, and... nothing. Adoption was flat. The client who asked for it used it twice. Other clients ignored it completely.

I realized the issue at Finvestfx when a treasury manager asked for a "bulk upload feature for FX transactions." I wrote it up. We built it. Six weeks later, I checked usage. Zero. Literally zero uploads.

I called him. Turns out what he actually needed was faster reconciliation between their ERP and our platform. Bulk upload was just his best guess at a solution. He didn't need to upload more transactions. He needed to stop manually cross-checking them.

That's when it clicked. A good requirement isn't what the user asks for. It's the outcome they're trying to reach, written clearly enough that your team can figure out the right solution.

What Actually Makes a Requirement Good

The PRDs that worked, the ones that got built fast and actually moved metrics, had three things:

1. A specific user outcome, not a feature description

Bad: "Add a dashboard for treasury managers."

Good: "Treasury managers need to spot FX exposure risks within 5 minutes of opening the platform, so they can hedge before market hours end."

The second one tells engineering *why* speed matters, *what* constitutes success, and *who* we're solving for. The first one just asks for a dashboard, which could mean anything.

2. A measurable business impact tied to it

At Sonic Linker, I wrote a PRD for improving our AI model's response accuracy. First draft said "increase accuracy." Useless.

I rewrote it: "Reduce user query resubmissions by 30% in the next sprint, because every resubmission costs us API calls and kills trust in the product."

Now engineering knows what success looks like *and* why it's worth prioritizing over other work. We hit that target in two weeks because the goal was crystal clear.

3. Constraints that force clarity, not flexibility

This sounds backwards, but the best PRDs I wrote had tight constraints. I'd say things like:

"This needs to work with our existing auth system, no new login flow."

"Mobile-first. If it doesn't work on a phone, it doesn't ship."

"No custom logic per client. One solution for all 20 enterprise customers."

Constraints force you to think hard about what actually matters. At Finvestfx, I had clients asking for wildly different reporting formats. I could've written a PRD for "customizable reports" and let engineering build a nightmare of configuration options.

Instead, I wrote: "All clients get the same 5 core reports, editable only by date range and currency. If a client needs more, we do a manual export once a month."

We shipped in 3 weeks instead of 3 months. Retention stayed strong. Turns out, nobody actually wanted infinite customization. They just wanted their data fast.

The Real Test: Can Someone Argue With It?

Here's my filter now. If I write a PRD and nobody pushes back, it's probably too vague.

Good requirements create healthy tension. Engineering might say "this timeline is aggressive." Design might say "this conflicts with our navigation paradigm." Sales might say "this won't work for our biggest prospect."

That's exactly what you want. Because if a PRD generates real questions, it means you've been specific enough to be wrong. And being specific enough to be wrong is the only way to be specific enough to be right.

At NJ Group, I worked with 60 insurance advisors on product adoption. I wrote a requirement: "Advisors need to generate a client proposal in under 10 minutes, including risk profiling and product recommendations, because anything longer and they lose the client's attention."

Our ops team immediately pushed back. "Ten minutes is impossible with our current workflows." Perfect. Now we had a real conversation about what we'd need to cut, automate, or redesign.

We didn't hit 10 minutes at first. We hit 18. But that was still a massive improvement from 45, and we only got there because the requirement forced us to have hard prioritization discussions.

What I Do Now

Before I write a single acceptance criterion, I write three sentences:

1. Who has this problem and what are they trying to do?
2. Why does solving this move our core metric (revenue, retention, activation)?
3. What is the simplest version that delivers 80% of the value?

If I can't answer those clearly, I don't write the PRD yet. I go back and talk to more users, or I kill the idea entirely.

Most "bad" requirements aren't bad because they're incomplete. They're bad because they're solving the wrong problem, or they're solving the right problem in the most complicated way possible.

The best PRD I ever wrote at Sonic Linker was 200 words. It described one user pain point, one success metric, and one constraint. Engineering built it in a week. It became our most-used feature within a month.

That's what good looks like. Not comprehensive. Not detailed. Just ruthlessly clear about what matters and why.