← Back to the examples
Interactive · Launch systems

A capability is not a launch

A developer platform has finished a new API capability. Engineering has validated that it works. The launch date is approaching. Is it ready to launch?

This is a generic launch archetype. It uses no employer, customer, or product data.

Public exampleBuilt to show the method in use.

Scene-setting only. The discipline below is the same for each.

1 Frame the builder

A launch is for someone. Choose the build context and the build mode, and watch the audience architecture, the proof, the route, and the activation event change underneath you. AI-assisted is a build mode, not a persona: any of these builders may work either way.

Build context

Build mode

Audience architecture · a West of Obvious public example

Primary job
Current alternative
Evaluation criteria
Gatekeeper
Primary barrier
First meaningful value
Activation event

2 Choose the launch scope

Readiness is conditional on what kind of launch the team is attempting. A private preview can responsibly proceed while some systems stay immature. A broad launch carries a different obligation.

3 Resolve the six launch decisions

Each decision produces something the whole launch team works from. Resolve them in any order, or assess early and see what the current decisions can support. The same decisions carry a higher evidence and operational threshold as the scope expands: "resolved" here means resolved to the selected scope. Widening the scope flags each resolved decision for reconfirmation at the new threshold.

Builder: not framed Scope: not chosen Decisions resolved: 0 of 6
The button works at any readiness. That is realistic.

The launch decision

Working is not the same as launch-ready.

Technical validation makes a capability usable. Launch readiness makes it understandable, credible, supportable, discoverable, adoptable, and measurable for a defined audience and scope.

The exact ownership model varies by organization. Product and Engineering anchor capability truth; Docs and DevRel bring reference and field proof; Support, growth, lifecycle, partners, legal, and communications carry other parts of readiness. Product marketing connects those inputs into one coherent launch decision: who the launch is for, what can responsibly be promised, how the promise is proved, where it should travel, what scope the team can support, and how it will learn after release.

Original public model  ·  West of Obvious

Design and build notes

Strategic premise. Engineering complete and launch-ready are different states, and closing that distance is a core product marketing responsibility, in partnership with the teams that hold each input. The precise boundaries vary by organization. The point is not that every layer belongs to marketing; it is that the launch needs one coherent decision across audience, capability truth, proof, route, scope, support, and measurement. Assessing early is not a trap: real launches ship with known gaps, and the judgment being modeled is knowing what you are accepting, and at what scope.

Public example. This fictional launch situation contains no employer, customer, or product data. It shows a smaller public version of the method.

Why each scope asks for different decisions. A private preview can defer full positioning and use a direct route, but it still needs product truth, proof of first success, alignment, and an explicit learning plan. Limited and broad launches require all six decisions; the breadth of the audience raises the evidence, support, and scale required behind each one. That is why widening the scope reopens the question: every resolved decision asks to be reconfirmed at the new threshold before the launch reads as supportable.

Build. This page is one HTML file with no framework or libraries. It supports keyboard navigation, a screen-reader status line, and reduced-motion preferences.