Blog Post

How to Empower Your Organization with Analytics

Nick Freund
June 19, 2023

Spend long enough at any modern company, and you will have had this dreaded experience: Someone within your organization, be they a leader with eyes on improved efficiency, or a security team plugging a newly found leak, throws a new piece of software into the mix with little warning. 

People across your team end up scrambling. They sit through haphazard training sessions, or sift through exhaustive documentation, and despite it all, the new shiny tool ends up unused. Or, end users find the new solution so cumbersome and confusing that the team who bought it – or worse, the team that is simply charged with maintaining it – spends all of their time troubleshooting rather than doing their actual job.

When you speak with CIOs, you will hear that these are generally viewed as the worst case scenarios for any piece of software that is brought into an organization. A failed or scattershot implementation erodes trust between different functions, wastes company budget, and fails to address the issue the tool was meant to solve in the first place.

Unfortunately, from speaking with many data teams, we often hear the same story of haphazard software adoption being emulated when it comes to their data technologies. 

Steve Jobs explained this tendency to emphasize ideas over implementation in reflecting on one of the challenging periods in Apple’s history, saying, "it's the disease of thinking that a great idea is 90% of the work … it is that process that is the magic.” While Jobs was talking about building rather than implementing products, we agree that the success of initiatives is not their idea, but rather the magic of the journey.

We would like to suggest that data teams begin to organize their enablement efforts, as well as the success of their data initiatives, around a “customer journey.” By viewing and measuring their efforts in this way, data teams can avoid the pitfalls associated with software that becomes “shelfware,” or which ultimately results in unhappy end users. If data is a product, the people who consume it should be supported and enabled like any customer.  

Onboarding New Users

A simple way to start thinking about what it means to empower end users is to consider what context a new employee will need in order to use a specific tool after they join the company. 

The worst version of this, across both software and data assets, is to simply point the user toward an intranet, or a help center, and to have them read all the documentation there. Why doesn’t this work?

Intranets are great ways of storing lots of information, especially when that information is hierarchical in nature. However, the information is also decontextualized, lacking all but the most basic reference points for why the information they contain is important. Without this context, new users are unlikely to retain much of what they read.

Training documentation is important, but it should be only one piece of an overall strategy that emphasizes context, and puts real business priorities front and center. This doesn’t mean you have to provide hours-long live training sessions to every person who joins the organization – the best teams employ a variety of approaches, including live sessions, in-context guides, and documentation.

The style of training should support end users with different learning styles and levels of comfort using data. For some, a more hands-on session may be necessary, while others might prefer a Pendo- or Appcues- style guide that allows them to walk step-by-step through your dashboards on their own time. Many teams will create self-guided challenges that ask users to use tools like Looker Explores to solve a problem, in order to familiarize them with the available resources. 

Whatever exact form your training strategies take, they should always be designed with scalability and self-service at the top of mind, so that you can provide context without necessarily needing a member of your data team in the room, or available in a Slack channel.

Technical Support and Enablement

Even the best tools require some form of ongoing support. Things break, customers will have ad hoc requests, and after using something for a long time, the basics of training can feel far away.

When building data products, analytics teams need to keep this ongoing support in mind. While having flows for issues with asset quality is important, support means more than bug fixes; it means that users always have the tools they need to appropriately contextualize data, and drive insights from it.

The most common solutions for ongoing support are to either shunt the user to an intranet that may or may not have the answer the user needs, or to use one of the oldest fallbacks: the service desk. We have discussed extensively on this blog how service desk models are broken, and how they lock data teams into transactional power dynamics with stakeholders. 

Viewed through the lens of software customer enablement, there is another reason why relying too heavily on the service desk model is a bad idea: service desks are inherently reactive, while enablement should be proactive. 

You do need a fallback if someone has a question that truly cannot be answered without a member of the data team stepping in. However, if users are needing to ask these questions with any level of frequency, it indicates that the end user is already not fully enabled. Proper enablement results in self-sufficiency.

Ongoing Training

