Workshop materials

Allow 25 minutes for the slides, 20 for the exercise, and 30 for share-outs and discussion.

1. 1. Building the AI Flywheel

   Ask who has been asked to lead AI adoption. The workshop ends with three candidate experiments and a first project scoped with an owner, evidence, and a review date.

2. 2. Who are you right now?

   Invite people to choose the card that best describes their team. The two failure modes are teams that buy tools, try to change everything, and end up changing nothing; and teams that change everything without intentionality. Fear represents teams stuck in analysis paralysis and yet to start. Anger makes room for teams blocked from using the tools they need, Anxiety for teams overwhelmed by uncontrolled change, Disgust for teams dismissing AI, and Joy for teams using AI deliberately. Use the answers to start discussion rather than grade maturity.

3. 3. The case against huge AI transformations

   The argument concerns large initial scope and a distant first release. More data assumptions, handoffs, and changes to people's work need to succeed together. AI outputs can carry an error into later steps. A long build delays user feedback. A large initiative can still be delivered through small projects. We first prove a useful process and then decide what to connect or expand. The playbook's staged approach is at https://revi.systems/playbook#how-to-build-it.

4. 4. Build a flywheel of minimum viable transformations

   Define an MVT as the smallest useful change to a real business process that moves the needle and earns the right to deploy AI deeper into the organization. Impact must be measurable through a KPI or survey and aligned with an OKR or strategy. Choose projects that are impactful and goal-aligned, tightly scoped, and have verifiable success. Define the quality bar and role of human judgment. After validation, make the workflow permanent and scale where the evidence warrants it. Define the flywheel as a sequence of projects in which the results and retained learning from one improve how the team chooses, scopes, and runs the next. The strategic loop is about allocating effort across projects. It can lead to a revision of the first project, a different process serving the business goal, or an expansion justified by evidence. Small projects provide earlier feedback and make the next commitment easier to evaluate. Context, examples, standards, and evidence have to remain accessible to the people running future projects.

5. 5. One huge bet—or a series of compounding projects?

   Compare two ways to pursue the same business goal. A large initial transformation commits broadly before seeing much live evidence. A sequence of MVTs delivers usable changes, gathers feedback, makes validated workflows permanent, and carries context, infrastructure, and standards into the next project. This is a conceptual comparison, not a claim that all large programs fail. The distinction is how scope and investment are committed, and when the team learns.

6. 6. The ingredients of a great MVT

   Start with a business goal, current-state evidence, and available tools. Select one tightly scoped, impactful, goal-aligned process with a verifiable success condition. The CoS coordinates the process owner, users, and any builder needed; they do not implement everything alone. Agree on the test owner and review date. The two cards distinguish the ingredients from the transformation method. Map and diagnose select the process; design and build creates the change; running with users produces learning; making validated changes permanent supports improvement and scale. The method is adapted from the playbook Roadmap: map the process, diagnose gaps, design and build the change, operationalize with users, then make validated changes permanent. Business goal, scoped process, data and tools, assigned owner, and success criteria are the five ingredients. This delivery process produces useful evidence for the strategic flywheel. Record results, get feedback from users, and evaluate against the goal and baseline, including review and correction work. When the hypothesis is validated, invest in making the workflow permanent: accountable ownership, dependable integrations, documented standards, quality monitoring, and support. Expand where evidence warrants it. An MVT is not a permanent prototype; continue monitoring after adoption.

7. 7. An example from my work

   This anonymized example summarizes the deal-context, CRM-maintenance, and pipeline-review work as one bounded transformation, following Sawyer’s account. The business goal was more commercial capacity without more administrative work. Map email, calls, Slack, CRM records, and follow-up tasks; centralize deal context in the CRM; establish a routine for checking and refreshing it; use the context for a weekly agenda; then have sellers and commercial leaders check facts and decide next actions. Early context flows were manual dry runs, while CRM-updating automation was also being tested and refined. Missing context and inconsistent deal definitions informed changes to capture, update rules, and quality checks. This is a simplified narrative of overlapping work, not a claim that all integrations were deployed at the first meeting or that measured capacity gains were achieved.

8. 8. From one MVT to a flywheel

   This slide compresses overlapping June–August work into a learning narrative, not a strict implementation chronology. June 22 pipeline feedback exposed a false deal and a need for earlier agendas. June 25 notes describe already-running CRM automation, missing-context errors, and public error flags used to refine prompts and data. July 30 notes describe my reconstruction of actual deal histories into an ideal deal playbook and seller feedback requesting customer-verifiable stage-exit criteria. The July 9 leadership review stress-tested the pipeline dashboard; August 3 notes propose comparing seller close dates with playbook-model projections. The operationalization document describes shared pipeline definitions and feedback feeding people, process, and automation. These establish real work and iteration, not measured revenue or time savings. Keep the client anonymous. Additional project examples come from the vendor-setup and SOW/MSA SOPs (Claude drafts from confirmed answer banks and templates, with engineering/legal review), June 15 seller capacity and research pain points, and quote-to-cash planning and September 25 receivables/reconciliation work. Sawyer confirmed these as projects the team started. Do not imply all were fully automated or deployed in one sequence.

9. 9. WORKSHOP: Design three MVTs for your team

   Point participants to the workshop materials QR code, then explain the exercise before breakout: work individually or in small groups around one real business goal. A mixed-company group should choose one participant’s problem. Start by naming the goal and baseline on worksheet page 1. Map the first process and its inputs, outputs, decisions, and context gaps; use page 2 to specify MVT 1, ownership, quality, feedback, and first action. Then sketch MVTs 2 and 3 in the candidate map on page 1. They are hypotheses about what could follow, not a fixed roadmap. Partners challenge goal alignment, scope, and verifiable success. On reconvening, share the goal, first process/change, success criteria, and what could be reused in the next MVT. No per-step timings are prescribed.

10. 10. Stay in touch

    Leave both QR codes visible during discussion. One opens Sawyer's LinkedIn profile; the other opens the public workshop materials with the worksheet and deck downloads.