Making Magnetic adoption actionable
Connecting product progress, shared blockers, and the decisions needed to move adoption forward.
- DPM & DesignOps
- Cisco - Feb 2025 to Sep 2026
The starting point
Across Cisco products, adopting Magnetic meant different things at different stages: a shared header and navigation, selected workflows, broader visual alignment, or deeper component adoption.
My work focused on making those differences visible and useful. Product conversations needed to connect progress with blockers, support needs, and a clear next step.
My contribution
I led
The preparation and facilitation of adoption follow-ups, synthesis of product updates, and coordination of next-action discussions.
I partnered
With product teams, design-system leadership, designers, and engineering contacts. Product teams owned implementation and release commitments; Magnetic partners helped address shared system needs.
I worked hands-on
On adoption summaries, tailored checkpoint questions, and a proposed refinement to workflow-based reporting.
The challenge
A percentage does not tell the whole story
Product updates used different libraries, scope definitions, and release targets. A nearly complete UI shell did not necessarily mean the main customer workflows had adopted Magnetic.
The coordination challenge was to understand what had actually changed, what was blocking further progress, and which decisions belonged with a product team or the design-system team.
The approach
Ask questions that lead to action
I shaped follow-ups around the current adoption phase, implementation evidence, component gaps, and the next milestone. The notes surfaced issues such as table capabilities, custom components, and unclear scope for high-priority pages.
01 · Progress
What changed, and what is released?
02 · Blocker
What prevents the next step?
03 · Decision
What support or choice is needed?
04 · Commitment
Who owns the next action?
Connect shared gaps
A component limitation may affect more than one product. Bringing that context into coordination helps distinguish an isolated request from a shared dependency worth discussing with Magnetic leadership.
The next iteration
Make the unit of progress clearer
I proposed preserving the existing adoption phases while tracking agreed priority workflows and distinguishing validated, reported, planned, and blocked work. A demo, production link, or release reference would support validation.
01 · Scope
Name the customer workflow and library.
02 · Evidence
Link the release or demonstration.
03 · Ownership
Record the blocker, owner, and next action.
Use meeting time for exceptions
The proposal moves routine updates toward asynchronous reporting and reserves checkpoints for blockers and decisions. It also allows relevant AI workflows to be reviewed for transparency, human control, feedback, and recovery within the same model.
What took shape
The work produced product-specific adoption follow-ups and a lean proposal for more comparable, evidence-backed reporting. It brought attention to differences in scope, library support, and release readiness.
The next step is to pilot the workflow-based model with a small product group and use the results to refine how we report progress.
How I would measure adoption
Proposed measures for the workflow-based adoption model. Agree eligible scope with each product; keep validated releases separate from estimates and targets.
Validated workflows
Released, demonstrated Magnetic workflows ÷ agreed priority workflows. Leadership sees adoption in terms of customer tasks.
Blocker age
Median days since a documented blocker was raised, grouped by library and owner. Shows where escalation or capacity is needed.
Products affected
Count of products with evidence of the same component or capability gap. Supports prioritization by shared impact.
Commitments met
Due adoption commitments completed with release evidence ÷ commitments due. Shows delivery confidence and scope changes.
What I carry forward
Make reporting useful to the next decision
The value of adoption tracking is in what it helps people do next. I would start the reporting refinement with a small product group, agree on the scope together, and test whether the evidence and follow-ups are useful before extending it.
