When a new system or upgrade struggles to gain traction, one of the first things people say is, “We need more training.”
Sometimes they are right. A team may need a clearer introduction to the system. A new hire may need guided practice. A manager may need better tools to coach the work. A global rollout may need structured learning so people understand what is changing, why it matters, and how to use the system correctly.
But in many organizations, the request for training is also a signal. It often means users are confused, support teams are hearing the same questions, managers are filling in gaps, or people are creating workarounds because the intended process is not clear enough.
In those cases, training may be part of the answer, but it is rarely the whole answer. The better question is not simply, “What training do we need?” The better question is, “Where is adoption breaking down?”
This question changes the work. It moves the discussion beyond courses and classes. It brings workflow, product design, documentation, support readiness, manager communication, system usability, and knowledge access into the same conversation. It also recognizes a reality many global organizations know well: people cannot adopt what they do not understand, cannot find, cannot trust, or cannot fit into the way they actually work.
Software adoption is not only a learning problem. It is an organizational problem.
The Training Request Is Often a Symptom
Training requests usually come from a real place. Someone is seeing a problem. Users may be entering data incorrectly. A new workflow may not be followed. Support tickets may have increased after a release. Managers may be frustrated because teams are not using a tool as intended.
It is understandable to respond by creating more content. A course feels concrete. A job aid feels useful. A video feels fast. A webinar can be scheduled. Those are all valid tools, and in many cases they are needed.
The risk comes when training becomes the default response before anyone has diagnosed the problem.
If users do not understand a process, training can help. If the screen labels are confusing, training may only compensate for poor design. If a required field appears too late in the workflow, a job aid may reduce errors, but the product may still be creating unnecessary friction. If users cannot find the answer when they need it, another course may not solve the problem. If managers are not reinforcing the new behavior, even well-designed training may fade quickly after rollout.
A training request should be treated as the beginning of an investigation, not the end of one.
Where Global Organizations Feel the Pressure
Global organizations make adoption problems easier to see because scale exposes weakness. A new workflow may be understood in one market and misunderstood in another. A training example may work for one business unit but feel irrelevant somewhere else. A system term may make sense to a product team but not to a front-line employee using English as a second language. A release note may be technically accurate but not practical enough for managers who need to explain the change to their teams.
The larger the organization, the more variation exists in roles, experience levels, languages, support models, regulatory environments, and operating practices. Standardization is still possible, but clarity matters more.
Hospitality and airline environments are good examples because they operate across countries, time zones, brands, service models, and local practices. They also depend on large numbers of employees using complex systems correctly during real-time operations. A hotel front desk associate, revenue manager, call center employee, implementation specialist, engineer, and support analyst may all interact with the same system, but each person needs a different level of detail.
The same is true far beyond travel. Healthcare, financial services, manufacturing, logistics, retail, and technology companies all face a similar challenge. When software sits at the center of the work, adoption depends on more than introducing features. People need to understand what the system does, how it supports their role, where to find reliable answers, and what to do when the standard path does not fit the situation in front of them.
Knowledge Exists Before Someone Builds a Course
Most organizations already have the knowledge they need. The challenge is finding it and bringing it together. Pieces of it live across the organization. Product managers understand the business intent behind a feature. Engineers and developers know how it works. Support analysts see where users struggle. Implementation teams understand the realities of deployment. Experienced employees often know the practical shortcuts and exceptions that never made it into the documentation. Additional pieces are scattered through release notes, support tickets, meeting notes, presentations, emails, recordings, and countless informal discussions.
By the time a learning team is asked to create training, much of the knowledge already exists. It simply has not been organized in a way people can easily use.
This is where instructional design and knowledge management become essential. Before designing a course, it helps to ask a few simple questions. What does the user need before doing the task? What will they need while doing it? What happens when something goes wrong? Who owns the information after launch?
A front-line employee may need a short procedure, a video demonstration, a job aid, or an accurate training database where realistic scenarios can be practiced without affecting production data. A support analyst may need troubleshooting logic and known issues. A trainer may need context, practice activities, facilitation notes, and a training environment aligned with actual system use. An engineer may need technical detail, system architecture, dependencies, expected behavior, or a reliable test harness for validating changes before they reach production. A developer may need implementation details, integration points, and expected system behavior. A product manager may need field feedback translated into patterns, requirements, and priorities.
Throughout my career, I have created learning and knowledge resources for audiences ranging from front-line employees and managers to trainers, support analysts, engineers, developers, and product teams. The audience changed. The underlying challenge remained the same: presenting the right information, at the right level of detail, when people needed it.
The same feature may require several kinds of knowledge, written at several levels of depth. This is why knowledge management cannot be treated as an archive. It is part of adoption. If users cannot find the right answer, if content is outdated, if ownership is unclear, or if search results return five conflicting documents, the organization has not solved the knowledge problem. It has only stored information.
Learning Should Fit the Work
Once the knowledge is understood, the next question is how people should receive it. Not every need belongs in an LMS. Not every answer belongs in a PDF. Not every change needs a webinar. Not every process requires a full course.
Sometimes instructor-led training is the right choice, especially when people need discussion, practice, coaching, or shared understanding. Sometimes virtual instructor-led training works well because teams are distributed across regions. Sometimes eLearning is useful for consistency, scale, and tracking. Sometimes a short video is better than a course because the user only needs to see a task performed. Sometimes a job aid, searchable knowledge article, embedded prompt, checklist, or manager talking point will do more good than another module.
Delivery strategy matters. An LMS can be valuable for structured learning, compliance, assignments, reporting, and role-based paths. A knowledge system can support search, reuse, content governance, and point-of-need access. A video platform can help users see a task as it happens. Embedded guidance can reduce confusion inside the workflow. Peer learning and manager coaching can help people apply the process in the real world. An accurate training database also matters because it gives users, trainers, and support teams a safe place to practice realistic scenarios before the stakes are real.
Effective learning rarely depends on a single platform. It depends on how learning, knowledge, performance support, and communication work together throughout the employee experience.
The platform should support the work. It should not define the work. Too often, organizations begin with the tool. They ask what should go into the LMS, what should be posted to the portal, or what can be turned into a video. Those are useful questions, but they come too early. The better starting point is the user’s situation.
What are they trying to do? When do they need help? How much time do they have? How often will the task occur? What happens if they make a mistake? Is the issue conceptual, procedural, technical, or behavioral? Does the answer need to be remembered, practiced, referenced, or discovered at the moment of need?
Those questions lead to better learning decisions because they are grounded in the work itself.
Product Teams and Learning Teams Need Each Other
One of the most useful shifts an organization can make is connecting product, training, knowledge, support, and field teams earlier in the process.
Each group sees a different part of adoption. Product teams understand intended behavior, system logic, constraints, and upcoming changes. Support teams see repeated user questions, defects, confusion, and workarounds. Field teams understand the operating reality. Learning teams understand how people absorb, practice, and retain information. Knowledge teams understand how answers should be organized, maintained, and surfaced.
When those groups work separately, the organization misses patterns. A training team may produce a course for a workflow users will continue to find confusing. A support team may answer the same question for months without anyone changing the documentation. A product team may release a helpful enhancement without giving managers the context needed to explain it. A knowledge base may contain the right information, but use language users do not search for.
When these teams work together, adoption improves. Support ticket trends can inform training priorities. Training feedback can reveal where product behavior is unclear. Field questions can lead to better release communications. Product changes can reduce the training burden. Knowledge articles can become source material for videos, job aids, and facilitator guides. Engineers and developers can clarify technical behavior before inaccurate assumptions spread through the organization.
This is where product thinking becomes valuable in learning and knowledge work. The goal is not to turn learning teams into product managers. The goal is to make sure user confusion becomes useful information. A recurring question is not just a training gap. It may be a design signal, a workflow signal, a documentation signal, or a support readiness signal.
Adoption improves when those signals are not ignored. Technology Helps. Judgment Matters More. Technology has changed how quickly learning and knowledge content can be produced.
AI can help draft outlines, summarize interviews, analyze transcripts, generate first-pass scripts, create knowledge checks, propose scenarios, and organize source material. Video tools can make it easier to demonstrate workflows, add callouts, simulate screen interactions, and create polished training content without a large production team. Learning platforms and knowledge systems can distribute content across a global audience, track completion, organize resources, and maintain a single place for reliable answers.
These capabilities matter. But faster production does not automatically mean better adoption.
Someone still has to understand the system. Someone has to know which details matter, where users are likely to struggle, what information must be verified, and how much complexity each audience can handle. Someone has to decide whether the real need is training, documentation, in-application guidance, product feedback, manager reinforcement, or a better support process.
The tools can accelerate the work. They cannot replace the judgment behind it. This is especially important in global organizations, where incomplete content can scale quickly. A weak explanation moves through support channels, manager discussions, translated materials, and informal workarounds. Once confusion spreads, it becomes harder to correct.
Good adoption work still depends on careful analysis, clear writing, technical accuracy, and practical understanding of the audience.
The Real Goal Is Adoption
Organizations will always ask for training. They should. Training is an essential part of any serious software rollout. But the strongest organizations ask a second question. What problem are we really trying to solve?
If the answer is a skill gap, training may be exactly what is needed. If the answer is missing knowledge, the organization may need better documentation or search. If the answer is an unclear workflow, product and process teams may need to revisit the experience. If the answer is poor reinforcement, managers may need better talking points, coaching guides, or field support. If the answer is confusion across roles or regions, the organization may need a more thoughtful learning and knowledge strategy.
Software adoption succeeds when people understand what to do, why it matters, where to get help, and how the system fits the work in front of them.
It fails when organizations create content without diagnosing the problem, launch systems without enough operational context, or assume users will figure things out once the technology is available.
After working with enterprise systems for more than three decades, I have come to believe successful software adoption is less about producing more content and more about helping people find the right answer at the right moment.
The goal is not more content. The goal is usable knowledge, confident users, fewer preventable errors, better support outcomes, and systems people can use effectively across the business.
Training matters. But adoption is the real measure.
Happy Learning!
Jeff
If you like this article, please share!