Builder
- Owns
- Feasibility, the shape of the solution, relative size, risk.
- Must not
- Set product commitments or service levels.
A method from FFFlow
Two sides. One document. Volleyed back and forth until both would sign it exactly as it stands.
Serve why this exists
Everyone agrees on what a good product requirements document should be: precise, testable requirements a team can build against and prove with tests.
Almost no one gets one. Product owns what the product should do. Engineering owns what can actually be built. Both need a hand in the document, and a document everyone owns is a document no one owns.
So the work turns into meetings, for weeks. Each one feels like progress, and none of them does the slow, exacting work of getting every requirement down to something you could test. Eventually someone in charge says enough, start coding, and the team calls it agile. The hard questions don’t go away. They come back later as rework.
Product Ping Pong gives the document one owner at every moment: whoever holds the ball. Product and engineering take turns. Each turn edits the document, and each hand-off carries the same promise: I would sign this exactly as it stands, if you will. It’s done when one side hands it back without changing a word.
The missing piece is AI, used intelligently. It does the thankless, brutal, diligent and boring work: getting every detail written down, and phrasing every requirement precisely enough to be falsifiable, so the team can actually build the thing the document describes.
The players seats, not people
The process defines what each seat owns, never who sits in it. A seat can be one person, a team, or an AI agent working on their behalf. Everyone sees every file at every turn. There are no side channels.
Around the table the AI does the legwork
Answers data questions from the code, the data and the tracker. Reports what it finds, with no opinion.
Keeps one shared fact sheet. When sources disagree, records which one wins and why.
Keeps the history out of the document: every turn memo and round summary, on the record.
Tidies the parking lot, merges duplicates, and routes big ideas to their own documents.
The ball one document
The document has eleven fixed headings and a soft ceiling of about 2,500 words. It describes the product as it should be, never the argument about it. Who proposed what, and what changed whose mind, lives in the turn memos and round summaries kept beside it.
Shape, not history. No “proposed by”, no round numbers, no who-said-what.
Roles, never people. “Any trained account owner can pick it up”, not a name.
No dates or estimates. Sizes are S M L XL, only to compare.
Numbers are cited. A value no one can back is written [provisional] until someone can.
The rally rounds and turns
On each turn a seat reads everything, responds to the last turn, edits the document, parks what doesn’t belong and writes a memo of 500 words or less. Then the checks run, and the turn only lands if they pass.
Round one is for data before rulings: each side asks the analyst for the numbers it needs before arguing a position. Later rounds narrow. If three rounds go by without agreement, the portfolio lead decides whether to split the work, park it, or play another round.
| Round | Serve | Return | Between rounds |
|---|---|---|---|
| Round 1 | Builder draftsfrom the inputs | Product respondsfiles data requests | Retro5 questions each |
| Round 2 | Builder turnnarrower now | Product turnevidence moves positions | Retrofindings F-n |
| Round 3 | Builder turnhands it over | Product: agreedhands it back unchanged | Convergedready to sign |
Out of play the parking lot
Every turn asks what doesn’t belong here. Parking costs nothing, so no one has to win an argument to keep a good thought. Each entry is one line, filed as one of four kinds.
ideaGood, but not this PRD.
planningScheduling and sequencing. Travels with the PRD to planning.
other-prdBelongs to a document that already exists.
splitBig enough to become its own PRD.
Change of ends the retro
Each seat answers in writing, 150 words or less per answer. The referee then writes the round summary: what moved, what’s still contested, and numbered findings that the owning seat must accept or reject on its next turn.
Match point how it ends
There is no closing ceremony. A seat that would sign the document hands it back exactly as it received it. Sign-off is yes or no. A condition is a change, and a change sends the ball back across the table.
After the match what you walk away with
Product Ping Pong stops at agreement. The converged document goes to whatever planning process you use, such as FFFlow’s roadmap and planning steps, with its parked planning items attached.
Back to FFFlow →