# Aipom Operating Model Design Sprint > Design and test a bounded AI product operating-model change across decisions, workflows, context, evidence, governance, capability, ownership, and adoption. - Skill: `deanpeters/aipom-operating-model-design-sprint` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add deanpeters/aipom-operating-model-design-sprint` - Raw SKILL.md: https://api.skillmd.com/api/skills/deanpeters/aipom-operating-model-design-sprint/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Dean Peters (https://skillmd.com/u/deanpeters) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/deanpeters/aipom-operating-model-design-sprint --- # AIPOM Operating Model Design Sprint ## What Is It Design, prototype, and test a bounded operating-model change around a consequential decision or productive motion. Integrate the smallest necessary strategy, portfolio, workflow, context, evaluation, governance, and capability practices rather than redesigning the whole organization. ## Why Use It Assessments and roadmaps identify conditions but do not prove a new way of operating. A sprint converts a priority into observable work, tests dependencies and adoption, and creates evidence for revise, establish, or stop decisions. ## When to Use It Use after an evidence-based assessment and roadmap identify a bounded, cross-category condition with an accountable sponsor and available participants. Do not use a sprint to bypass urgent safeguards or pretend enterprise transformation happens in a week. ## What It Produces - Sprint charter, context ledger, and system boundary - Current-state diagnosis and target operating conditions - Integrated operating prototype across required categories - Representative test, measures, failures, and participant evidence - Adopt, revise, contain, stop, or scale-later decision - Owned 30/90-day implementation and learning handoff ## Who Should Participate Include the accountable sponsor, Product Operations, practitioners who perform the work, product and technology partners, data or knowledge owners, governance partners, and affected users where relevant. ## Evidence to Bring Bring assessment findings, roadmap, current decisions and workflows, baselines, artifacts, owners, dependencies, incidents, adoption evidence, constraints, and available skill outputs. Preserve missing and conflicting evidence. ## How to Do It 1. **Frame:** define the priority condition, decision, boundary, outcome, sponsor, constraints, and stop rules. 2. **Load evidence:** assemble the context ledger and distinguish current practice from documented intent. 3. **Diagnose:** map the decision or motion, root constraints, dependencies, affected perspectives, and critical safeguards. 4. **Choose design principles:** state the few conditions the future operating model must satisfy. 5. **Compose:** select only the AIPOM components needed across workflow, context, evaluation, governance, economics, and capability. 6. **Prototype:** create an integrated, runnable operating slice with roles, evidence, controls, fallback, and feedback. 7. **Test:** run representative cases with real participants and capture outcomes, burden, failures, disagreement, and adaptation. 8. **Decide:** adopt, revise, contain, stop, or scale later based on evidence. 9. **Handoff:** assign owners, 30/90-day motions, measures, review cadence, unresolved questions, and reuse path. ## Facilitation Protocol Support guided, context-dump, and best-guess modes for preparation, but do not fabricate participant commitment or test evidence. Ask one consequential question at a time in guided mode. Reuse assessment and roadmap context. Preserve a sprint ledger across sessions and record decisions, changes, failures, and ownership. ## Decision Logic 1. **Contain first** when a critical gap exposes current work. 2. **Repair a root condition** when several symptoms share missing authority, context, evidence, or ownership. 3. **Prototype a bounded operating slice** when dependencies can be tested with real participants. 4. **Revise** when value is plausible but burden, failure, or adoption evidence rejects part of the design. 5. **Establish** when representative use is repeatable with owners and controls. 6. **Stop** when the design lacks value, capacity, authority, or acceptable consequence. Do not spread the sprint evenly across seven categories; include only what the target decision requires. Do not call the design operationalized until evidence shows standardized use beyond the sprint. ## Completion Criteria Finish with a bounded problem, evidence and assumptions, integrated prototype, representative test, results and failures, preserved disagreement, accountable decision, 30/90-day owners, measures, unresolved questions, and scale or retirement conditions. ## Key Concepts - The unit of design is a decision or productive motion. - Integration matters more than artifact count. - A prototype tests an operating relationship, not just a template. - Sprint completion is not maturity; adoption evidence follows. ## Organizational Applications Use to establish portfolio gates, redesign an AI-assisted decision cycle, operationalize context and evaluation, repair post-incident governance, or test a capability-and-reuse system. ## Common Pitfalls - Attempting an enterprise redesign in one sprint - Inviting leaders without practitioners - Producing canvases without running the work - Ignoring safeguards to preserve momentum - Declaring success from participant enthusiasm - Handing off tasks without decision ownership or review ## Combine With Use `aipom-decision-cycle-redesign` for workflow depth, `aipom-initiative-readiness-review` for a material initiative decision, and `workflow-to-skill-converter` to preserve a proven operating motion. ## Assets and Templates - [Design sprint template](template.md) - [Synthetic worked example](examples/worked-example.md) - [Weak example](examples/weak-example.md) ## Sources This workflow is an original AIPOM synthesis of operating-model design, evidence-based product discovery, workflow prototyping, and organizational change practice.