Discussion brief · Decision meeting · 05 Nov 2026
A calmer way to launch.
A launch decision for a fictional collaboration product. Three credible paths, one deliberate first step.
What are we deciding?
How should we introduce the new workspace without disrupting the teams already using our product?
CONSTRAINT 1
Keep current workflows available during the transition.
CONSTRAINT 2
Work within the existing four-person product team.
CONSTRAINT 3
Make the decision reversible after the first two weeks.
Who decides, and what is in scope?
Working group — approval pending
At the next decision review
Discussion draft. Recommendation is not approval.
In this decision
Select a reversible introduction path and the conditions for expanding it.
Outside this decision
Final launch date, unapproved staffing and commercial promises are outside this decision.
What do we actually know?
The brief describes existing workflows that must remain available.
Source / status: Supplied fictional scenario / design constraint
Limit: No direct customer interviews or measured outcome data are supplied.
The proposed work is assigned to an existing small team.
Source / status: Supplied fictional capacity assumption
Limit: Named owners and their availability still require explicit confirmation.
Rollback must be possible before widening access.
Source / status: Proposed release requirement, not test evidence
Limit: A recovery exercise has not yet been documented in this brief.
There is more than one way.
Choose the tradeoff.
Assessments are qualitative judgments, not measured scores.
| Criterion | A / One big release | B / A guided pilot | C / Optional early access |
|---|---|---|---|
| Learning quality | Broad but difficult to isolate | Focused and observable | Useful, but self-selected |
| Support burden | Concentrated at launch | Smaller, sustained effort | Unpredictable timing |
| Reversibility | High coordination cost | Simple pilot rollback | Individual opt-out |
| Team capacity | One large peak | Manageable weekly cadence | Longer parallel support |
Name what must be true.
A small group can reveal meaningful workflow friction.
How to check
Recruit varied invited teams and observe complete tasks rather than impressions.
Parallel support can fit the available capacity.
How to check
Confirm available coverage and review actual support work before expanding.
The prior experience can be restored safely.
How to check
Rehearse recovery on representative data before the pilot begins.
Make the work visible.
| Workstream | Capacity / availability | Dependency to resolve |
|---|---|---|
| Product & research | Planning estimate only; named availability not yet confirmed. | Participant consent and a suitable observation plan. |
| Engineering | Use the existing team; no additional hiring is assumed. | Verified migration subset and rehearsed rollback. |
| Support | Coverage remains pending until a willing owner accepts. | Issue triage, response windows and escalation handoff. |
Use supplied estimates and accepted owners. Missing capacity is a dependency, not permission to promise delivery.
Know when to change course.
Recovery does not work as expected.
Watch for
A rehearsal cannot restore a complete representative workflow.
Respond with
Pause invitations and resolve the recovery gap before proceeding.
The pilot overwhelms support.
Watch for
The agreed support capacity is exceeded or essential issues go unanswered.
Respond with
Stop expansion, reduce scope and review whether to continue.
The sample hides important needs.
Watch for
Participants represent only the most confident or enthusiastic teams.
Respond with
Broaden recruitment deliberately before claiming the experience is ready.
Our proposed direction.
B
A guided pilot
Start with a guided pilot so the team can observe complete workflows, correct friction, and make a better expansion decision.
Revisit this choice when
The pilot creates support work the team cannot sustain, or participants cannot finish the core workflow.
Earn the next step.
Prepare the conditions
Confirm scope, owners, consent and a recoverable first step.
Advance only when
Dependencies are verified and the pilot has an accepted support owner.
Observe a bounded pilot
Watch complete workflows and retain useful qualitative evidence.
Advance only when
The team reviews real observations and can explain unresolved friction.
Decide whether to expand
Consider the evidence and capacity, including reasons to stop.
Advance only when
An authorized decision records conditions, dissent and the next review.
Make the next move clear.
Invite five representative teams and confirm their consent.
Product leadBefore pilot begins
Write rollback steps and a support handoff.
Engineering leadBefore first invitation
Review observed issues and decide whether to expand.
Product + SupportTwo weeks after launch