Shipping Products

Scope

Covers

• Turning “we need to ship” into a concrete release plan with owners, dates, and a rollout strategy
• Building a Shipping & Launch Pack that makes the release decision-ready (Go/No-go)
• Shipping in small, frequent increments to improve both speed and stability
• Defining a reusable Product Quality List (PQL) and iterating it based on escapes
• Planning measurement, monitoring, rollback, and post-launch learning

When to use

• “We’re launching / releasing / deploying / going live—make a plan and ship.”
• “Create a go/no-go checklist and rollout plan for this release.”
• “We need to ship faster without breaking trust—set up small-batch shipping.”
• “Write release notes + comms + enablement for an upcoming launch.”

When NOT to use

• You don’t yet agree on the problem or target user (use problem-definition)
• You need to right-size scope to hit a date/appetite (use scoping-cutting)
• You need a decision-ready PRD (use writing-prds) or build-ready spec/design doc (use writing-specs-designs)
• You’re setting long-term strategy/vision (use defining-product-vision) or choosing among initiatives (use prioritizing-roadmap)
• You need a timeline/milestone plan with stakeholder cadence but are not yet launching (use managing-timelines)
• You need launch marketing copy, positioning, or campaign planning (use launch-marketing)
• You’re running a post-incident review after something went wrong (use post-mortems-retrospectives)

Inputs

Minimum required

• What you’re shipping (feature/change), target users, and where it will be available (platforms, regions, plans)
• Desired ship date/timebox + constraints (compliance, privacy, brand, uptime windows)
• Success metric(s) + guardrails (trust/safety, performance, reliability, support load)
• Rollout context (flags? staged rollout? beta? migration?) + key dependencies
• Stakeholders + DRI (who decides go/no-go) + who is on point during the launch

Missing-info strategy

• Ask up to 5 questions from references/INTAKE.md.
• If answers aren’t available, proceed with explicit assumptions and list Open questions that would change the ship decision.

Outputs (deliverables)

Produce a Shipping & Launch Pack in Markdown (in-chat; or as files if the user requests):

1. Release brief (what/why now/who/when; DRI; scope + non-goals)
2. Rollout plan (phases, eligibility, flags, sequencing, kill switch, rollback)
3. Quality plan (PQL) (tests/acceptance, “must be true”, known risks, sign-offs)
4. Measurement + monitoring plan (success metrics, dashboards, alerts, owner)
5. Comms + enablement plan (internal/external messaging, docs, support readiness)
6. Launch day runbook (timeline, checkpoints, go/no-go criteria, escalation)
7. Post-launch review plan (what we’ll learn, retro prompts, follow-ups)
8. Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md Expanded guidance: references/WORKFLOW.md

Workflow (8 steps)

1) Intake + define “what does shipped mean?”

• Inputs: User request; references/INTAKE.md.
• Actions: Clarify the change, target users, ship date, DRI, constraints, and what “live” means (where/for whom).
• Outputs: Release brief (draft).
• Checks: You can state the release in one sentence: “We will ship to by via .”

2) Choose the ship strategy (small batches by default)

• Inputs: Release brief; constraints; dependency map.
• Actions: Decide: internal → beta → GA (or phased rollout), flag strategy, and how to keep changes small. Identify the smallest safe increments.
• Outputs: Rollout plan (draft) + incremental release slices.
• Checks: Each increment has a clear user-visible outcome and a rollback path.

3) Run the “maximally accelerated” forcing function

• Inputs: Rollout plan (draft); slice list; blockers.
• Actions: Ask: “If we had to ship tomorrow, what would we do?” Use this to identify critical path vs non-essential work. Convert into a realistic plan.
• Outputs: Critical path list + cut/defer list + open questions.
• Checks: Every blocker is categorized: remove, work around, accept risk, or change scope.

4) Define the Product Quality List (PQL) + acceptance bar

• Inputs: Known risks; guardrails; product surface area.
• Actions: Create/extend a PQL (tests, UX states, security/privacy, reliability, performance). Explicitly list “must be true” to ship.
• Outputs: Quality plan (PQL) + go/no-go criteria (draft).
• Checks: PQL items are measurable/verifiable, not vibes; owners are assigned.

5) Measurement, monitoring, rollback

• Inputs: Success metrics/guardrails; rollout plan.
• Actions: Define dashboards/queries, alert thresholds, and on-call/escalation. Write the rollback and “stop-the-line” triggers.
• Outputs: Monitoring plan + rollback plan + launch runbook skeleton.
• Checks: If the metric moves the wrong way, you know who acts, how fast, and what they do.

6) Comms + enablement (internal first)

• Inputs: Release brief; target audiences; launch tier (minor/major).
• Actions: Draft internal announcement, release notes, help docs updates, sales/support enablement, and external messaging (if any).
• Outputs: Comms + enablement plan.
• Checks: Every audience has: what changed, why it matters, what to do next, where to get help.

7) Go/No-go + launch execution

• Inputs: Full pack draft; PQL; checklists.
• Actions: Run a go/no-go review, finalize the runbook timeline, confirm roles, and ensure dependencies are ready.
• Outputs: Final Shipping & Launch Pack (ready to execute).
• Checks: references/CHECKLISTS.md passes with no open “stop-ship” items.

8) Post-launch review + iterate the system

• Inputs: Launch outcomes; incident notes; feedback.
• Actions: Run a short retro, capture learnings, update the PQL based on escapes, and define next iteration(s).
• Outputs: Post-launch review notes + PQL updates + next steps.
• Checks: At least 1 process improvement is identified and owners/dates are assigned.

Anti-patterns (common failure modes)

1. Big-bang launch with no rollback. Shipping to 100% of users simultaneously with no kill switch or staged rollout. One regression impacts everyone and recovery is slow.
2. Go/no-go by gut feel. Running a launch review without a concrete checklist or PQL. “It feels ready” replaces measurable stop-ship criteria, and known risks are hand-waved.
3. Monitoring as an afterthought. Defining dashboards and alerts after launch day instead of before. The team discovers regressions from support tickets, not automated alerts.
4. Comms-last syndrome. Internal teams (Support, Sales, CS) learn about the launch from customers. Enablement materials are written retroactively, creating a trust gap.
5. Ship and forget. Declaring victory at launch without a post-launch review. Escapes, quality gaps, and process improvements go unrecorded and repeat next release.

Quality gate (required)

• Use references/CHECKLISTS.md and references/RUBRIC.md.
• Always include: Risks, Open questions, Next steps.

Examples

Example 1 (B2B SaaS release): “We’re launching role-based access control for admins next month. Create a Shipping & Launch Pack with a staged rollout, go/no-go criteria, and support enablement.” Expected: a phased rollout with clear eligibility, a PQL including permission edge cases, and a launch runbook + comms plan.

Example 2 (Consumer app iteration): “Ship ‘saved searches’ to 10% of users behind a flag next week; define monitoring and rollback triggers.” Expected: a small-batch rollout plan, dashboards/alerts tied to guardrails, and explicit stop-the-line thresholds.

Boundary example (scope cutting): “We need to cut scope so we can ship by the deadline.” Response: use scoping-cutting to right-size the slice first; then return here to plan the actual launch.

Boundary example (post-mortem): “The launch failed; let’s figure out what went wrong.” Response: use post-mortems-retrospectives to run a structured incident review; this skill covers pre-launch planning, not post-incident analysis.

Boundary example (roadmap): “Decide what we should build this quarter.” Response: use prioritizing-roadmap (and/or defining-product-vision) first; then apply this skill to the chosen initiative’s release.