Can You Review My PRD?

As a Distinguished Engineer most of my peers aren’t just makers or builders, they’re thinkers. They add value to their teams by generating ideas most others don’t conceive of. Where years ago those ideas took weeks or months to coalesce into a shareable form (PRD, RFC, etc.), today that can happen in hours or days with the help of AI agents. What a time to be alive!

I realized recently that while every so often one of them sends me a: “Hey, can you review my PRD and tell me what you think of this project?”, the mental cost of giving that input is much larger than their cost to produce it. It’s long, and that’s nobody’s fault. The agent that helped write it will gladly produce as much as you ask for, so a thorough PRD now takes an afternoon to write instead of a month.

So I have three options, none of them great. I can skim it and send back a few comments. I can block off most of a day and read it properly (which I don’t have to spare, and neither does anyone else who got the same message). Or I can hand it to my own agent and forward whatever it says, at which point two AIs have reviewed each other and no human has thought about the project at all. (Try to guess how often this is happening where you work. Try not to get sick while you do.)

The cost moved to the reader

For a while I figured the problem was that I read too slowly or said yes to too many things. Then it hit me that the calculus had changed without us realizing. We’re still operating on 2022 models of produce/review loops.

While AI made writing cheap, it did nothing for reading. A document my colleague produced in an afternoon still takes me the better part of a day to understand well enough to have a real opinion about it. So every “can you review this?” quietly moves the expensive half of the work from the person who wrote it to the person who has to read it. Multiply that by everyone on a team who’s moving fast with an agent, and nobody can keep up with anybody.

And, realize that I and my colleagues genuinely WANT to help each other. We absolutely geek out on sharing ideas, planning the future, and making miracles happen that nobody thought possible. That’s the whole job as a DE. Like literally.

The usual fixes don’t help much. Should we stay in our own lanes and just trust each other? (Not fun.) Do we slow down and “Pace the AI”? (Lame.) Or maybe we just set aside time for cross-project review? (Time is infinite, right?) Those are three answers to one question: how much of each other’s output should we absorb? When the output is effectively unlimited, the honest answer is less than we’d like, no matter which option we pick.

What a PRD can’t tell me

The actual problem each of us is trying to share with each other is hiding in the volume of data we need to consume and evaluate. Even a short PRD makes for a hard review, and I wrote about why a couple of months ago in Ideal State Articulation.

A PRD describes what the team will build: features, behaviors, deliverables. What I actually need to judge is what really happens after you deliver it, and most PRDs never actually get that far. So when I review one, the only thing I can really check is whether the list looks complete, especially when an agent producing that list thought a longer list would be a better one. A team can ship every line of a requirements doc and still miss the point, and nothing in the doc would have warned anybody.

My colleague asked what I think of the project. To answer that honestly, I need to know what they intended to achieve as an end state. Nobody needs the whole PRD to tell you whether you’re building the right thing. They need the goal, written down in a way that could turn out to be wrong.

Put the intent on top

So I think going forward I’ll start asking for something different, and sending it too. Before I try to read the document I’ll ask for four things only the author knows and AI can’t produce:

The problem: what’s broken right now, specifically.

When it works: what’s true once this ships, stated so it could fail.

What it must not become: the failure they’re refusing in advance.

Where they’re least sure: the part they really want my eyes on.

The second line does most of the work. “Onboarding is easier” can’t fail; almost anything you ship will satisfy it. “A new manager can find last month’s incident report in under a minute without asking anyone” can fail, which means someone else can check it. The test from the ideal-state post applies here too: could a stranger, reading only that line, judge later whether you got there?

The third line is the one people skip, and I think it is critical for a human reviewer. Naming what the project must not turn into (“must not add a login step,” “must not need a person to approve every request”) tells me where the author thinks the danger is. If I think the danger is somewhere else, that’s the most useful thing I can tell them.

The review gets short, and better

With those four things in hand, a review stops being a reading assignment. It takes a couple of minutes, and my job changes from checking a list to checking their tests. Would “when it works” actually fail if the project went sideways? Is the thing it must not become the real risk, or just a safe one they picked because it was easy to write down? Those are judgment calls, and judgment is the part I’m actually good for.

The full PRD is still there, and now I can point my own agent at it with a much sharper question than “review this”: if the team builds everything in here, does “when it works” come true, and does anything in it drift toward “must not become”? Agents are really good at that kind of check. It keeps my attention on the part that needs a human, and it keeps the agent doing the reading it’s great at.

Does the detail still matter? Sometimes, absolutely. An API contract, a security design, anything somebody is going to sign off on: those need a careful read, and four lines on top won’t replace that. They will aim that careful read at the right place instead of spreading it thin across the whole document. (Anyone who has done a security review of a massive design doc knows exactly what I mean.)

If they can’t answer the four questions

Fair warning: those four things are harder to write than the PRD. The agent can’t produce them, because they’re about what the author believes, what they’re worried about, and what they’re unsure of, and only the author knows those things.

That cuts both ways. If I can’t fill in “when it works” for my own project with something that could fail, I don’t have an intent yet. I have a wish with a PRD stapled to it.

Better to find that out before anyone else spends a day reading. The agent happily let me skip the thinking, and the four questions make me go back and do it.

Intents are small enough to overlap

This is the part I get REALLY excited about: what happens when everybody does this.

Projects are too big to compare. I can’t hold your project and mine side by side and notice where they collide, because there’s too much of each. Intents are small enough to compare. When your “must not add a login step” sits next to my plan for a new verification screen, we can both see the collision in about ten seconds, long before it shows up in production (and long before the Slack thread where we figure out whose fault it was). And when your “when it works” reads almost word for word like mine, we’re working on the same problem from different ends. That’s where the real collaboration starts, and it’s the part of this job we all signed up for.

Try it on the next one

The next time someone asks you to review their PRD, don’t open it first. Write back: “Happy to! What does done look like, and how would we know if it failed?”

It can feel a little rude to answer a request with a question. My bet is they’ll be relieved, because it tells them you’re taking the project seriously instead of skimming it (or quietly handing it to your agent). And the next time you’re the one asking, put your four lines on top before you hit send. It’ll save you both some headaches later.

We can’t keep up with each other’s work anymore, and I don’t think we should try. We can keep up with what each other intends.