Software rollouts follow a remarkably consistent arc.
The platform gets selected. A champion emerges, often the product manager, operations lead, or whoever drove the decision to buy. They’ve spent weeks or months in the product. They’ve been through every demo, read every release note, and explored features the average user will never touch. They are, by any reasonable measure, an expert.
Then comes time to train the team, and it follows the same script almost every time:
- A walkthrough of the interface, feature by feature
- An explanation of where everything lives
- A Q&A where questions go mostly unanswered because the situations employees are worried about are oddly specific and don’t show in the demo environment
Then everyone goes live. Immediately, something is unclear. Nobody seems to remember where the thing was in the walkthrough. The person who ran the training is already in a sprint for the next software rollout.
Adoption stalls. Workarounds spread like wildfire. People keep using the old system in parallel “just in case.” Six months in, leadership wonders why the investment was made at all. The platform vendor is confused and wondering what they did wrong. And the product champion who did their absolute best is quietly (or not-so-quietly) being blamed for a problem that was actually a training design problem all along.
The curse of expertise
There’s a well-documented phenomenon in learning science sometimes called the “curse of knowledge” – it’s the difficulty an expert has in remembering what it felt like to not know something. It’s not a character flaw; it’s a structural problem with how expertise works.
When you know a system inside and out, you forget which parts confused you at first. You skip steps that seem obvious. You explain features in terms of what they do rather than the problem they can solve for the person using them. You use the product’s vocabulary rather than the vocabulary of what it’s replacing. You spend significant time on cool functionality that power users will love but frontline users will never once use.
Read: none of this is the product manager’s fault. It’s the predictable outcome of asking someone to teach from expertise rather than from a learner’s perspective. The two are optimized for different things.
What end users actually need from software training
They need to learn the 10 percent of the software that covers about 90 percent of their actual work – not a comprehensive tour of the product. They need training framed around their existing workflows, not around the software’s architecture. They need to know what replaces what they were doing before, not just that a new thing exists.
They need practice with real scenarios before going live rather than a passive walkthrough they’ll try to remember under pressure two weeks later. They need quick-reference materials they can reach for mid-task when something doesn’t look the way they expected it to. And they need a clear path for what to do when something goes wrong, hopefully one that doesn’t involve scheduling a meeting with the implementation team.
Basically none of this is about the software itself. It’s about the transition. The learning challenge isn’t, “How does this product work?” It’s, “How do I do my job now that this part of it has changed?” These are two very different questions with two very different answers.
What a proper software roll out training program looks like
It starts long before launch with a workflow analysis. What are the specific tasks employees are performing today? Which of those are changing, which are staying the same, and which are being eliminated completely? That mapping tells you exactly what needs to be trained, which is almost always a smaller slice of the software than a full product tour covers.
The training itself needs to be role-based. The person processing invoices needs different training than the person pulling reports, and that person needs different training than the person managing access. A single session that covers everything for everyone covers everything for no one particularly well.
Job aids get built BEFORE go-live, not after when help tickets start coming in. A one-page quick difference card for the five things someone does every day is worth more than a 90-minute training they attended three weeks ago.
And there is a support plan for the first 30 days. Not “email us if you have questions,” but a structured plan for catching issues early, answering common questions in a centralized place (like a wiki), and adjusting training materials when a consistent point of confusion emerges.
The PM still matters, just differently
To be 100 percent clear: the product manager’s expertise is essential. They are the source of truth on what the software can do, what the edge cases are, and where the common mistakes happen. That knowledge needs to be in the training.
The shift we’re asking you to consider is how it gets there. Subject matter expertise (the PM’s deep product knowledge) feeds the content. Instructional design expertise shapes how that content gets delivered to a group of people who are learning under pressure, with varying technical comfort levels, while also trying to perform their job duties.
When both of those things are in the room, software rollouts go differently. Adoption is faster. Help tickets are fewer. The platform actually gets used the way it was intended.
If you have a software rollout coming up and the training plan is “whoever knows the product best will run a walkthrough” – we’d be glad to show you what the alternative looks like. Reach out and we’ll be in touch very soon!
