| name | aipom-operating-model-design-sprint |
| description | Design and test a bounded AI product operating-model change across decisions, workflows, context, evidence, governance, capability, ownership, and adoption. |
| type | workflow |
| category | cross-category |
| phase | 3 |
| status | active |
| operating_level | ["organization","portfolio","product-team"] |
| audience | ["CPO","CTO","Product Operations","Product Manager","Team Lead","Engineering","Data","Finance","AI Governance"] |
| best_for | ["Turning assessment findings into an operating design","Resolving cross-category dependencies","Testing a repeatable practice before scaling"] |
| evidence_required | ["Operating-model assessment and roadmap","Priority condition and affected decisions","Existing artifacts workflows owners and measures","Capacity constraints and change evidence"] |
| produces | ["Bounded operating-model design","Integrated prototype and test","Adoption decision and implementation handoff"] |
| assessment_questions | ["STR-01","STR-02","STR-03","STR-04","STR-05","POR-01","POR-02","POR-03","POR-04","POR-05","WFL-01","WFL-02","WFL-03","WFL-04","WFL-05","CTX-01","CTX-02","CTX-03","CTX-04","CTX-05","EVAL-01","EVAL-02","EVAL-03","EVAL-04","EVAL-05","GOV-01","GOV-02","GOV-03","GOV-04","GOV-05","CAP-01","CAP-02","[Truncated]"] |
| maturity_move | {"from":"repeatable","to":"operationalized"} |
| estimated_time | 3-10 working days |
| group_size | 5-12 core team plus participants |
| depends_on | ["aipom-operating-model-assessment","aipom-operating-model-roadmap"] |
| combine_with | ["aipom-decision-cycle-redesign","aipom-initiative-readiness-review","workflow-to-skill-converter"] |
| sources | [] |
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
- Frame: define the priority condition, decision, boundary, outcome, sponsor, constraints, and stop rules.
- Load evidence: assemble the context ledger and distinguish current practice from documented intent.
- Diagnose: map the decision or motion, root constraints, dependencies, affected perspectives, and critical safeguards.
- Choose design principles: state the few conditions the future operating model must satisfy.
- Compose: select only the AIPOM components needed across workflow, context, evaluation, governance, economics, and capability.
- Prototype: create an integrated, runnable operating slice with roles, evidence, controls, fallback, and feedback.
- Test: run representative cases with real participants and capture outcomes, burden, failures, disagreement, and adaptation.
