A product decision record template with a worked example
A product decision record explains what you chose, which goal it serves, what evidence supports it and what would make you reconsider. Use the template and example to keep the reasoning available to the next reviewer or coding agent.
Name the goal and decision first
Write the choice as a question with a named owner: ‘Should new teams invite a colleague before or after first setup?’ Then state the desired user outcome and how you will measure it. Success for the record means a future teammate can reconstruct the alternatives and tradeoff. Success for the product still requires observing the result.
Copy the product decision record
This template adapts the compact context, decision, status and consequences structure of Michael Nygard's architecture decision records to product choices. The goal, evidence, options and reopening conditions below are our practical additions. Keep one consequential choice per record and link a replacement when a later decision replaces it.
Decision and owner
[Question, accountable owner, date and status: proposed, accepted or replaced.]
Goal and success criteria
[User outcome, measure, baseline, target, review date and guardrails.]
Context and evidence
[Link direct observations, their dates and the populations they describe. Name relevant prior decisions. Separate interpretation, assumptions and contradictory evidence.]
Credible options
[For each option, state how it could meet the goal, its drawback and the evidence that would favor it. Include keeping current behavior when it is viable.]
Decision and rationale
[What will change? Why does this option best fit the current evidence and constraints? What are you deliberately accepting or leaving out?]
Consequences and follow-up
[Affected requirements, owners, dependencies, user validation and measurement. Link the work and authoritative sources.]
Reopen when
[Specific contrary evidence, guardrail breach or changed constraint. Name the review date and owner. Preserve this record if a later decision replaces it.]
See the practice in context
Worked example — when to ask for a teammate invitation
All observations and targets in this example are fictional. Notice that both options have a defensible benefit and that the evidence points in different directions. The decision records that tension rather than turning a preference into a fact.
Fictional example. All observations and targets below are illustrative; replace them with evidence from your product.
Decision and owner
Should first-time administrators invite a teammate before or after configuring their workspace? Owner: onboarding PM. Status: proposed for review.
Goal and success criteria
Increase eligible new teams completing setup within seven days from 42% to 60% over six weeks. Guardrail: no decline in the share of new teams with two active members after fourteen days. Verify event definitions and baseline before launch.
Evidence and conflict
In five observed sessions, three administrators wanted to see a working workspace before inviting colleagues. Support notes also describe teams that stalled because a colleague needed to supply setup information. Observations support delaying the invitation for some teams; the support notes suggest collaboration helps others. Neither sample establishes how common each situation is.
Option A — keep invitation before configuration
Encourages early collaboration and preserves the familiar flow. It may interrupt administrators who are not ready to involve a colleague. Choose this if research shows shared setup is essential for the target segment.
Option B — offer invitation after configuration, with an earlier optional action
Lets an administrator establish value first while retaining a route to collaborate. It may reduce invitation discovery and requires a clear later prompt. Choose this if administrators can complete setup alone and still find the invitation at the appropriate moment.
Proposed decision
Test B with administrators from both situations before implementation. Keep the optional early action visible. Do not remove collaboration to simplify the screen. The PM and engineering owner must agree the revised journey before changing the spec.
Follow-up and reopening
Observe whether participants can complete their task and invite help when needed. Include observations that contradict B. If users needing collaboration cannot find the early action, revise the prototype before build. After release, review setup completion weekly and the fourteen-day collaboration guardrail. A sustained guardrail decline or new evidence of a required collaboration step reopens the decision; do not call an early fluctuation a proven effect.
Check the evidence behind the choice
Ask which goal governs the decision, who each source represents, when it was collected, which prior decision constrains the choice and what has changed. A repeated request may reveal a real need without proving the proposed solution. A generated summary is useful for locating evidence, but does not become a new observation.
- If research and analytics disagree, investigate population, definitions and timing before choosing the more convenient source.
- If a key belief is untested, state the smallest research activity that could change the decision and its owner.
- When evidence is insufficient, record a research decision with a review date rather than an unsupported build commitment.
Make and preserve decisions in Prodeology
Bring relevant sources and prior decisions into Product Intelligence. Use the feature and outcome context to frame the question. Run User Interview for research planning and synthesis, or Assumption Mapping to expose uncertain beliefs, then resolve the consequential choice through the appropriate review step.
- Keep the owner, answer and rationale in Decisions so the choice remains connected to the work it affects.
- Update the affected feature and requirements after the decision. Check that the spec carries the agreed behavior into implementation.
- Revisit the decision when the stated evidence changes. Current Prodeology workflows can support the review; your team still needs to collect and assess post-release outcome measurements.
Review without reopening every old debate
Reopen a decision because its assumptions, constraints or outcome evidence changed. Before that threshold, preserve the accepted direction and collect the missing evidence. When a new decision replaces the old one, link them and retain the earlier reasoning so future teams understand why the product evolved.
A record supports judgment; the owner makes the call
A template makes tradeoffs inspectable. It cannot establish that evidence is representative or choose the right outcome for the business. The people responsible still make and own the consequential call.
Make product decisions with evidence in Prodeology
Connect goals, research and prior decisions, examine the alternatives and carry the agreed answer into your plan and spec.
Sign up for early access now