Example
How to coordinate a software release without hiding blockers in chat
Martin’s team has passing tests and a migration described as should be fine. He needs a Room that compares shipping with the flag off, delaying for a rollback note, and cutting the migration while the rest ships.
Ship Thursday only if rollback, support wording, and the flag plan are visible—or hold on purpose
Date, the no-invisible-blockers rule, and the ship / delay / cut decision
Keep the date beside rollback and support as first-class work
Compare flag-off, Friday delay, and cut-migration options
Flag, tests, and rollback notes
Name the missing artifact instead of “should be fine”
Show what actually is ready so it does not paper over what is not
Keep completed tests visible without letting them substitute for rollback
Owners for support, QA, and migration
Name who will review customer wording
Name who owns the release checks
Name the owner Martin still has to ask for the rollback note; keep this in People until Martin actually sends a request
Changelog and customer wording
Keep Martin’s owned customer-wording draft on the same Board as the flag
Keep the unfinished public explanation beside customer wording
The Thursday release Board keeps checks, accountable people, customer communication, and the actual release rule visible.
The ship, delay, or cut-migration Card becomes a Room for the feature flag, missing rollback, support draft, and owner commitments.
Ava can organize the visible release evidence. Martin owns production judgment and every team or customer message; Ava deploys, changes flags, and sends nothing.
Ready in chat is not ready if rollback and support are blank
This Board has one job: Ship Thursday only if rollback, support wording, and the flag plan are visible—or hold on purpose.
The decision still belongs to Martin: Whether to ship with the flag off for the migration, delay to Friday for a rollback note, or cut the migration and ship the rest.
You.one can keep the work, several kinds of evidence, and “Choose ship, delay, or cut migration” decision visible through its Superboard view. The organized facts support Martin; they do not replace Martin's judgment: Martin chooses ship or hold, talks to owners, and owns production judgment.
Available today
Thursday release: one place for the mission
The Thursday release Board gives this mission one durable operating picture. Martin can use familiar language instead of translating the situation into project-management jargon. Its four Lists separate the kinds of attention this situation actually requires.
The Board is not a master task list. It keeps the live choice, the facts that could change it, and any reply or outside event already in motion visible without pretending every uncertainty is work in progress.
Swipe or scroll sideways to see every column.
| List | What belongs here |
|---|---|
| Mission | Date, the no-invisible-blockers rule, and the ship / delay / cut decision |
| Checks | Flag, tests, and rollback notes |
| People and replies | Owners for support, QA, and migration |
| Comms | Changelog and customer wording |
Available today
Cards that sound like the real work
These Card titles come directly from Martin's situation: “Choose ship, delay, or cut migration” is the live choice, while “Migration with no rollback note” and “Feature flag ready” hold different facts that can change it. The point is recognition, not a perfect taxonomy.
Swipe or scroll sideways to see every column.
| Card | List | Job |
|---|---|---|
| Thursday only if blockers are named | Mission | Keep the date beside rollback and support as first-class work |
| Choose ship, delay, or cut migration | Mission | Compare flag-off, Friday delay, and cut-migration options |
| Migration with no rollback note | Checks | Name the missing artifact instead of “should be fine” |
| Draft customer wording for support | Comms | Keep Martin’s owned customer-wording draft on the same Board as the flag |
| Feature flag ready | Checks | Show what actually is ready so it does not paper over what is not |
| Release test suite passed | Checks | Keep completed tests visible without letting them substitute for rollback |
| Changelog is still a pull-request title | Comms | Keep the unfinished public explanation beside customer wording |
| Support owner: Amina | People and replies | Name who will review customer wording |
| QA owner: Lee | People and replies | Name who owns the release checks |
| Migration and rollback owner: Devon | People and replies | Name the owner Martin still has to ask for the rollback note; keep this in People until Martin actually sends a request |
Available today
Keep the evidence with “Choose ship, delay, or cut migration”
Opening the Card gives the visible item durable depth. Stage can hold Go/no-go brief: Place flag, missing rollback, support wording, and ship / delay / cut options on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Martin will choose flag-off Thursday, a Friday delay for rollback, or cutting the migration and shipping the rest.”
A Card Chat request can ask Ava to prepare the specific comparison or extraction in “Choose ship, delay, or cut migration” from the visible evidence. Ava can work from the context Martin deliberately brings into this Card, List, or Board; she cannot monitor the rest of life, contact anyone, or inherit the decision.
Martin's call remains explicit: Martin chooses ship or hold, talks to owners, and owns production judgment.
Swipe or scroll sideways to see every column.
| Surface | Job in this example |
|---|---|
| Stage | Go/no-go brief: Place flag, missing rollback, support wording, and ship / delay / cut options on one page |
| Chat | Keep Martin's request and Ava's attributed response with the work |
| Pulse | Open decision: Martin will choose flag-off Thursday, a Friday delay for rollback, or cutting the migration and shipping the rest |
Start small and rename what feels artificial
Martin should rename every List or Card that feels artificial. This recipe succeeds when “Choose ship, delay, or cut migration” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.
Swipe or scroll sideways to see every column.
| Step | Action |
|---|---|
| 1. Write the ship rule | Rollback and support are checks, not vibes |
| 2. Card each check | Flag, tests, rollback note |
| 3. Name owners | People for support and migration |
| 4. Draft customer wording | Blank is a blocker |
| 5. Decide in a Room | Open “Choose ship, delay, or cut migration” and record flag-off Thursday, Friday delay, or cut migration |
A ticket board plus a Slack thread can remain part of the system
A ticket board plus a Slack thread can be enough while the situation stays simple: rollback and support wording already exist.
It starts to break when a “should be fine” migration and a blank customer sentence both claim Thursday.
The Thursday release Board earns its place only when the familiar tool—a ticket board plus a Slack thread—can no longer keep the reason, Go/no-go brief, conversation, current state, decision, and history connected.
Where this example stops
- This is a fictional example, not a customer story.
- This is not a reliability, uptime, or security claim.
- It does not show Ava deploying software or messaging customers.
- It is not a measured release result.