Adoption is not
a launch. It is a
system.
Fluency designs the conditions that move a specific audience from its current behavior to sustained, fluent use, then turns what they ask for next into product decisions that close the loop back to them.
Nine phases. Three beats. One wheel that turns higher each pass.
The method is mine. Concept, model, build.
Track record, not results the method produced. The Autodesk chapter, FY22.
Most adoption work stops at "they can use it." Then the dashboard goes flat, the team ships another feature, and nothing changes, because capability was never the constraint. The system around the behavior was. Fluency designs that system: the cues, the sequence, the trust, the reinforcement that make a behavior occur, repeat, and survive after the training ends.
Nine phases.
One wheel.
The order is forced, not chosen. You cannot rank a signal you do not have, and you cannot compound trust you have not earned by closing.
-
Get Fluent · 01 to 03
01LiteracyCan they read it. First exposure, the vocabulary.02WorkingCan they use it with a hand held. Guided, not alone.03FluentDo they use it unprompted. Independent and sustained.
-
Assay · 04 to 08
04CaptureCatch what a fluent team asks for next.05WeighRank it by commercial truth, not by volume.06PresentCarry the ranked signal to product, legible.07DecideThe one manual call. Noise, or worth building. Mine.08CloseReport the outcome back to the customer who asked.
-
Compound · 09
09CompoundThe close becomes trust. Trust deepens adoption. The wheel turns again, one turn higher.
Adoption dies at two joints.
I own both.
A team has to be fluent before what it asks for is worth ranking. You cannot rank a signal you do not have, and most work never gets a team fluent enough to produce real signal.
A product decision only compounds when it returns to the customer who asked. You cannot build trust you have not earned by closing, and most work ships the decision and drops the loop.
Both are where adoption actually breaks. Both are exactly what I hold.
- What I own, first 90 days The adoption system, not a training. I map how the team uses it now against fluent use, and find where the wheel breaks, before I touch anything.
- The seam I fix first Whichever is bleeding. Most often the close, because a decision that never returns to the customer is where trust quietly drains.
- The metric I move Sustained, unprompted use. Fluent use that survives after the training ends.
The same behavior looks different from every seat. Fluency adapts to who is asked and what condition they are in. Same target, different reasons to get there.
The goal is not trust. It is calibration, reliance that matches how reliable the system actually is. Leaning in where it earns it. Staying skeptical where it has not.
"Customer support operations" undersells it. I do not hand a team fluency and walk away. I build the wheel that turns fluency into product decisions, and product decisions into deeper trust.
The method is mine. Concept, model, build.