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 (usewriting-specs-designs) - You’re setting long-term strategy/vision (use
defining-product-vision) or choosing among initiatives (useprioritizing-roadmap)
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):
- Release brief (what/why now/who/when; DRI; scope + non-goals)
- Rollout plan (phases, eligibility, flags, sequencing, kill switch, rollback)
- Quality plan (PQL) (tests/acceptance, “must be true”, known risks, sign-offs)
- Measurement + monitoring plan (success metrics, dashboards, alerts, owner)
- Comms + enablement plan (internal/external messaging, docs, support readiness)
- Launch day runbook (timeline, checkpoints, go/no-go criteria, escalation)
- Post-launch review plan (what we’ll learn, retro prompts, follow-ups)
- 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.
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: “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.