A Good Product Requirement Isn't What Gets Written. It's What Gets Agreed Upon.

I used to think a good PRD meant comprehensive specs. Every edge case documented. User stories formatted perfectly. Acceptance criteria that covered everything.

Then I joined Sonic Linker's founding team and realized we didn't have time for that. We had 3 months to ship a working AI SaaS product. If I spent 2 weeks writing beautiful requirements, we'd miss our window.

So I tried something different. I wrote a half-page doc that just said: "Users need to paste a URL and get an AI-generated summary in under 10 seconds. If it takes longer, they'll close the tab. That's the whole job."

The eng lead read it. Asked three questions. We sketched the flow on a whiteboard. Started building the next day.

We shipped in 11 weeks.

The problem with most PRDs is they optimize for coverage, not clarity

At Finvestfx, I managed 20+ enterprise clients in forex and treasury. These were banks and large corporates. They'd send feature requests that were... complicated. Multi-currency reconciliation workflows. Audit trails that needed to sync across 4 different systems. Compliance requirements I didn't fully understand.

Early on, I'd write long PRDs trying to capture everything they said. I'd send it to engineering. They'd come back confused. "Wait, does this need to happen real-time or can it batch overnight?" I didn't know. The client email didn't say.

So I started doing something else. Before writing anything, I'd get on a call with the client and the tech lead. I'd ask dumb questions until I actually understood the problem. "Why does the reconciliation need to happen daily instead of weekly?" Turns out, it didn't. The client just assumed that's what we'd build.

That one question saved us 3 weeks of dev time.

The PRD I wrote after that call was shorter. But it was clear. Everyone knew what we were building and why. That's what made it good.

Good requirements have one thing in common: someone can say "no, that's not it" when you build the wrong thing

When I worked with NJ Group coaching 60+ insurance advisors and IFAs, I had to help them adopt new product features. These weren't engineers. They were sales folks who just wanted tools that made their job easier.

I'd watch them use the product and ask what they needed. They'd say things like "I need better reporting." Okay, but what does that mean?

I learned to push. "Show me the report you're using now. What's missing?" They'd pull up an Excel sheet. "See this column? I have to manually copy this data from three different screens. If the system just gave me this in one place, I'd save 20 minutes per client."

That's a good requirement. It's specific. I can build something. And more importantly, when I show them the first version, they can tell me if it's right or wrong.

At Sonic Linker, we built an AI feature that was supposed to "help users find relevant content faster." Vague, right? We built it. Users didn't use it. Why? Because "faster" wasn't the problem. The problem was they didn't trust the AI's suggestions.

If I'd written the requirement as "users need to trust that the AI is showing them the right content," we would've built something completely different. Maybe we would've shown confidence scores. Maybe we would've let them filter by source. I don't know. But at least we would've been solving the right problem.

The best requirements I've written were the ones where I fought the hardest with stakeholders upfront

At Stampede Capital, I worked on a pre-IPO equity platform. Lots of regulatory constraints. Lots of stakeholder opinions. Sales wanted features that would close deals. Compliance wanted features that wouldn't get us sued. Engineering wanted features that were technically feasible.

I could've written a PRD that tried to make everyone happy. Instead, I got everyone in a room and made them argue it out. "If we build this compliance feature, we'll delay the sales feature by 6 weeks. Which matters more right now?"

That meeting sucked. People got frustrated. But by the end, we all agreed on what we were building and why. The PRD I wrote after that was 2 pages. But it was rock solid. No one came back later saying "wait, I thought we were doing it this way."

That's the thing about good requirements. They're not good because they're detailed. They're good because everyone agrees on what success looks like before you start building.

What I actually do now

I don't write PRDs first anymore. I start with a problem statement. One paragraph. "Users are churning because X. We think if we build Y, they'll stay because Z."

Then I validate that with data or user interviews. If I can't validate it, I don't write a PRD. I go back and find a better problem.

Once I know the problem is real, I sketch the solution with engineering. Literally sketch. Whiteboard or Figma. Get alignment on the approach.

Then I write the PRD. But by that point, it's not a spec. It's a record of what we already agreed on. The hard work already happened.

A good requirement isn't what gets written. It's what gets agreed upon. If you're spending more time formatting your PRD than talking to users and engineering, you're doing it backwards.