Rather than focusing on answering questions as they come up, data teams can save time and encourage self-sufficiency by implementing different forms of ongoing training. To illustrate why this is necessary, think about some of the possible circumstances your team might find themselves in:

  • A user needs to track down a metric that is outside of the normal suite of dashboards they typically use. Do they know where to find that metric? Do they know what the metrics mean when they do? Could they properly use a self-service asset like a Looker Explore to analyze it themselves?
  • Company-wide KPIs are made available to everyone in the company. Are users able to identify what inputs create the metrics, so they can see how their work impacts them?
  • If a user needs to present metrics to a cross-functional working group, will that group have access to the underlying data and definitions, or will they use an entirely different set of jargon?
  • When someone goes out on parental or another type of extended leave, can they hit the ground running with the necessary data when they get back?

There are a lot of potential approaches to this ongoing training. You could host lunch and learn sessions, drop-in office hours, or make Loom videos available for a dashboard that raises a lot of questions.

For more self-service oriented teams, offering to review dashboards created by users can also be a way to make sure your analytics tools are being used correctly, and with the appropriate context. Ted Conbeer, the Chief Data Officer at Privacy Dynamics, discussed this approach on a recent episode of our Data Knowledge Pioneers podcast:

“In almost every interaction with my stakeholders across the business and Product and Ops and Marketing, I would just repeat this over and over again. If you ever don't know, or if you don't use the dashboard every day and you just found something and you want to build something new, just send it to me. Because I can take 15 minutes and probably tell you if it's close to right or not. But if you never send it to me, if you never ask, I'll never know.”

Every training initiative is of course dependent on your team’s staffing and the organizational culture around your data. But the more options you have where your end users can keep up with ongoing changes and be reminded what is actually valuable, the better enabled they will be.

How to Rollout New Features and Assets

The impact of data teams is often measured by how much they build, and how quickly they can put crucial data in front of end users.

But even the best teams have rolled out new dashboards or self service assets  that seem like they will be of value, only to find that no one uses them. It turns out, how you launch a new feature or asset is just as crucial as what you launch.

Again, we can take our lead from the customer journey through software adoption to understand how to avoid this scenario:

Good software companies keep their customers engaged with their roadmap 

  • Customers not only know what is coming down the pipe, but also have input into how the end result should look before development starts. The customers know what is coming, and have the ability to help make sure the final product is relevant to them.
  • It can be a good idea to have a general roadmap available to everyone in the company as well, so that even users who are less engaged can understand what you are working on.

Announcing new features early, and training proactively, is key

  • Announcing new features is obviously table stakes for any rollout, but the timing of those announcements is crucial. Giving users advanced warning when a new release is imminent allows you to socialize it ahead of time, and prevent surprises on release day.
  • The announcement timeline should be synced with your training strategy as well – whether self-service or hands-on, every release should have some form of training that is available as soon as you go live.

Product updates and changelogs give everyone a source of truth for what’s new

  • When changes are actually released, making a product update or changelog available keeps everyone apprised of new options. These updates should be shared regularly in order to drive traffic to new assets or features. 

Measuring adoption gives you a waypoint

  • You don’t know what you don’t know, and if you are relying on anecdotal data or simply surveying department heads about how their teams use new features, you do not have the complete picture. We have discussed in a previous article how investing in these adoption metrics can benefit your organization, but this is doubly true during the actual rollout process.

Iterate, iterate, iterate

  • There will no doubt be another new asset coming out right after the one you have just released. Before you move on, though, be sure to use the journey you have just gone through to make your next rollout even better. Along the way, expect to make mistakes, to take away learnings from every step, and to constantly evolve your rollout process.


This may seem like a lot of extra work to throw on top of building the data products that your organization uses on a day-to-day basis, but the process of empowering your end users speaks to one of the possibly less glamorous truths about data: success is not just about what you build, it is about how what you build is used

Just as a poorly implemented software solution can wind up as shelfware, all of your efforts to build engaging data assets can be for nothing without proper enablement. 

By treating your end users as customers, though, and putting a multi-faceted enablement strategy in place, your analytics team can make sure all your efforts directly contribute to the success of everyone in the business.

Nick Freund
June 19, 2023