Aipom productive motion map
Skill deanpeters/ai-product-operating-model-skills/skills/aipom-productive-motion-map
Evidence-based skills for designing and improving AI product operating models
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.
3 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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.
- 3 stars3 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.
What its author says it does
Copied from the file, not written here
Map a recurring product-team motion through decisions, actors, inputs, handoffs, delays, rework, and failure before assigning AI and human responsibilities.
SKILL.md
4.3 KB, 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.
Gives 0 of the 12 instructions most css styling skills give
Counted across 586 of the 596 authors here whose files we hold, read 2026-08-06
- avoid excessive centered layoutsin 55 of 586, across 12 files
- bundle code into single HTML filein 54 of 586, across 14 files
- Respect prefers-reduced-motion user settingsin 52 of 586, across 35 files
- avoid purple gradientsin 51 of 586, across 11 files
- avoid uniform rounded cornersin 51 of 586, across 11 files
- avoid Inter fontin 51 of 586, across 11 files
- edit generated files to develop artifactin 50 of 586, across 10 files
- animate only transform and opacity propertiesin 43 of 586
- Make touch targets at least 44x44 pixelsin 41 of 586, across 15 files
- Ensure minimum color contrast of 4.5:1in 39 of 586, across 10 files
- use tailwind cssin 39 of 586, across 24 files
- Use SVG icons instead of emojisin 38 of 586, across 11 files
Said here and by no other author read
- Map a bounded recurring motion
- Define the trigger and desired outcome
- Reconstruct real cases not intended process
- Map steps decisions actors inputs and handoffs
- Mark waiting batching review and rework
- Identify missing recreated stale or contradictory context
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.