---
name: product-decision-record
description: "Use when someone has made (or is about to lock in) a product or strategy bet — build-vs-buy, a pricing move, a target-segment choice, a platform pick, deprecating something customers rely on — and wants it written down so the call and its tradeoffs stay legible later. Captures four fixed parts: the decision, the context as it stood at the time, the options considered with why each was or wasn't chosen, and whether the bet is hard to undo or cheap to reverse — and lets that reversibility set how much rigor the record demands. Do NOT use to pitch a not-yet-made decision to a reader (that is a one-pager), to write a full spec/PRD, or to decide a live incident rollback."
metadata:
  decimalai-skill-id: "5ab70e0d-0572-4c0f-87ce-6a0cf5d4d2ec"
  decimalai-version-id: "60379384-1f19-482a-b05c-49366000a901"
  decimalai-version: "1"
  decimalai-body-sha256: "e17582883ca63ba5414e066853d3640a1d94f41011f79c40467534e3f6d19284"
  decimalai-name: "product-decision-record"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "documentation"
  decimalai-source: "https://app.decimal.ai/s/product-decision-record@1/SKILL.md"
---
# Product decision record

When someone asks to "write down the decision we made so we remember why," the base model reaches for
a generic engineering **ADR**: Title, Status, Context, Decision, Consequences. Two things go wrong.
First, it justifies only the path chosen — it argues *why this is right* and never records the roads
not taken or **why they lost**, so a future reader can't tell whether an option was weighed and
rejected or simply never considered. Second, it treats every decision as equally weighty, with no read
on whether the bet is one you can walk back cheaply or one you're stuck with.

A product decision record fixes both. It is a **record, not a pitch** — the decision is already made
(or being locked in now), so it is written in the settled past tense, not as persuasion. And it turns
on one product-specific idea the base model omits: **reversibility as a one-way vs two-way door**, which
sets how much scrutiny the record — and the decision behind it — deserves.

## The four fixed parts — always these, always in this order

1. **Decision** — the bet in one line: what we are doing, decided as of a date, and who owns it. Concrete
   enough to picture ("We are building onboarding in-house rather than buying vendor X, as of 2026-07"),
   not a topic ("onboarding"). One decision per record.
2. **Context** — the forces as they stood **at the time the call was made**: the constraint, the
   deadline, what we knew, and — critically — what we did *not* know. Snapshot it; write what was true
   then so the record stays legible after the world moves. Name the load-bearing assumptions explicitly
   so a later reader can see which ones, if they break, would reopen the decision.
3. **Options considered** — the real alternatives that were on the table, each with an honest reason it
   was or wasn't chosen. Record at least the **chosen** option (why it won) and one **rejected** one
   (why it lost) — more if they were genuinely weighed. This is the part the base model drops. The road
   not taken, with its rationale, is what stops a future team from blindly reopening settled ground — or
   from repeating an option that was already ruled out for a reason that still holds.
4. **Reversibility** — classify the bet as a **one-way door** or a **two-way door**, and say what that
   implies:
   - **Two-way door** — cheap and fast to reverse (a copy change, a meeting cadence, a time-boxed
     experiment on one segment, a trial of a tool). Bias to **decide fast and move on**; don't
     over-deliberate. Name a **revisit trigger** — a date or a signal that says "check whether this is
     working" — because the whole point is that you'll walk it back if it's wrong.
   - **One-way door** — hard, slow, or expensive to undo (a data migration, a core platform pick, a
     brand or naming choice, a multi-year contract, deprecating a public interface customers depend on).
     This warrants the real scrutiny: name the **cost of being wrong** and **what evidence would have
     changed the call**, so the weight of the decision is on the record.

## The rules that make it a record, not an ADR clone

- **It's a record, not a pitch.** The decision is made. Write it as settled fact ("We chose X"), not as
  a case for X. If you're still trying to convince a reader to approve something, that's a one-pager, not
  this.
- **Record the road not taken.** Every record names at least one rejected option and the honest reason it
  lost. A record that only defends the chosen path is advocacy wearing a record's clothes.
- **Let reversibility set the rigor.** The door type is not decoration — it changes the record. A two-way
  door with three pages of deliberation is wasted; a one-way door with a one-line justification is
  reckless. Match the depth of the record to the cost of being wrong.
- **Snapshot the context; don't retcon.** Write what was known *at decision time*, including the
  unknowns. Don't rewrite it later to look smarter than the room was. If new facts arrive, that's a new
  record superseding this one, not an edit to this one's history.
- **Name the assumptions that would reopen it.** State the beliefs the decision rests on. When one
  visibly breaks, the record tells the team it's time to revisit — that's how a record stays useful.
- **Product reversibility, not just code reversibility.** "Can we revert the commit" is not the question.
  The question is whether the *business* consequence — customers migrated, a brand in market, a contract
  signed, an interface others built on — can be unwound.

## What this is not

- Not a **one-pager or proposal** — that argues *whether* to decide and asks a reader for a yes. This
  records a decision *already* taken.
- Not a **spec or PRD** — that defines *how* to build. Link it from the decision line if it exists.
- Not an **incident rollback call** — deciding to revert a live deploy under fire is a different job.

## Shape to produce

```
[Title: the decision in one line]        (decided: YYYY-MM  ·  owner: name)

Decision   — the one bet we are making, concretely.
Context    — the forces, constraints, and unknowns as they stood at decision time;
             the load-bearing assumptions this rests on.
Options     — each real alternative with an honest reason it won or lost:
   • Chosen:   <option> — why it won.
   • Rejected: <option> — why it lost.
Reversibility — one-way door or two-way door, and what that implies:
   two-way → the revisit trigger (date/signal); bias was to decide fast.
   one-way → the cost of being wrong; what evidence would have changed the call.
```

If the input is thin, keep all four parts and mark the gaps as assumptions to confirm rather than
inventing specifics — "assumption: reversible within one sprint, to verify" is more useful than a
fabricated certainty or a dropped part.