From Spec to Spec Sheet: The PRD Habits That Actually Move Banks

From Spec to Spec Sheet: The PRD Habits That Actually Move Banks

Twenty-four years into product, I've written a lot of PRDs. Most of them weren't read. The ones that moved a bank from "interesting" to "implemented" had three things in common — and none of them are about format or template.

Lead with the regulator, not the user

Every product textbook tells you to start a PRD with a user persona. In fintech, this is half-true. The user matters, but in a regulated environment, the *regulator* is a stakeholder who can stop the launch cold. I now open every fintech PRD with a regulatory context paragraph: which jurisdiction, which directives, which reporting obligations. It does two things. It forces me to confront the constraints early. And it signals to engineering and compliance that I've done my homework.

If the PRD reaches a compliance officer who has to *teach* me my own product's regulatory frame, the document has already failed.

The "first 100 transactions" section

Every fintech product has a soft launch — a friends-and-family round, a controlled pilot, a low-volume rollout. Most PRDs gloss over this in a "go-to-market" section that's two bullet points long.

I now write a dedicated "first 100 transactions" section in every PRD. What does the monitoring look like? Which thresholds trigger a pause? Who's on the operations bridge? What's the rollback path if something funny shows up in the ledger? It's not glamorous, but it's the difference between a launch that earns trust with the bank and one that erodes it.

Acceptance criteria as conversation starters

Acceptance criteria, the way I see them written most often, are a transcript of obvious truths. *Given the customer is approved, when they swipe, then the transaction is authorised.* Yes. Thanks.

The acceptance criteria that actually move banks are the ones that surface the disagreements: what happens when the bureau is down, what happens when the issuer's authorisation host returns a degraded response, what happens when the network reverses a transaction after the customer has already received goods. These are the conversations engineering and risk teams want to have. The PRD is the place to start them, not avoid them.

The thing I won't do anymore

I used to write PRDs that tried to be comprehensive. Forty pages, every edge case enumerated. They were impressive and useless — nobody read them, and the team built from a Slack thread anyway.

Now I write PRDs that are deliberately incomplete. Fifteen pages, the contentious decisions front and centre, the obvious paths summarised. The implicit message: this is a starting point for a conversation, not the final answer. Banks — especially the good ones — appreciate that. They've been on the receiving end of too many forty-page documents that turned out to be wrong.

A PRD is a forecast of disagreement

The best PRDs I've written are forecasts of where the team will disagree. The worst ones are catalogues of what everyone already knows. If your document doesn't make at least three people uncomfortable in a good way, it probably isn't doing its job.