Think, Plan, Execute: How to Run Self-Service Analytics in a Thoughtful, Effective Way

Self-service has become a bit of a dirty word in the data industry.

The theory sells a rosy picture. Give more people access to data and they all become more informed, productive, and competitive across the board.

In reality, the data industry is littered with:

• Failed self-service attempts
• Metrics catalog upon metrics catalog
• More drag-and-drop interfaces than you can shake a stick at

All promising so much before ultimately delivering little value.

The problem? Far too much onus on technology doing the work for us, with little to no deep, structured thought on how self-serve should be implemented for each organization’s bespoke use-cases.

Yes, AI is transforming what’s possible at lightning speed. But the above still applies, with human-level thinking about any AI uses still highly necessary.

This article aims to offer a fix by covering what it means to do self-serve properly. We’ll put forward a mental model to build your thinking around and help you start executing on a self-service capability that actually delivers value to your organization.

Why self-service matters

The most valuable outcome from self-service is that the business is able to increase the speed and quality of its decision making.

This, ultimately, makes it more efficient and competitive than the rest of the market.

Though this sounds a bit woolly, when you break this down into tangible initiatives and use-cases (see next section) this allows you to form a pretty tangible business case—and even include a monetary ROI.

On the other side of the coin, it can stop organizations chasing diminishing returns.

For example:

• Not every question the business is asking is necessarily worth answering or is due to a lack of robust, holistic operational reports that answer the most basic questions.
• Some questions are sufficiently knotty that they really should involve the data team’s involvement just because their impact or complexity is sufficiently large.
• Sometimes it’s not even the speed of creating insights which is the bottleneck of the decision-making process - but poor/slow communication or lack of clarity or processes in the business which should be addressed first.

In these cases a broader view of the goal of self-service can help you implement the right changes even if that means investing more resources to scale the data team.

Mental model for self-service: One use-case at a time

One of the biggest mistakes we see from organizations is to treat self-service as a company-wide initiative. Though ultimately everyone in an organization should be empowered by data, it’s rarely a one-size-fits-all situation.

Every role/team/department will have different decisions to make with varying levels of complexity and scale. Within this, the people involved will then have different analytical skills and needs.

It can therefore be helpful to consider a self-service initiative as a series of use-cases, mapping the right data product to:

• decision type,
• analytic skills; and
• org structures.

This not only improves the outcomes of success but also makes the business case as clear as possible (as described above).

Cover your decision spectrum

It’s important to note at this point that in any organization there are a range of decisions that take place, from the very tactical/operational to the most strategic and complex.

Dashboards or simple self-service interfaces are great for the more tactical, operational situations. Decisions that can usually be made relatively quickly and by a single person.

However:

When the decision is complex or cuts across teams and functions, dashboards are no longer sufficient. These decisions need a tool which supports not just data but the wider workflow via collaboration, easy iteration, and discussion—and the combination of data and qualitative information.

A good self-service model needs to support both ends of this spectrum.

A use-case question framework

Here’s a list of common questions which can help inform the right solution for a given use-case, in line with the mental model above:

Decision types:

• Are the decisions being made very repeatable/transactional, more strategic, or a range?
• Where are the decision(s) actually being made? E.g. On a mobile or in a board room.
• What other inputs (other than data) need to be included for a decision to be made?

Analytical skills:

• What is the skill level of the individuals involved? E.g. Can they write SQL, read statistical reports?
• Will the team need any training or documentation to interpret the data clearly?

Data sources/modelling:

• What is the cadence of the decision? e.g. does the data need to be updating realtime/hourly/daily etc?
• Are the metrics being considered well modelled and trustworthy?
• How likely are these data sources to change?
• Is the data sensitive and need access controls?

Proving value:

• Can the value of these decisions be measured and a ROI be proven?
• Can the use of the self-service solution be measured to prove it continues to deliver?

Where to start (before building anything)

A common question data teams ask when thinking about use cases is… “Where do I start?”

There’s no right or wrong answer to this. But a helpful starting point can be to analyze the data requests received by the data team over a few week period, capturing:

• The team/individual who requested it
• The decision the request was supporting
• The complexity of the request

After a few weeks of tracking, this dataset builds up a heatmap of where the biggest unmet data demands are in the business. The data team can then focus on this area first when thinking about self-service.

How to build a self-serve environment that actually delivers value

Once you’ve found a clear department/use-case to focus on there are five steps we recommend using to build out a self-service capability and minimize the risk that what you build out isn’t fit for purpose.

1. Map the business operation

Mapping your business operations is often overlooked, yet it's critical to ensure the data products you create truly reflect your business processes and have lasting value.

Start by collaborating closely with your business stakeholders. Dive deep to fully grasp the nuances and complexities of their daily operations. Clearly define the metrics they want to track and understand the attributes of the system involved.

This isn't just about gathering data—it's about understanding the decisions stakeholders are currently making or aspire to make.

By thoroughly mapping your operations upfront, you'll build data solutions that accurately address real business needs and support strategic decision-making for the long term.

2. Build an MVP report of the top-level operation

Once you've clearly mapped the operational processes, create a high-level operational report. This MVP (Minimum Viable Product) should capture core metrics and attributes to quickly validate your initial model.

It provides immediate value by answering basic operational questions and enables the data team to perform preliminary data quality checks before fully developing the comprehensive data model.

3. Define the data model

With validation complete, you can confidently build a detailed data model.

Operationalize this data model either through a semantic layer or by creating gold-standard tables within your data warehouse. This approach ensures your data model is robust, maintainable, and ready for more detailed analytics.

4. Choose the right interface

Selecting the right interface to present your data model depends on two key factors:

1. The complexity of analytics required
2. The data literacy of the end users

Matching the interface to the specific use-case ensures the data product is accessible and effectively utilized by stakeholders.

It’s worth noting here that generative AI as an interface has the potential to be the most successful attempt at self-service analytics to date.

Even so, it requires intentional thought to lay the groundwork for any AI interface to be able to deliver compelling results at your particular organization. This is where the framework laid out in this post still applies.

5. Document, train, and maintain

At this stage, your process should include:

• A clearly mapped operational model.
• A corresponding data model, fully materialized.
• An MVP operational report summarizing key metrics.
• An interface or data product tailored for further exploratory analysis by end-users.

It's crucial now to document how all this works in a version-controlled environment that you can regularly maintain and keep current with any operational changes or bug fixes.

You should also provide comprehensive training for end-users, and continue updating them on any changes made to the data model or interface—ensuring continuous usability and reliability.

Unlock your competitive advantage with thoughtful self-service analytics

Building an effective self-service capability is a powerful way to add a competitive edge to your organization. But it needs to be done thoughtfully, with a focus on business value, and in a way that reduces the risks of failure.

Ready to get started on your own self-serve product? Take a look at Count Metrics, our semantic layer designed to help you build well-governed metric catalogs and bring no-code capabilities to the Count Canvas that your stakeholders will love.