Reference document · brief to outcome
The Initiative Lead Playbook
A minimum set of living artifacts for a 6–8 person product, design, and engineering team. Copy the prompts; keep the answers short; delete any artifact that no longer supports a decision.
The minimum sequence
These are not stage gates. Discovery, design, delivery, and learning overlap. The sequence says which missing fact should pull the team backward before it creates an expensive promise.
| Need to decide | Use | Ready when |
|---|---|---|
| Why act, and what counts? | Initiative frame | Outcome, guardrails, scope, unknowns, owners are arguable. |
| What might be false? | Assumption workshop | High-impact weak beliefs have tests and owners. |
| How does work really happen? | Workflow / EventStorming map | Rules, waits, actors, failures, meanings, and external systems are visible. |
| What is the smallest useful path? | Story map and examples | One vertical slice can produce evidence end to end. |
| What must the design be good at? | Architecture drivers | Five to seven scenarios have measures and checks. |
| Where are the boundaries? | Architecture packet + contracts | Scope, ownership, state, interactions, and critical failure are inspectable. |
| Which option do we choose? | Option table, spike, ADR | Forces, consequences, dissent, and revisit trigger are recorded. |
| How do we retire risk? | Walking skeleton + delivery map | Milestones produce evidence and dependencies have fallbacks. |
| How do eight people act as one? | Team charter | Decision rights, WIP, sources of truth, cadence, escalation are explicit. |
| How do we expose safely? | Rollout contract | Tests, telemetry, gates, reversal, and operational owner exist. |
| What changed and what next? | Weekly review + closeout | Evidence changes decisions and temporary machinery leaves. |
1. Initiative frame
- Why now
- Trigger, evidence, strategic context, and cost of doing nothing.
- Problem
- For [user/cohort] in [situation], [observed condition] causes [impact]. Baseline: [source and date].
- Outcome
- Move [measure] from [baseline] to [target] for [cohort] by [time].
- Guardrails
- Measures that must not degrade, each with threshold and owner.
- First boundary
- Included users/workflows; non-goals; what later expansion remains possible.
- Constraints
- Facts solution design must respect—not preferences disguised as facts.
- Assumptions
- Top value, usability, feasibility, and viability beliefs; evidence strength.
- Risks
- Impact × likelihood, early signal, mitigation, owner, review date.
- Decision rights
- Who decides outcome/scope, experience, architecture, and rollout.
- Next evidence
- What the team will learn before making the next expensive commitment.
Quality check: a reader can distinguish outcomes from outputs, constraints from assumptions, and commitments from options. Every number has a source. Every risk has an owner and signal. Every non-goal prevents a plausible misunderstanding.
2. Discovery and brainstorming workshop
Decision question: one sentence, visible throughout.
People: decider, user/domain knowledge, product, design, engineering, and people carrying operational consequences. Invite for knowledge, not representation.
Pre-read: frame, evidence, constraints, glossary. Mark facts, interpretations, and open questions separately.
Criteria: outcome impact, confidence, effort, reversibility, guardrails. Agree before seeing favored options.
| Time | Mode | Prompt |
|---|---|---|
| 10 min | frame | What decision must leave this room, and what is already known? |
| 10 min | silent diverge | Facts, assumptions, questions—one idea per note. |
| 15 min | share / cluster | Round-robin; clarify without defending; name themes. |
| 15 min | silent sketch | At least three mechanisms; include a manual or no-build option. |
| 15 min | converge | Compare against criteria; state strongest case against your preference. |
| 10 min | close | Direction, dissent, unknowns, tests, owners, decision date. |
Assumption map: place each belief by impact if false and evidence strength. Test high-impact, weak-evidence beliefs first. A vote surfaces sentiment; the named decider closes the choice after advice.
3. Workflow and domain map
- Domain events in past tense, left to right.
- Commands that caused events; actors who issued commands.
- Policies that react to an event and decide a command.
- External systems, manual tools, delays, time triggers, failures.
- Hotspots for unclear policy, competing language, waiting, or ownership.
For each hotspot record: example and counterexample, person who knows, unanswered question, and next evidence. Build a glossary with term, precise local meaning, context, and phrases to avoid. Candidate boundaries require evidence from language, invariants, change cadence, or ownership—not merely a noun.
4. Story map and executable examples
Backbone: user activities across the whole journey, left to right.
Depth: alternatives and rule variations beneath each activity.
Release line: one narrow row that completes the journey and tests a named assumption or outcome.
Manual seam: which uncertain automation can a person perform safely for the first cohort? Add capacity, owner, and removal trigger.
Rule: the behavior being clarified.
Happy: Given [specific state], when [action], then [observable result].
Boundary: exact edge or counterexample and expected reason.
Failure: dependency, retry, conflict, or partial outcome.
Guardrail: accessibility, security, privacy, performance, or operational case.
Telemetry: event or measure that shows the behavior and outcome.
5. Architecture-driver table
When [source] causes [stimulus] during [environment], [artifact] must [response], measured by [number].
Why it matters: outcome, guardrail, regulatory, or operational consequence.
Design pressure: which structural choices this scenario distinguishes.
Evidence: test, fitness function, drill, or production measure; owner and date.
Select only the few scenarios with high business impact, uncertainty, or structural reach. Cover the qualities that actually matter: availability, performance, security/privacy, modifiability, data integrity, interoperability, usability/accessibility, operability, cost, or others demanded by the context. Write conflicts between them.
6. Minimum architecture packet
| View | Must show | Review question |
|---|---|---|
| System context | people, system in scope, external systems, trust boundaries | What is ours and where does uncontrolled behavior enter? |
| Container | deployables, data stores, interactions, protocols, owners | Which driver justifies each operational boundary? |
| Dynamic | ordered interactions for one critical happy or failure path | Where can work, identity, or truth be lost or duplicated? |
| Module/dependency | model boundaries and allowed arrows inside deployables | Can likely change stay local and be enforced? |
Every view needs title, scope, audience, version/date, legend, labelled relationships, and the drivers or risks it addresses. Prefer a modular monolith for one small team unless a measurable driver pays for independent deployment. Supplement C4 with state, data-flow, or sequence views where static structure cannot answer the decision.
7. State and contract review
From → command → to: actor, precondition, invariant, authoritative owner, emitted fact, audit.
Race / retry: expected state on duplicate, stale command, timeout, or reordering.
Compensation: what reverses an external side effect that code rollback cannot undo?
Meaning: command, fact, or query; business promise made by success.
Identity: resource id, intent/idempotency key, ordering key.
Failures: rejected, conflicted, unavailable, timed out, partial; safe caller action for each.
Evolution: required fields, tolerant-reader rule, deprecation window, migration owner.
Data: classification, minimum fields, trust crossing, encryption, retention, deletion, access.
Proof: producer/consumer contract tests and operational signal.
8. Options, spikes, and ADRs
For each genuinely different option: mechanism; drivers it satisfies; drivers it harms; delivery/operational cost; reversibility; largest unknown; evidence already held. Include “do nothing,” manual, or buy when credible.
Decision: what choice is blocked?
Question: one falsifiable uncertainty.
Timebox: fixed hours/days and named investigator.
Method: smallest experiment; production-like where the question requires.
Result: number, trace, compatibility finding, or explicit inconclusive result.
Disposal: throw away, or separately review before productionizing.
Title / status / date / decider.
Context: facts and the decision required.
Forces: named drivers, constraints, risks, and affected owners.
Options: credible alternatives and why not chosen.
Decision: active voice; enough specificity to constrain implementation.
Consequences: benefits, accepted costs, follow-up work, operational ownership.
Dissent / advice: material concern and who carries it.
Revisit when: measurable change in context. Supersede; do not rewrite history.
9. Walking skeleton and delivery map
From [real source/build], move one [controlled user action] through [real deployment, boundaries, storage, representative adapter] and prove it with [telemetry/demo]. State every fake or hard-coded behavior.
Evidence milestone: behavior demonstrable; risk or assumption retired; exit check; target range; owner. Never report “percent complete.”
Dependency row: external owner; exact deliverable/decision; needed-by; current readiness evidence; fallback; escalation trigger and recipient.
Forecast: range and confidence; what changed; fixed variables; movable variable; smallest scope trade that preserves outcome; date of next evidence.
10. Team charter
Purpose: outcome and first cohort.
People: accountabilities, availability, missing expertise, consultation path.
Decision rights: final call for outcome/scope, experience, architecture, implementation, quality, rollout; advice required.
Flow: WIP limit, swarm rule, review/pairing expectations, blocked-item trigger.
Sources of truth: one location each for frame, scope, work, decisions, risk, evidence.
Cadence: purpose, inputs, output changed, and cancellation rule for each meeting.
Escalation: objective triggers, DRI, options format, recipient, response needed by.
Health: sustainable pace, focus protection, learning/redundancy, one team experiment.
11. Readiness and rollout contract
Risk-to-test map: risk/driver → example/unit, integration/contract, end-to-end, quality test, exploratory charter, or recovery drill → owner → evidence.
Telemetry map: outcome and guardrails by cohort; system health and saturation; business-state distribution and age; external dependency health; data quality/privacy; manual/support load. Every measure needs an owner and a decision it can change.
Cohort / percentage: who receives behavior?
Entry: required test, ownership, support, security/privacy, accessibility, and previous-stage evidence.
Observe: measures, segments, minimum volume/duration.
Advance: explicit thresholds and named decider.
Pause / reverse: trigger, authority, action, recovery time, communication.
Data / side effects: rollback, roll-forward, or compensation for in-flight work.
Operational ready: dashboards; actionable alerts; correlation; runbook; support brief; on-call/service owner; access; recovery; known failure states; capacity; disable path exercised; temporary flags have deletion owner/date.
12. Weekly review and closeout
Outcome / guardrails: baseline, current, target, cohort, confidence.
Learned: assumption and evidence; what decision changes.
Delivered: integrated, demonstrable behavior—not activity.
Flow: aging work, WIP, block, swarm.
Risk / dependency: changed signal, owner, action, escalation.
Decisions: made, waiting, dissent, next evidence/date.
Forecast: range, confidence, scope trade, next reforecast.
Ask: one explicit decision or resource, options and consequences.
- Outcome and guardrails reported against baseline, including non-benefiting segments and displaced cost.
- Steady-state service, on-call, vendor, data, support, and roadmap ownership accepted by name.
- Release flags, temporary paths, access, test data, pilot dashboards, and manual steps removed—or debt recorded with interest and trigger.
- Architecture views and contracts updated; decisions superseded rather than rewritten; fitness functions remain.
- Expected / observed / surprised / next-time learning review completed; at most two improvements owned and dated.
- Continue, change, stop, or hand over decided explicitly.
The traceability test
Trace one line through the packet: outcome → assumption → slice → driver → boundary/contract → decision → milestone → test/telemetry → rollout gate → continue/change/stop. A broken line is unnecessary work or unmanaged risk. The packet succeeds by coherence, not weight.
Primary sources behind the playbook
- User Story Mapping, Jeff Patton; Specification by Example, Gojko Adzic; Continuous Discovery Habits, Teresa Torres.
- Software Architecture in Practice, Bass, Clements & Kazman; C4 model, Simon Brown.
- Architecture Decision Record, Fowler; A Philosophy of Software Design, Ousterhout.
- Growing Object-Oriented Software, Guided by Tests, Freeman & Pryce; Accelerate, Forsgren, Humble & Kim.
- Team Topologies, Skelton & Pais; Canarying Releases, Google SRE Workbook.
- Taught across lessons 0039–0050.