Every digital transformation contains an unspoken belief.
Once the system is live, people will figure it out.
Not immediately, perhaps. Not perfectly. But eventually. They will log in, explore, ask around, remember the training, find the documentation, learn the workflow, and adjust. Some early confusion is expected. Some support tickets are normal. Some mistakes are part of the transition.
The assumption is that competence will naturally emerge after launch.
This assumption is comforting because it allows organizations to treat go-live as the major threshold. Before go-live, the project is implementation. After go-live, the system becomes operational. Users now have access. Training has happened. Documentation exists. The process is available. The organization begins to expect adoption.
But access does not create competence.
A live system does not automatically produce correct behavior. A trained user does not automatically become a confident user. A documented workflow does not automatically become a usable workflow. A completed rollout does not automatically create execution quality.
In complex enterprise software environments, users do not simply figure it out. They interpret, improvise, simplify, copy, avoid, ask peers, follow old habits, and choose the path that seems workable under pressure.
Sometimes that produces the intended behavior. Often, it produces drift.
That is the first lie of digital transformation: the belief that people will naturally turn system access into reliable execution.
Why “they’ll figure it out” feels reasonable
The assumption does not usually come from negligence. It comes from experience.
People do figure out many things at work. They learn tools by using them. They ask colleagues for help. They develop habits. They adapt to new processes. They survive messy rollouts. Organizations have seen this happen many times.
So leaders often expect a certain amount of post-launch learning. They assume that users will become more comfortable as they use the system. Early friction is treated as temporary. Confusion is treated as a normal adoption curve.
There is some truth in this. People do learn through use. Practice does improve familiarity. Repetition can turn difficult workflows into routine behavior.
But the assumption breaks down when work is complex, infrequent, high-pressure, or consequence-heavy.
In those conditions, “figuring it out” becomes unreliable.
A user may figure out how to submit a request, but not how to submit one that is approval-ready. A supplier may figure out how to upload a document, but not which document is required for compliance. A project team may figure out how to update a record, but not how early or completely the record must be updated for the business to trust it. A sales rep may figure out which CRM fields are required, but not how to maintain data that supports forecasting.
The difference is important.
Users can often figure out how to complete a task. That does not mean they have figured out how to perform the work correctly enough for the business outcome.
Access is not adoption
Enterprise software teams often treat access as the start of adoption.
Users have credentials. Roles have been assigned. The application is available. Training has been delivered. The workflow is live. From a program perspective, the organization has crossed a major milestone.
But from the user’s perspective, the real test begins later.
It begins when they need to perform a task inside the system while work is moving around them.
They may be trying to raise an urgent purchase request, approve something between meetings, submit an invoice before payment is delayed, document a field issue while the jobsite is active, update a CRM opportunity before a forecast call, classify a ticket while a customer is waiting, or complete an HR workflow they have not touched in months.
This is when the difference between system availability and user competence becomes visible.
| Program milestone | What it proves | What it does not prove |
|---|---|---|
| System is live | The application is available | Users can complete work correctly |
| Users have access | People can enter the system | They understand what to do inside it |
| Training is complete | Users were exposed to the process | They can apply it under real pressure |
| Documentation exists | Instructions are available somewhere | Users can find and interpret them at the moment of need |
| Workflow is configured | The intended process exists | The process fits real work conditions |
| Early activity is visible | Users are interacting with the system | The work is reliable, complete, or trustworthy |
This is why digital adoption cannot be reduced to go-live activity. Adoption begins when users have to perform real work, not when the system becomes available.
Ambiguity is where drift begins
Most enterprise software workflows contain ambiguity.
Sometimes the ambiguity is in the process. Which buying path applies? Which supplier document is required? Which category should be selected? Which approval route is correct? What qualifies as enough evidence? When should a change event be created? What does this status actually mean?
Sometimes the ambiguity is in the situation. The user may be dealing with an exception, missing information, time pressure, regional variation, incomplete handoff, conflicting instructions, or a case that was not covered clearly in training.
Sometimes the ambiguity is in the interface. The screen may show multiple similar options. The field label may be unclear. The required context may be hidden. The system may allow several paths without explaining which one is appropriate.
When users encounter ambiguity, they do not stop and become process philosophers. They try to move the work forward.
They choose the option that seems closest. They ask a colleague. They copy what someone else did last time. They use the path that worked before. They fill a required field with something acceptable enough. They submit and wait for someone downstream to correct it. They use email, spreadsheets, messages, or screenshots because those channels feel clearer than the system.
This is how drift begins.
Not as rebellion. Not always as carelessness. Often as practical improvisation inside unclear conditions.
The organization expected competence to emerge. Instead, ambiguity produced local interpretation.
Pressure changes how users learn
Post-launch learning does not happen in a calm environment.
Users learn while work is happening. That matters because pressure changes behavior.
A user under pressure is not trying to master the system. They are trying to finish the task. They want the request approved, the invoice submitted, the issue resolved, the record updated, the customer answered, the project moved, or the approval cleared.
When the official process is clear, practical, and close to the work, users may follow it. When it is unclear or slower than the alternative, they simplify.
Under pressure, people are likely to:
- choose familiar paths over correct paths
- copy peer behavior instead of reading documentation
- complete required fields quickly rather than carefully
- use informal channels to solve urgent problems
- defer system updates until after the real work has moved
- treat warnings as administrative friction
- rely on downstream teams to correct weak inputs
- return to old habits when the new process is ambiguous
This is not a failure of human character. It is a predictable response to work pressure.
That is why the assumption that users will “figure it out” is dangerous. They will figure something out. The question is whether what they figure out matches the behavior the business needs.
The first-use problem in enterprise software
First use is one of the most underestimated moments in digital adoption.
Training may happen days or weeks before the user performs the real task. Documentation may be available, but not in the flow of work. The user may remember the broad idea but not the important details. The workflow may look slightly different from the training environment. The task may involve an exception. The user may be interrupted, rushed, or uncertain.
At that moment, the organization’s assumption is tested.
Can the user understand what to do? Can they recognize what matters? Can they complete the task without creating downstream work? Can they distinguish between required and optional? Can they avoid the tempting shortcut? Can they tell whether their submission is correct?
If the answer is no, the user still has to act.
That action becomes learning. If the system accepts the weak input, the user learns that the input was good enough. If a teammate shows them a shortcut, the user learns the shortcut. If support corrects the issue later, the user learns that correction is part of the process. If the workaround gets the result faster, the user learns that the workaround works.
First use does not only reveal competence. It creates behavior.
This is why the first-use experience deserves more attention in enterprise software adoption. It is the point where training, process design, interface signals, pressure, and user interpretation collide.
What users actually figure out
Users do learn after launch. But they may not learn what the organization intended.
They often learn the practical version of the system.
| What the organization hopes users learn | What users may actually learn |
|---|---|
| The correct process | The fastest path to completion |
| The business reason behind the workflow | Which fields block submission |
| The importance of data quality | Which data can be cleaned up later |
| The need for timely updates | How late an update can be before someone complains |
| The right approval behavior | How quickly approvals can be cleared |
| The documentation standard | What evidence is usually chased later |
| The official system of record | Which side channel gets the fastest response |
| The intended workflow | What peers say “actually works” |
This difference is not trivial. It explains why adoption can appear to improve while process quality remains weak.
Users may become more efficient at navigating the system, but not more reliable at producing the right business outcome. They may reduce their own friction while increasing downstream correction. They may learn how to satisfy the interface without understanding what the business needs from the workflow.
That is not digital transformation. It is local adaptation.
Why informal learning can undermine formal adoption
Informal learning is powerful because it is practical.
When users are confused, they often trust peers more than documentation. A colleague can answer quickly. A team habit feels proven. A workaround has social credibility because someone else has already used it. A local shortcut may feel more relevant than a global process document.
This is how informal learning becomes part of adoption.
It can be helpful when peers reinforce the right behavior. But it can be risky when the group normalizes weak execution.
A team may teach new users to submit incomplete requests because “procurement will ask if they need anything.” A supplier may learn to email documents because the portal is confusing. A project team may maintain a spreadsheet because the official system feels too slow for coordination. Sales reps may learn which CRM fields need real attention and which can be filled with generic information.
No one may formally approve these behaviors. But they can become the real operating model.
This is the problem with assuming competence will naturally emerge. Competence emerges from the environment around the user. If that environment includes ambiguity, pressure, weak controls, and informal shortcuts, the competence that emerges may be competence in bypassing the system rather than using it correctly.
The difference between adaptation and adoption
Organizations often mistake adaptation for adoption.
Adaptation means users find a way to keep working. Adoption means users perform the work in a way that supports the intended business outcome.
The two are not the same.
A team can adapt to a new system by creating a shadow spreadsheet. A supplier can adapt by sending documents over email. A manager can adapt by approving quickly without meaningful review. A field team can adapt by updating records later. A sales team can adapt by filling CRM fields just enough to satisfy reporting requirements.
These behaviors help people survive the system. They do not necessarily help the organization realize the value of the system.
| Adaptation | Adoption |
|---|---|
| Users find a workable path | Users follow a path the business can trust |
| Local friction reduces | Business process quality improves |
| Work continues | Work becomes more reliable |
| Informal habits stabilize | Intended behavior becomes repeatable |
| Users learn how to get through the system | Users understand how to execute the work correctly |
| Activity increases | Outcome quality improves |
This distinction is especially important in digital transformation because the organization may see activity and assume adoption. But activity can include workarounds, shallow completion, late updates, weak records, and incomplete submissions.
Real adoption is not simply that users continue working after launch. It is that the new way of working becomes reliable enough to replace the old one.
The competence gap after go-live
The post-launch competence gap is the space between what users are expected to do and what they can reliably do in real work.
This gap is often invisible before launch because the organization measures readiness through preparation activity: training completion, documentation, communication, test cases, stakeholder signoff, and system availability.
After launch, the gap becomes visible through behavior.
| Expected competence | What reveals the gap |
|---|---|
| Users know the correct path | They choose familiar or incorrect routes |
| Users understand required information | They miss fields or provide weak inputs |
| Users remember training | They ask repeated questions at the moment of work |
| Users follow new processes | They return to old tools or side channels |
| Users handle exceptions correctly | They escalate, improvise, or create local workarounds |
| Users maintain data quality | Downstream teams clean records manually |
| Users perform tasks on time | Updates arrive late or only after reminders |
The competence gap is not always a sign that the rollout failed. It is a sign that the organization needs to treat competence as something designed, reinforced, and measured after launch.
Competence is not a natural byproduct of access. It is an operating condition that has to be built.
Designing for post-launch competence
A better digital adoption strategy does not assume users will figure it out. It designs the environment so users are less likely to figure out the wrong thing.
That means focusing on the moments where ambiguity and pressure are highest.
A useful model is to design for five post-launch conditions.
| Condition | Design question | Why it matters |
|---|---|---|
| First use | What happens when the user performs the task for the first time outside training? | First use creates habits and interpretations |
| Low-frequency use | What happens when the user returns after weeks or months? | Memory fades when tasks are rare |
| Exception handling | What happens when the case does not match the standard workflow? | Exceptions often create workarounds |
| High-pressure execution | What happens when speed competes with correctness? | Pressure reveals the path users really trust |
| Downstream consequence | What happens when weak input moves forward? | Users may not feel the cost of poor execution |
Designing for these conditions changes the work of adoption. The goal is not only to explain the process before launch. It is to make correct execution more likely after launch.
That may involve clearer workflow paths, better field-level context, stronger validations, role-specific support, timely prompts, better exception handling, in-flow guidance, manager reinforcement, and measurement that looks at workflow quality rather than activity alone.
The specific mechanism will vary by system and process. The principle remains the same: do not leave competence to chance after go-live.
The role of digital adoption in reducing ambiguity
Digital adoption should be understood as an ambiguity-reduction discipline.
At its weakest, digital adoption helps users navigate software. At its strongest, it helps organizations reduce uncertainty at the exact moments where uncertainty creates business risk.
That means digital adoption should answer questions such as:
- Where do users hesitate?
- Where do they choose the wrong path?
- Where do they rely on peers or side channels?
- Where do they submit incomplete information?
- Where do they abandon the workflow?
- Where do they repeatedly ask for help?
- Where does the system allow poor execution to move forward?
- Where do downstream teams correct what upstream users should have done differently?
These questions are more useful than asking only whether users logged in, completed training, or launched guidance.
They focus on the quality of execution after launch.
Digital adoption becomes valuable when it helps users act correctly inside the real workflow, not merely when it gives them information somewhere near the software.
What leaders should stop assuming
Leaders should be careful with certain assumptions after go-live.
| Assumption | Better question |
|---|---|
| Users will figure it out | What will they figure out if the workflow is ambiguous? |
| Training will carry them | What happens when training is no longer fresh? |
| Documentation is available | Will users consult it during real work? |
| Early confusion is normal | Which confusion is creating repeatable bad habits? |
| Activity means adoption | Is the activity producing reliable work? |
| Support tickets will decline naturally | Are users learning the right behavior or finding informal workarounds? |
| Managers will reinforce the change | Are managers rewarded for speed, quality, or both? |
| The system is live, so the process is live | Is the intended behavior actually happening inside the system? |
These questions do not make leaders pessimistic. They make adoption more realistic.
The goal is not to eliminate uncertainty before launch. That is impossible. The goal is to recognize that uncertainty will appear and to design the adoption model around it.
The danger of optimistic implementation
Digital transformation programs often carry an optimistic view of users.
The optimism says that people are capable, practical, and adaptive. That is true.
But capability is not the same as reliable execution. Practicality can produce shortcuts. Adaptation can produce shadow processes. Confidence can produce shallow completion. Peer learning can spread poor habits. Local success can create global inconsistency.
The problem is not that users cannot figure things out. The problem is that users will figure things out according to the conditions they encounter.
If the official workflow is clear and useful, they may learn it. If it is confusing, they may work around it. If the system tolerates weak data, they may submit weak data. If support teams correct issues later, they may learn that correction is expected. If leadership measures completion but not quality, they may optimize for completion.
Users are not passive recipients of transformation. They are active interpreters of it.
This is why digital transformation cannot end at deployment. The real transformation happens when user interpretation begins to stabilize into organizational behavior.
Competence must be observed, not assumed
One of the most important shifts is from assuming competence to observing it.
Before launch, leaders can assume users are ready because training is complete. After launch, they need to verify whether users are actually performing the work correctly.
This requires looking beyond surface adoption metrics.
Logins, page views, feature use, training completion, and workflow volume may show activity. They do not necessarily show competence.
Better competence indicators include:
- reduction in repeated user errors
- fewer incomplete submissions
- cleaner handoffs between teams
- fewer downstream corrections
- fewer avoidable support questions
- more timely updates
- better data quality
- fewer side-channel dependencies
- stronger trust in reports and records
- better completion of high-consequence workflow steps
These measures are closer to the real question: did users learn how to execute the work in a way the business can trust?
From “people will figure it out” to “we will learn what reality teaches”
The more mature posture is not to assume users will figure everything out correctly. It is to assume that post-launch behavior will teach the organization what the rollout did not fully understand.
Every repeated question is evidence. Every workaround is evidence. Every incomplete submission is evidence. Every late update is evidence. Every support pattern is evidence. Every downstream correction is evidence.
These signals should not be treated only as user issues. They should be used to improve the adoption model.
The organization should ask:
- What did users misunderstand?
- What did they find too difficult?
- What did they avoid?
- What did they copy from peers?
- What did the system allow?
- What did the workflow fail to clarify?
- What did downstream teams have to rescue?
- What behavior became normal after first use?
This changes the meaning of post-launch support.
Support is not just a help desk function. It is an intelligence source. It shows where the organization’s assumptions met reality and where reality disagreed.
Conclusion: users will figure something out
People are resourceful. They will find a way to keep working.
That is exactly why “people will figure it out” is not a safe adoption strategy.
Users may figure out the intended workflow. They may also figure out the shortcut, the workaround, the minimum acceptable input, the peer-approved path, the old process hidden inside the new system, or the fastest way to satisfy the screen without satisfying the business need.
The question is not whether people will adapt.
They will.
The question is whether their adaptation will produce the behavior the transformation was meant to create.
Digital transformation succeeds when organizations stop treating competence as an automatic result of go-live and start treating it as something that must be designed, supported, observed, and improved after launch.
A system can be live before the organization is ready to use it well. A workflow can exist before users know how to carry it reliably. Training can be complete before behavior has changed. Early activity can rise before true adoption has taken hold.
That is why the first lie of digital transformation is so costly.
People will not simply figure it out.
They will figure out what the system, pressure, peers, incentives, and interface teach them to do.
The work of digital adoption is to make sure they learn the right thing.