Launch orchestrator
A launch touches every team but usually lives in no one's tool, so it gets coordinated by hand, and coordination is what breaks. This builds one governed launch doc that holds the plan and activates every team from the same context. It does not just track the launch; it runs it.
Inputs
The roadmap item (name, target GA date, the goal), the teams involved, and the launch objectives and targets. Frame the launch with eigenquestion-planner first (what is the real problem this launch solves, and what does winning look like) so the plan aims at the outcome, not the checklist.
The build (uses the Launch Plan template)
- Hero: launch name, GA date, one-line goal, owner, status; a live progress bar off the task board.
- Objectives and success metrics.
- Workstream board: a Build Tasks table as a board grouped by phase, with a live progress readout.
- Phase timeline: milestones from build to GA to scale, near-term anchored to real dates, dependencies wired in the UI.
- Per-team activations: an Activation-by-team table (Sales, CS, Marketing, RevOps, Data, Leadership) with what fires for each and who stays in control.
- References: the brief, the assets, the trackers.
Build the substance via the MCP (superhuman-docs-builder), finish the columns, timeline dependencies, and publish in the UI, then ship-check. Keep humans in control; the doc drafts and routes, it does not auto-send.
Make it yours
Fork it. Set your phases, your teams, your targets, wire your roadmap trigger. The point is a launch that runs from one governed surface instead of a dozen disconnected tools. Built by an operator. Customize it, break it, make it better.
1---2name: launch-orchestrator3description: Launch orchestrator4---56# Launch orchestrator78A launch touches every team but usually lives in no one's tool, so it gets coordinated by hand, and coordination is what breaks. This builds one governed launch doc that holds the plan and activates every team from the same context. It does not just track the launch; it runs it.910## Inputs11The roadmap item (name, target GA date, the goal), the teams involved, and the launch objectives and targets. Frame the launch with eigenquestion-planner first (what is the real problem this launch solves, and what does winning look like) so the plan aims at the outcome, not the checklist.1213## The build (uses the Launch Plan template)14- **Hero:** launch name, GA date, one-line goal, owner, status; a live progress bar off the task board.15- **Objectives and success metrics.**16- **Workstream board:** a Build Tasks table as a board grouped by phase, with a live progress readout.17- **Phase timeline:** milestones from build to GA to scale, near-term anchored to real dates, dependencies wired in the UI.18- **Per-team activations:** an Activation-by-team table (Sales, CS, Marketing, RevOps, Data, Leadership) with what fires for each and who stays in control.19- **References:** the brief, the assets, the trackers.2021Build the substance via the MCP (superhuman-docs-builder), finish the columns, timeline dependencies, and publish in the UI, then ship-check. Keep humans in control; the doc drafts and routes, it does not auto-send.2223## Make it yours24Fork it. Set your phases, your teams, your targets, wire your roadmap trigger. The point is a launch that runs from one governed surface instead of a dozen disconnected tools. Built by an operator. Customize it, break it, make it better.
heath-gtm