Decision Governance & Criteria Template

Purpose

This template helps teams design clear decision gates and criteria for discovery and innovation work. Use it to make funding and prioritization choices faster, more defensible, and easier to scale across a portfolio while protecting small bets and early learning.

How to use this template

Copy this template for each decision gate you want to standardize (for example: Concept Validation, Prototype, Pilot, Scale). Fill the fields with organization‑specific thresholds, examples of acceptable evidence, and named role owners. Keep answers concise—this template is meant to be read in portfolio reviews and used as a practical checklist, not a spec document.

Gate overview

Decision Gate Name: [e.g., Prototype → Pilot]

Purpose: What decision are we enabling and why does it matter? (1–2 sentences)

Timing: When in the project lifecycle is this gate evaluated? (e.g., after 3 customer tests, before pilot funding, quarterly portfolio review)

Required evidence and metrics

List the minimum evidence and quantitative/qualitative metrics required to approve the gate. Distinguish between must-have evidence and helpful-but-optional context.

• Must-have evidence (examples):
  • Customer test summaries with verbatim feedback and sample size (N).
  • Prototype performance against defined success metric(s) (e.g., task completion rate ≥ 80%).
  • Estimated unit economics or clear hypothesis for path to acceptable economics.
  • Risk log identifying top technical, regulatory, or market risks and mitigation plans.
• Quantitative metrics (examples):
  • Customer engagement: activation, retention, or conversion rates with time windows.
  • Operational metrics: defect or downtime rates measured during pilot tests.
  • Financial signals: projected CAC, LTV, or break-even timeline (high-level).
• Qualitative evidence (examples):
  • Customer testimonials, competitive positioning analysis, and user journey improvements.

Roles and approval authorities

Define who plays each role in this gate. Use names, positions, or role types and a clear approval authority (e.g., single approver, panel, or threshold-based). Consider a lightweight RACI for clarity.

• Gate owner (facilitator): [Role or Person] — prepares materials and runs the review.
• Technical lead: [Role] — verifies technical readiness and risks.
• Product / Research lead: [Role] — verifies customer evidence and learning.
• Finance / Portfolio steward: [Role] — assesses financial implications and portfolio fit.
• Approver(s): [Role(s) and approval rule] — e.g., two of three: Product Director, Portfolio Committee Chair, CFO.

Approval rules and criteria

State explicit pass/fail rules where possible. Avoid vague phrasing like "sufficient evidence." Examples of explicit criteria:

• At least N=20 customer interviews with ≥60% expressing intent to use the solution.
• Prototype meets primary performance metric ≥80% across three independent tests.
• Top 3 technical risks have mitigation plans with owner and acceptable timeline.
• Expected incremental portfolio impact (revenue cost savings or strategic value) exceeds threshold X, or the team has a funded next-step experiment of ≤$Y.

Escalation paths and fast exceptions

When decisions cannot wait for a full committee, define a clear escalator and a documented fast‑track rule. Capture who can approve a time‑boxed pilot, under what conditions, and what documentation is required afterward.

Documentation and record-keeping

Record the decision, rationale, supporting evidence, dissenting opinions, and next actions. Suggested minimum record elements:

1. Decision outcome: Approve / Defer / Reject / Fund limited experiment.
2. Rationale and key evidence cited.
3. Assigned next steps, owners, and timelines.
4. Link to supporting artifacts (reports, slide decks, test data, customer quotes).

Sample go/no‑go criteria by stage (editable examples)

Prototype → Pilot

• Customer interest: 20+ engaged users or 10+ pilot partners with signed intent letters.
• Performance: prototype achieves primary KPI at or above target in at least two independent tests.
• Risks: No unresolved critical technical risk; plan in place for top 3 medium-level risks.
• Funding ask: pilot cap ≤ $X or pre-approved pilot budget exists.

Pilot → Scale

• Operational readiness: processes, support, and supply chain validated in pilot environment.
• Unit economics: pilot shows path toward target margins within Y months with stated assumptions.
• Compliance & safety: meets regulatory checks required for scale.
• Customer signals: retention and NPS exceed pre-defined thresholds.

Examples and common pitfalls

Keep the gate focused on the decision you need, and avoid turning reviews into status updates. Common mistakes to avoid:

• Using the gate to punish past delays instead of validating future risk and value.
• Requiring excessive documentation that delays learning—prefer representative evidence.
• Letting one strong advocate substitute for objective evidence.

Tailoring guidance

Adjust thresholds by project stage, strategic importance, or risk profile. For early-stage discovery, prefer lightweight evidence and time‑boxed funding for experiments. For regulated or capital‑intensive initiatives, require more robust evidence and formal sign‑off.

Suggested review cadence and ownership

Recommend a cadence (e.g., monthly portfolio review for early stage, quarterly for pilots) and nominate a portfolio steward responsible for keeping gate definitions up to date and ensuring consistency across projects.

Quick templates (copy-and-paste)

Use these short forms during reviews.

Next steps and optional enhancements

Consider turning this template into an interactive decision form that collects the required evidence fields and stores each decision record for portfolio analytics and retrospective learning.