Aipom productive motion map
Skill deanpeters/ai-product-operating-model-skills/skills/aipom-productive-motion-map
Map a recurring product-team motion through decisions, actors, inputs, handoffs, delays, rework, and failure before assigning AI and human responsibilities.From its SKILL.md
npx -y skills add deanpeters/ai-product-operating-model-skills --skill aipom-productive-motion-mapAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.3 KB, 675 tokens by cl100k_base, as published. Nobody here has run it
AIPOM Productive Motion Map
What Is It
Map how one recurring product-team outcome is actually produced: decisions, actors, inputs, tools, handoffs, waiting, rework, exceptions, and failures. The map establishes evidence before AI responsibilities are designed.
Why Use It
Automating a diagrammed ideal state often makes hidden work faster and less visible. Observing the real motion reveals where judgment, context, coordination, and recovery create or destroy value.
When to Use It
Use after choosing a workflow opportunity and before a human-AI work contract, playbook, or automation design. Map a bounded recurring motion, not an entire department.
What It Produces
- Trigger-to-outcome current-state map
- Decision, actor, input, handoff, wait, and rework record
- Failure and exception paths
- Baseline measures and priority redesign target
Who Should Participate
Include people who perform and receive the work, the accountable workflow owner, Team Lead, Product Manager, Product Operations where present, and technical or operational partners. Leadership descriptions cannot replace practitioner observation.
Evidence to Bring
Bring recent cases, timestamps, artifacts, decision logs, rework examples, exceptions, incidents, and participant observations. Note where the formal process differs from actual work.
How to Do It
- Define the trigger, desired outcome, boundary, owner, and unit of work.
- Reconstruct several real cases rather than the intended process.
- Map steps, decisions, actors, inputs, outputs, systems, and handoffs.
- Mark waiting, batching, searching, translation, review, rework, and abandonment.
- Identify context that is missing, recreated, stale, or contradictory.
- Trace exception, escalation, and failure recovery paths.
- Measure cycle time, touch time, review burden, rework, and outcome quality where possible.
- Identify the constraint or decision that most shapes the outcome.
- Choose a bounded redesign target and evidence needed before changing it.
Key Concepts
- A productive motion is a recurring path to an outcome, not a job title.
- Waiting and review are work even when absent from the process diagram.
- Exceptions reveal the true operating model.
- Baselines prevent faster output from masquerading as better work.
Organizational Applications
Use for discovery synthesis, roadmap decisions, support escalation, launch readiness, experiment review, research intake, and portfolio preparation.
Common Pitfalls
- Mapping the official process instead of observed work
- Starting with AI insertion points
- Ignoring exception and recovery paths
- Measuring only touch time
- Treating every friction as automation-worthy
- Redesigning the whole system before finding the constraint
Combine With
Use human-aipom-work-contract to assign responsibilities, aipom-workflow-playbook-builder to make the redesigned motion reusable, and aipom-decision-cycle-redesign for deeper cross-team change.
Assets and Templates
Sources
This skill is an original AIPOM synthesis of workflow observation, service-design, and decision-flow practices.
What ships with it: 3 files
1.4 KB alongside SKILL.md
examples/
- weak-example.md252 B
- worked-example.md593 B
- template.md604 B
Gives 0 of the 12 instructions most css styling skills give in 675 tokens
Counted across 512 of the 512 authors here whose files we hold, read 2026-09-06
- Animate only transform and opacityin 32 of 512, across 30 files
- Respect prefers-reduced-motionin 21 of 512
- Support reduced motion preferencesin 16 of 512, across 6 files
- Use Tailwind CSS for stylingin 14 of 512, across 13 files
- Specify AnimatePresence mode explicitlyin 12 of 512, across 2 files
- Set initial states explicitlyin 12 of 512, across 2 files
- Use semantic HTML elementsin 11 of 512, across 10 files
- Use oklch for color valuesin 11 of 512, across 10 files
- Honor prefers-reduced-motion in animationsin 10 of 512
- Provide a reduced-motion fallback for animationsin 10 of 512, across 9 files
- Use property names in camelCasein 9 of 512, across 4 files
- Ensure UI animations stay under 300msin 9 of 512, across 6 files
Said here and by no other author read
- Define trigger and outcome boundaries
- Reconstruct several real cases
- Map steps decisions and handoffs
- Mark waiting rework and abandonment
- Trace exception and failure paths
- Measure cycle and touch times
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.