What goes in a product decision document: 17 fields most teams forget

Why product borrowed the wrong half of ADRs

Engineering has Architecture Decision Records. Every meaningful technical choice gets a markdown file with context, options, decision, consequences.

Product copied the format and removed the parts that mattered.

Most product decision docs in the wild are: problem statement, proposed solution, scope, owner.

That's a one-shot artefact. It captures the decision but not the conditions under which the decision was correct.

When the conditions change — and they always do — there's nothing to re-evaluate against.

The 17 fields

• 1. Decision title — short, specific, dated.
• 2. Decision owner — single human, not a team.
• 3. Decision date — when the call was made, not when the doc was written.
• 4. Status — proposed, accepted, superseded, expired.
• 5. Problem statement — the customer or business problem this addresses.
• 6. Options considered — at least three, including the do-nothing option.
• 7. Chosen option — and a one-sentence reason it beat the others.
• 8. Supporting evidence — links to source. Tickets, events, transcripts, dashboards.
• 9. Contradicting evidence — counter-signal that argues against the choice.
• 10. Explicit assumptions — the statements that need to be true for this to work.
• 11. Expiry triggers — the specific signals that would invalidate this decision.
• 12. Confidence level at time of decision — low, medium, or high.
• 13. Reversibility — one-way door, two-way door, or somewhere in between.
• 14. Rollback plan — what we do if the decision goes wrong.
• 15. Success metrics — how we'll know it worked. Hard numbers, dated.
• 16. Review date — when this decision will be re-evaluated.
• 17. Linked decisions — upstream decisions this depends on, downstream decisions it enables.

The four fields most teams skip

Most teams write fields 1, 2, 5, 7, and 15 and call it a decision doc.

The four that actually pay back over time are 9, 11, 12, and 13.

Field 9 — contradicting evidence — is what makes the decision honest. Without it, the doc is a sales pitch.

Field 11 — expiry triggers — is what makes the decision operable. Without it, nobody knows when to revisit.

Field 12 — confidence at time of decision — is what protects you from hindsight bias. A high-confidence decision that fails is a different lesson than a low-confidence experiment that fails.

Field 13 — reversibility — is what lets you size the risk. A two-way door doesn't need the same scrutiny as a one-way door.

An example, partially filled

Decision title: Adopt usage-based pricing for the API tier (2026 Q2).

Owner: Mira (PM).

Status: accepted.

Chosen option: usage-based pricing with a $99/mo platform fee. Beat seat-based because of three enterprise contracts where seat counts are unstable.

Supporting evidence: 4 enterprise sales calls (Gong links), churn analysis on seat-based tier (PostHog cohort), 7 inbound requests for usage pricing (Intercom).

Contradicting evidence: SMB cohort prefers predictable monthly billing — 12 cancellations in pilot citing 'bill anxiety' (Stripe + Intercom).

Expiry triggers: SMB churn rate exceeds 6% for two consecutive months. Or median enterprise contract value drops below $20k ARR.

Confidence: medium. Reversibility: two-way door (pricing can be changed).

Review date: 2026-08-01.

How to use the schema

Don't make this a Notion form with 17 mandatory fields. That kills adoption.

Treat the 17 as a checklist. The doc is whatever shape your team likes — markdown, Linear issue, Airtable row.

What matters is that the 17 questions get answered, not that they appear in a specific order.

Synchronise stores decisions in this shape under the hood. The fields above are the open spec — adopt them in whatever tool you already use.