Analytics transformations are often designed around what has to be built.
A new platform is selected.
Measurement is redesigned.
KPIs are standardized.
Dashboards are migrated.
Governance is defined.
Data becomes easier to access.
Then, somewhere near the end, attention turns to adoption.
People are trained.
Documentation is published.
Champions are identified.
Teams are encouraged to use the new capability.
I think that sequence gets something important wrong.
If analytics is meant to change how an organization makes decisions, adoption is not a downstream change-management activity. It is part of the analytics capability itself and should influence how that capability is designed from the beginning.
This view comes from working across analytics transformations, multi-market environments, self-service initiatives, platform rollouts, training, and capability building. The recurring lesson is that making analytics available and making analytics usable are different problems.
Access is not the same as capability
A modern analytics platform can give more people direct access to data. That can be valuable. But access alone does not create self-service.
A user still needs to know which question to ask, which metric is appropriate, how definitions relate to the business, which dimensions matter, what a comparison actually means, and how much confidence to place in the result.
Without that context, more access can simply distribute analytical inconsistency more widely.
This is why I see self-service as an operating-model question rather than a product feature.
The relevant issue is not whether somebody can open the analytics platform. It is whether the organization has created the conditions in which that person can use evidence appropriately for the decisions they are responsible for.
Those conditions include reliable measurement, understandable definitions, sensible access, clear ownership, analytical standards, and enough capability among users to interpret what they see.
Training matters, but it is only one part of that system.
Different people need different relationships with analytics
An analyst may need to explore data deeply, challenge definitions, create new measures, and assess whether an observed pattern is statistically or causally meaningful.
A product manager may need to understand how customers use a feature, where journeys break down, and whether a change improved the intended outcome.
A commercial leader may need a reliable view of performance, the ability to investigate important deviations, and confidence that teams are working from consistent definitions.
The goal should not be to turn all of these people into analysts.
It should be to give each group enough analytical capability to make better decisions within its role, while making clear when deeper analytical expertise is required.
That distinction affects how tools are configured, how information is organized, what gets standardized, what should remain flexible, and what kind of enablement is useful.
Across my own roles, capability building has included training, mentoring, power-user development, self-service approaches, common KPI definitions, and analytical standards. These were not separate from the analytics operating model. They were mechanisms for extending analytical capability beyond the central team.
Training should be connected to real work
It is easy to design analytics training around the tool.
How to build a chart.
How to apply a filter.
How to create a segment.
How to save a report.
Those skills may be necessary, but they are rarely the reason the organization invested in analytics.
The more important questions are closer to the work itself.
How should a team investigate a change in customer behavior? Which metrics should be used to evaluate a product change? When should markets be compared and when should they be analyzed separately? How should a user distinguish an interesting correlation from evidence that supports an intervention?
These questions connect analytical capability to decisions rather than to software functionality.
That does not mean every training session needs to become an advanced analytics course. It means enablement should be designed around the ways different users are expected to work with evidence.
Once that is clear, the technology becomes easier to teach because it has a purpose.
Adoption also depends on what the analytics team builds
It is tempting to treat low adoption primarily as a user problem.
People have not been trained enough.
They are resistant to change.
They keep using spreadsheets.
They prefer the previous system.
Sometimes those explanations are partly true. They can also hide weaknesses in the capability itself.
If metrics are difficult to understand, users will hesitate to trust them. If several reports answer apparently identical questions differently, people will create their own version. If finding the right information requires specialist knowledge, self-service will remain limited regardless of how many licenses have been distributed.
Adoption therefore provides information about the design of the analytics capability.
It can reveal problems with measurement, definitions, discoverability, usability, ownership, or the fit between analytical products and the decisions people actually need to make.
That makes adoption a two-way relationship. The organization needs to develop users' analytical capability, but the analytics function also needs to learn from how people use, misunderstand, or avoid what has been built.
Governance and adoption are connected
Governance is sometimes presented as the restrictive side of analytics: definitions, standards, ownership, and control.
Adoption is presented as the enabling side: access, self-service, training, and flexibility.
I do not see them as opposites.
Good governance reduces the amount of knowledge a user needs to reconstruct every time they use data.
If a metric has a clear definition and ownership, the user does not need to resolve that question independently. If common analytical concepts are standardized, teams can spend less time reconciling competing versions of the same measure. If measurement quality is understood, users can make more informed judgments about the evidence in front of them.
Governance can therefore make self-service easier, provided it is designed to support decisions rather than simply to control the analytical environment.
The same applies to roles and responsibilities. A scalable operating model needs clarity about what business users can reasonably do themselves, what requires analytical support, who owns definitions, and who is accountable for the quality of the underlying measurement.
Sustainable analytics capability combines technology with priorities, measurement foundations, governance, roles, self-service, analytical capability, and stakeholder adoption.
The transformation is not finished when the platform launches
Technology projects naturally have milestones.
Implementation complete.
Migration complete.
Rollout complete.
Analytics capability is harder to finish in that way.
A platform can be live while the organization still depends heavily on a small group of specialists. Dashboards can exist while teams continue to use inconsistent metrics. Users can have access without knowing which analysis they should trust or how to translate it into a decision.
This does not mean every user needs to become fully self-sufficient. Some analytical questions should remain with specialists.
The objective is more practical: the right analytical capability should exist at the right places in the organization, with clear boundaries between self-service and specialist support.
That has been a consistent part of my experience across organizations and markets, including standardizing methods, developing power users, building self-service approaches, training and mentoring, and supporting the adoption of new analytics capabilities.
Design adoption into the capability
When analytics is treated mainly as a technology or reporting function, adoption can appear to be something that happens after delivery.
When analytics is treated as an organizational capability, that distinction becomes difficult to maintain.
The people using analytics, the decisions they need to make, the skills they require, the definitions they rely on, the support available to them, and the technology itself are parts of the same system.
That leads to a different question during transformation.
Not:
How will we get people to adopt what we build?
But:
What do we need to build so that people can use analytics effectively in their work?
The difference is subtle, but important.
Adoption is not evidence that the analytics transformation has been communicated successfully.
It is part of what the transformation is supposed to achieve.