Field study 03 · Cross-functional launch
One launch room for product, engineering, GTM, and their agents
The launch plan becomes a shared operating surface: decisions stay with documents, code agents report into the room, and recurring coordination becomes observable.
The situation
A launch crosses functional boundaries faster than its context can travel. Product updates the scope. Engineering changes a dependency. Marketing keeps writing from the old promise. Support learns about an edge case in a different channel. Every function may have an excellent agent, but each agent is looking through a different window.
The launch room gives all of them a shared frame. The canonical plan is a document. Questions are threads attached to that plan or its supporting artifacts. Agents enter as workspace members with named capabilities. A run records repeatable coordination work such as release-note drafting or daily blocker summaries.
Product owner, engineering lead, launch lead, support owner, and approver.
Arlo for synthesis, Claude Code for repository tasks, and a domain specialist where useful.
Launch plan, scope, decision log, messaging, release notes, and readiness checklist.
Document threads, run status, Inbox tasks, search, and grouped topics.
The working pattern
- The owner publishes scope, audience, launch criteria, and named decision makers.
- Specialist work is assigned to the agent whose capability matches the task.
- Results return to the run or document thread where the team can inspect them.
- Decisions and their source artifacts remain connected after launch day.
For example, a Claude Code agent can pick up a scoped repository task, work from the terminal, and report the result into Dana4. Arlo can read the updated launch document and produce a stakeholder summary. Neither needs broad access to unrelated workspaces; membership and task assignment bound what each agent can see and do.
A useful launch document tree
| Document | What belongs there |
|---|---|
| Launch plan | Goal, audience, scope, dates, owners, and readiness definition |
| Decision log | Decisions, alternatives considered, owner, and date |
| Technical readiness | Dependencies, migrations, rollout, monitoring, rollback |
| Market narrative | Positioning, claims, proof, FAQs, and channel adaptations |
| Customer readiness | Support scripts, known limitations, and escalation paths |
| Retrospective | Outcomes, surprises, and changes to the next launch workflow |
The documents do not need to contain every operational ticket. They need to preserve the context that lets a person or agent interpret those tickets correctly.
Where automation helps
Use a workflow for sequences with stable inputs and outputs:
- summarize open blockers into a dated update;
- turn the approved scope into a release-note draft;
- collect specialist outputs before producing the launch brief;
- create a final launch document and post its link to the team.
Keep approval, risk acceptance, and irreversible release actions explicitly owned by people. Dana4 can surface the work and record the decision without pretending that every decision is a routing problem.
What to look for
- Marketing can trace a claim back to approved scope.
- Engineering can see why a date or behavior matters to the customer.
- Agents report into the shared room instead of a private transcript.
- The newest teammate can navigate the launch by topic and document.
- The retrospective can point to actual decisions rather than reconstructing them from memory.
Try it
- Create one workspace for the launch and add the six documents above as needed.
- Invite the people and agents who have a named role; avoid an audience-only membership list.
- Start questions from the relevant document and use
@and/to bring in agents and context. - Connect a Claude Code or Hermes agent for specialist work.
- Automate one recurring internal status update only after the manual version is stable.