Every software rollout has a second budget line that rarely makes the plan: the cost of getting people to actually use the system once it ships. In this week’s episode of the Adoption Curve, Sean looks at two teams that planned for it on purpose instead of paying for it later.
What you'll learn
- The real reason a go-live date and a training-ready date shouldn't be the same date
- What actually makes a go/no-go gate affordable to hold, instead of just a nice idea
- The five-stage framework that keeps adoption going after the rollout's officially "done"
Meet our guest
Sean Adams is the Chief Revenue Officer at iorad, where he spends most of his time talking to L&D and enablement teams who are mid-rollout and trying to figure out why training isn't landing the way they expected. That vantage point — watching adoption succeed or stall across hundreds of customer environments — is what this episode draws on.
In this solo episode, he pulled two examples that hit the same problem from opposite ends: a go/no-go gate at Border States, and a five-stage reinforcement framework at Freshworks. Both are attempts to budget for adoption instead of hoping for it.
Every software rollout has two costs
Discovery gets a budget line. Workshops get a budget line. Dev sprints and testing get a budget line. But getting people to actually use the thing once it ships doesn’t always get one.
Adoption doesn't look like a cost until it's already being paid: a support queue that doesn't shrink, a workaround that becomes the new normal, a system nobody trusts because the first thing they saw didn't match what they were trained on.
Two real rollouts show what it looks like to plan for that second cost on purpose: one at the front end, one at the back end.
Key Insight #1: Don't start the clock before the system does
Sara Madsen, a senior instructional designer at Border States, builds a go/no-go date into every rollout she runs. That date defines when training is allowed to begin — and it only fires once the system itself is stable.
"When it's an emergency, you don't create engaging content, you create the bare minimum, and the experience suffers for the learner."
— Sara Madsen, Border States
Madsen has seen what happens when that gate gets skipped. Years ago, her team was handed a half-finished SAP rollout and told training launched in eight weeks, while the screens were still changing. "We did it," she says, "but it wasn't great." That's what built the gate in the first place. Even one button moving on a homepage is enough to make a learner stop trusting everything else they were taught.
A gate like that only survives contact with a real deadline if the team can afford to wait for it. Border States made that affordable by changing who builds the training: SMEs now capture the real workflow directly using iorad, and training that used to take 48 hours to build takes about 9. Same SME, same live system, radically less time between "I understand this workflow" and "there's a tutorial for it." That speed is the reason the team can hold the line on stability instead of gambling that the system won't shift again.
Key Insight #2: Adoption doesn't end at go-live
Freshworks approached the same problem from the other direction. In 2024 they took on a full CRM overhaul plus a dozen-plus other GTM tool rollouts, on an eight-month timeline instead of the usual eighteen, with one person, Nicki Nuñez, Manager of Learning Platforms & Digital Adoption, responsible for adoption across the whole stack.
"Course completion is not the same thing as capability."
— iorad case study, "How Freshworks Drives Behavior Change"
Her fix was a five-stage learner adoption framework: First Exposure, Orientation, Ramp & Practice, Competency, and Reinforcement, run for every tool in the stack and built on a Seismic page with iorad tutorials embedded throughout. The stage most rollouts skip is the last one. Freshworks runs it as a standing weekly cadence, because behavior decays if nobody reinforces it.
The proof shows up in small moments. One rep Slacked in with a routine question, got a tutorial link back like always, and replied: "I can't believe I didn't check to see if there was a tutorial before I bugged you." That's what it looks like when checking the library becomes the reflex instead of the exception.
Key Insight #3: What actually proves adoption is working
Both examples are protecting the same underlying thing: whether people can actually do the job. A completion report can't tell you that.
"IT professionals measure success by go-live dates, I swear. But when we care about the experience, we find success by knowing that they learned a skill and are applying the skill."
— Sara Madsen, Border States
A hundred completions is a number a system logs automatically. A skill being used, unprompted, three weeks after training, in the middle of a real workday, is something a team has to go looking for. If the only thing your rollout tracks is completion, you won't see the tax until it's already been paid.
The tactical starting point
If you're planning your next rollout:
- Set a go/no-go date now, before content creation starts, tied to system stability rather than the deadline.
- Shrink your own build time so the gate is affordable instead of theoretical.
- Decide your reinforcement cadence before you ever reach go-live, and name who owns it.
- Pick one behavior to measure in the live system instead of a completion count.
The build cost was always going to show up on the plan. Make sure the adoption cost does too.