Product Ping Pong

A method from FFFlow

Product Ping Pong

Two sides. One document. Volleyed back and forth until both would sign it exactly as it stands.

The ball is the PRD. Each hit is one turn. The referee keeps score and never touches it. Round 1 · Turn 1 · Builder

Serve why this exists

Everyone owns the PRD. So no one does.

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

Three seats at the table.

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.

Seat 1

Builder

Owns
Feasibility, the shape of the solution, relative size, risk.
Must not
Set product commitments or service levels.
Seat 2

Product

Owns
Outcomes, client experience, commitments, priorities.
Must not
Dictate implementation.
Seat 3 · the referee

Facilitator

Owns
Turn order, the checks, the retros, the score.
Must not
Touch the document. What it notices becomes a finding.

Around the table the AI does the legwork

Analyst

Answers data questions from the code, the data and the tracker. Reports what it finds, with no opinion.

Librarian

Keeps one shared fact sheet. When sources disagree, records which one wins and why.

Archivist

Keeps the history out of the document: every turn memo and round summary, on the record.

Curator

Tidies the parking lot, merges duplicates, and routes big ideas to their own documents.

The ball one document

What gets volleyed is a PRD with a fixed shape.

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.

<slug>-prd.md
  1. Problem
  2. Roles
  3. Outcomes and non-goals
  4. Journeys
  5. Requirements
  6. Service parameters
  7. Metrics
  8. Increments
  9. Risks
  10. Key decisions 0–3
  11. Open questions
Shape

Shape, not history. No “proposed by”, no round numbers, no who-said-what.

Roles

Roles, never people. “Any trained account owner can pick it up”, not a name.

Size

No dates or estimates. Sizes are S M L XL, only to compare.

Proof

Numbers are cited. A value no one can back is written [provisional] until someone can.

The rally rounds and turns

One turn per side, then a retro. Repeat until it comes back unchanged.

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.

RoundServeReturnBetween rounds
Round 1Builder draftsfrom the inputsProduct respondsfiles data requestsRetro5 questions each
Round 2Builder turnnarrower nowProduct turnevidence moves positionsRetrofindings F-n
Round 3Builder turnhands it overProduct: agreedhands it back unchangedConvergedready to sign
Builder turnProduct turnRefereeAgreement turn

Out of play the parking lot

Good ideas that aren’t this document get parked, not lost.

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.

idea

Good, but not this PRD.

planning

Scheduling and sequencing. Travels with the PRD to planning.

other-prd

Belongs to a document that already exists.

split

Big enough to become its own PRD.

Change of ends the retro

Every round ends with five questions, on the record.

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.

  1. What changed your mind this round, and on what evidence?
  2. What worries you most in the document as it stands?
  3. What would you give up to close faster?
  4. What are you assuming that isn’t written down?
  5. Did anything you parked deserve to be its own PRD?

Match point how it ends

Agreement is handing the ball back untouched.

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.

Status
Drafting
  • Turns are changing the document
  • Questions still open
Status
Converged
  • Last turn changed nothing
  • Zero open questions
  • Checks pass
Status
Ratified
  • Every seat signed yes
  • No provisional values left
  • Committed where the team agreed

After the match what you walk away with

A document both sides already agreed to, ready for planning.

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 →
# claude code
/plugin marketplace add zerotechdebt/ffflow
/plugin install ppp@ffflow

# start a match
/ppp:prd-start
/ppp:prd-turn
/ppp:prd-retro