What This Template Is For
Most product decisions do not need a meeting. They need a clear proposal, a defined set of evaluators, a deadline, and a protocol for what happens when not everyone agrees. Async decisions are faster than meetings for 80% of product calls because they give people time to think, remove scheduling overhead, and create a written record that survives memory.
The problem is that teams default to meetings because they do not have a structure for async decisions. Without structure, async decisions devolve into endless Slack threads, comment chains that lose context, and decisions that nobody realizes were made. This template provides the structure. It defines a proposal format, a review process, a decision deadline, and a commitment protocol.
Use this template alongside the Product Operations Handbook for broader operational process design. For decisions that require stakeholder alignment beyond your immediate team, the Stakeholder Management Handbook covers influence strategies. If your team is still building its operating rhythm, the operating cadence template helps you define when async decisions fit versus when synchronous discussion is needed.
How to Use This Template
- The decision proposer fills out the Decision Proposal section. This should take 15-30 minutes. Do not spend more time writing the proposal than the decision warrants.
- Share the completed proposal in your team's async decision channel (Slack, Teams, Notion, or wherever your team centralizes decisions).
- Tag all listed evaluators and set a clear review deadline. Three business days is the default for standard decisions. One business day for urgent ones.
- Evaluators add their input using the structured feedback format. They vote Approve, Approve with Conditions, Request Changes, or Abstain.
- When the deadline passes, the decision owner reviews all input and makes the final call. Document the outcome in the Decision Record section.
- Share the decision record with all stakeholders. Anyone who missed the review window has implicitly approved.
The Template
Decision Proposal
| Field | Details |
|---|---|
| Decision Title | [One-line summary, e.g., "Adopt Linear for sprint tracking"] |
| Decision Owner | [Name and role of the person who makes the final call] |
| Proposer | [Name of the person writing this proposal] |
| Date Proposed | [Date] |
| Review Deadline | [Date and time, include timezone] |
| Decision Type | [Reversible / Irreversible / Time-Sensitive] |
Context
[2-4 sentences explaining why this decision needs to be made now. What changed? What problem are we solving? What happens if we do not decide?]
Proposal
[State the proposed decision clearly in 1-2 sentences. Be specific enough that someone could act on this without further clarification.]
What we would do:
- [Action 1]
- [Action 2]
- [Action 3]
What we would not do:
- [Explicitly state what is out of scope to prevent scope creep]
Options Considered
| Option | Pros | Cons | Effort | Risk |
|---|---|---|---|---|
| Option A (Recommended) | [Pro 1, Pro 2] | [Con 1] | [Low/Med/High] | [Low/Med/High] |
| Option B | [Pro 1] | [Con 1, Con 2] | [Low/Med/High] | [Low/Med/High] |
| Option C: Do Nothing | [No effort, no risk] | [Problem persists, may worsen] | None | [Varies] |
Decision Criteria
[What factors matter most for this decision? List the 3-5 criteria by which options should be evaluated. Weight them if useful.]
- ☐ [Criterion 1]: [Why this matters, e.g., "User impact: how many users are affected?"]
- ☐ [Criterion 2]: [e.g., "Implementation effort: can we ship this within the current sprint?"]
- ☐ [Criterion 3]: [e.g., "Reversibility: can we undo this if it does not work?"]
- ☐ [Criterion 4]: [e.g., "Alignment with Q3 goals: does this move our key metrics?"]
Evidence and Data
[Include links to relevant data, customer feedback, competitive analysis, or prior decisions. The goal is to give reviewers enough context to evaluate the proposal without scheduling a meeting.]
- [Link to data source 1]
- [Link to customer feedback]
- [Link to related past decision]
Evaluators
| Name | Role | Input Required | Deadline |
|---|---|---|---|
| [Name] | [Role] | Required | [Date] |
| [Name] | [Role] | Required | [Date] |
| [Name] | [Role] | Optional | [Date] |
| [Name] | [Role] | FYI Only | N/A |
Evaluator Feedback Format
Each evaluator should respond with:
Vote: [Approve / Approve with Conditions / Request Changes / Abstain]
Rationale: [1-3 sentences explaining your position]
Conditions (if applicable): [What would need to change for you to approve?]
Questions: [Any questions for the proposer before you can finalize your vote]
Decision Record
| Field | Details |
|---|---|
| Decision Made | [Date] |
| Outcome | [Approved / Modified / Rejected] |
| Final Decision | [State the decision in 1-2 sentences] |
| Key Modifications | [What changed from the original proposal based on feedback] |
| Dissenting Views | [Summarize any significant disagreements and how they were resolved] |
| Next Steps | [Who does what by when] |
| Review Date | [When will we evaluate whether this decision was correct?] |
Async Decision Rules
These rules prevent the most common async decision failures. Adopt them as a team and reference them in your team charter.
The Silent Approval Rule
If an evaluator does not respond by the deadline, their vote counts as "Approve." This prevents a single non-respondent from blocking decisions indefinitely. Post a reminder 24 hours before the deadline. If someone needs more time, they must explicitly request an extension before the deadline passes.
The Escalation Rule
If required evaluators submit conflicting votes (some Approve, some Request Changes), the decision owner has two options:
- Modify and re-propose. Incorporate the requested changes and give evaluators 24 hours to review the modified proposal.
- Decide and document. Make the call, document the dissenting view, and explain why you are proceeding despite the objection.
Do not let conflicting votes result in no decision. Indecision is almost always worse than a wrong decision that can be reversed.
The Reversibility Rule
Classify every decision as Reversible or Irreversible before starting the review.
- Reversible decisions (can be undone within 2 weeks with minimal cost): Use a 1-2 day review window. Bias toward action. Two approvals are sufficient.
- Irreversible decisions (cannot be easily undone: pricing changes, architectural shifts, public commitments): Use a 3-5 day review window. Require input from all evaluators. The decision owner should schedule a sync meeting if there are significant concerns.
For a structured approach to evaluating product decisions, the RICE framework provides a scoring model that works well as a decision criterion.
Decision Types and Review Windows
| Decision Type | Review Window | Required Approvals | Examples |
|---|---|---|---|
| Trivial | Same day | Decision owner only | Copy changes, bug prioritization |
| Standard | 2-3 business days | 2+ evaluators | Feature scope, sprint priorities |
| Significant | 3-5 business days | All required evaluators | Architecture choices, vendor selection |
| Critical | 5+ days + sync meeting | All evaluators + leadership | Pricing model, platform migration |
Filled Example: Feature Scope Decision
Decision Proposal
| Field | Details |
|---|---|
| Decision Title | Remove social login from V1 launch scope |
| Decision Owner | Sarah Kim, Senior PM |
| Proposer | Sarah Kim |
| Date Proposed | March 5, 2026 |
| Review Deadline | March 7, 2026, 5:00 PM Pacific |
| Decision Type | Reversible |
Context
Our V1 launch date is March 28. Engineering estimates that social login (Google + GitHub OAuth) will take 8 additional engineering days. We have 15 engineering days remaining and 20 days of committed scope. Something needs to be cut. Social login has the highest effort-to-impact ratio of the remaining features.
Proposal
Remove Google and GitHub OAuth from V1 launch scope. Launch with email/password authentication only. Add social login in the V1.1 release (targeting April 15).
What we would do:
- Remove social login tickets from the V1 milestone in Linear
- Update the launch checklist to reflect email-only auth
- Add social login to the V1.1 milestone with April 15 target
- Update the signup page copy to remove "Sign in with Google" placeholder
What we would not do:
- Remove magic link authentication (already built, staying in V1)
- Change the account model or database schema (social login will plug into existing user model)
Options Considered
| Option | Pros | Cons | Effort | Risk |
|---|---|---|---|---|
| Remove social login (Recommended) | Protects launch date, minimal user impact for B2B | Some users prefer social login | None (removes work) | Low (can add post-launch) |
| Remove onboarding wizard | Saves 6 eng days | Significant activation impact | None (removes work) | High (activation is our key metric) |
| Extend launch to April 4 | Ship everything | 1 week delay, stakeholder commitments | 8 eng days | Medium (delays revenue) |
Decision Criteria
- ☑ Launch date impact: Does this protect the March 28 date?
- ☑ User impact: How many users will notice the missing feature?
- ☑ Reversibility: Can we add this back easily after launch?
- ☑ Metric impact: Does this affect our activation rate target?
Evaluators
| Name | Role | Input Required | Deadline |
|---|---|---|---|
| Alex Rivera | Engineering Lead | Required | March 7 |
| Jordan Lee | Designer | Required | March 7 |
| Lisa Park | VP Product | Optional | March 7 |
Decision Record
| Field | Details |
|---|---|
| Decision Made | March 7, 2026 |
| Outcome | Approved |
| Final Decision | Social login removed from V1 scope. Email/password + magic link auth for V1 launch on March 28. Social login (Google + GitHub) added to V1.1 milestone targeting April 15. |
| Key Modifications | Alex requested we keep the OAuth database columns in the schema migration to avoid a second migration later. Approved. |
| Dissenting Views | None. All evaluators approved. Lisa noted this is the right call for a B2B product where social login conversion lift is typically < 3%. |
| Next Steps | Sarah: move tickets in Linear by EOD March 7. Alex: keep OAuth columns in migration. Jordan: update signup mockups. |
| Review Date | April 15 (V1.1 planning) |
Common Mistakes to Avoid
- No deadline. An async decision without a deadline is a discussion, not a decision. Always set a specific date and time (with timezone) for review completion.
- Too many evaluators. Every additional evaluator adds latency and increases the chance of conflicting feedback. Limit required evaluators to 2-4 people. Everyone else is FYI.
- Skipping the "Do Nothing" option. Always include a "do nothing" option in your analysis. Sometimes the best decision is to not decide yet, and you need to articulate why that is or is not acceptable.
- No decision record. If you make a decision and do not document the outcome, you will re-litigate the same decision in 3 months when someone asks "why did we do it this way?" The decision record is the most valuable part of this template.
- Using async for contentious decisions. If you know the decision will be controversial, do not force it through async. Schedule a 30-minute sync meeting, use this template as the pre-read, and make the call in the room.
Key Takeaways
- Every async decision needs a proposal, a deadline, named evaluators, and a decision record
- Classify decisions by reversibility to set appropriate review windows and approval thresholds
- Silence after the deadline counts as approval. This prevents a single non-respondent from blocking progress
- Document the outcome and the reasoning. The decision record prevents re-litigation
- Reserve sync meetings for decisions that are contentious, complex, or emotionally charged
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use