AIWorkDex
Operations Practice

Make an evidence-backed launch decision

Reach an authorised go, delay, or reduced-scope decision with every critical dependency and recovery owner visible.

Preparation
One setup session, owner updates before the gate, and an authorised decision review.
Difficulty
Advanced
Task
Run a launch-readiness review
Back to the Task: Run a launch-readiness review

Before you start

Get what you need before you start

  • Identify the launch decision owner and every functional evidence owner.
  • Define blocking criteria, accepted-exception authority, observability checks, and rollback conditions.
  • Keep credentials and deployment secrets inside approved protected systems.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Build the launch record

    List each critical dependency across product, billing, access, data, legal, communications, support, monitoring, deployment, and rollback. Add its owner, evidence link, blocking state, and approval.

    Why it matters: A personal checklist can hide missing handoffs and evidence owned by another function.

    Input
    The launch scope, functional plans, release sequence, risk register, and authority map.
    Output
    One launch record with dependencies, owners, evidence, blockers, approvals, and recovery ownership.
    Tools in this stepGitHub ActionsGoogle Sheets

    Evidence for this step

    • A self-described first-time founder lists completed and unfinished launch dependencies and describes scrambling and second-guessing.

      Reddit: Root post, lines 17–52

  2. Verify evidence and exceptions

    Have each functional owner open their evidence and state go, no-go, or a documented exception. Send unresolved critical blockers to the launch decision owner.

    Why it matters: Operations coordinates the record while each function retains responsibility for its evidence and decision.

    Input
    The launch record, current evidence, blocking criteria, and exception authority.
    Output
    Owner-verified states, open blockers, and documented exception requests.
    Tools in this stepGoogle Sheets

    Evidence for this step

    • A self-described first-time founder lists completed and unfinished launch dependencies and describes scrambling and second-guessing.

      Reddit: Root post, lines 17–52

  3. Apply the deployment approval gate

    For the software deployment, confirm repository visibility and plan support. Configure the approved environment, reviewer, self-review setting, administrator bypass position, source restriction, and protection rules. Test the gate without exposing secrets.

    Why it matters: A protected deployment can hold software until review while leaving other launch dependencies in the cross-functional record.

    Input
    The release workflow, repository rules, authorised reviewers, deployment source, and secret policy.
    Output
    A tested software deployment gate linked to the broader launch record.
    Tools in this stepGitHub Actions

    Evidence for this step

  4. Record the launch decision

    The authorised owner chooses go, delay, or reduced scope. Record evidence, accepted exceptions, release sequence, observability checks, rollback trigger, rollback owner, and next review.

    Why it matters: A launch proceeds safely only when the decision and recovery authority remain explicit.

    Input
    Verified readiness states, blockers, exceptions, deployment gate, and recovery plan.
    Output
    An authorised launch decision with sequence, monitoring, rollback, owners, and review time.
    Tools in this stepGitHub ActionsGoogle Sheets

    Evidence for this step

Success checks

Check the result before you finish

  • Every critical dependency has an owner, evidence link, and blocking state.
  • Each function approves its own evidence and exceptions through the defined authority.
  • The software deployment gate holds secrets until its approved conditions pass.
  • The final decision names monitoring, rollback trigger, rollback owner, and next review.

Failure modes

Watch for these problems

  • The record says ready without evidence. Return the item to its functional owner.
  • A deployment approval is treated as whole-launch approval. Review every non-software dependency separately.
  • An exception lacks an authorised owner or expiry. Keep it blocking until both exist.
  • Rollback has a trigger but no owner or tested path. Delay or reduce scope until recovery is actionable.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.