Data Product Capabilities 1

SIX REASONS YOUR ANALYTICS SOLUTIONS ARE FALLING SHORT

The uncertain economy is forcing businesses to find ways to derive more value from both their customer-facing products and their operational investments, but many companies struggle with the latter. After years spent building data warehouses, visualization tools, and dashboards, they are still having trouble using those solutions to improve business decisions that directly impact operations and sales.

When it comes to deriving and demonstrating value, customer-facing products and applications have a distinct advantage over internal analytics and reporting solutions. It’s far easier for external product development teams to gather and incorporate customer feedback to improve external offerings. Product owners often use Agile approaches to incorporate this feedback and speed the release of new features, which in turn increases adoption, creating a virtuous cycle. For internal analytics products, things are far less straightforward. Gathering feedback, making iterative improvements, and measuring the value they deliver are generally much harder.

TOP SIX CAUSES OF ANALYTIC VALUE GAPS

So what are some of the issues underlying this value-delivery conundrum? It helps to compare internal solutions with customerfacing ones to get at some of the root causes. Here are the top six we’ve identified:

THERE IS LITTLE TO NO SOLUTION GOVERNANCE

External products are generally well defined. But internal solutions are often developed haphazardly whenever a problem is identified. That can lead to solution proliferation in which expert users take matters into their own hands, developing point solutions to specific problems and publishing them to a wider audience. In a larger organization this can cause real headaches: eight versions of the same shipping report, for example, or hundreds of dashboards with little clarity regarding which one users should turn to. As priorities shift, the problem is only exacerbated. Changes are made with minimal oversight, and solutions may be abandoned without being formally decommissioned.

FEEDBACK LOOPS ARE INEFFECTIVE

Market-facing applications are usually built with a direct and fast customer feedback loop that helps companies continually improve their products by adding features that customers want. This, in turn, increases usage and consequently revenues. Amazon’s famed recommendation engine is a great case in point. The AI-driven capability gets smarter with each user interaction, making it more likely that customers will trust and purchase from Amazon.

The situation is quite different when you’re dealing with operational solutions—particularly the analytics solutions that support decision-making. Why? We see a handful of common reasons:

Most internal dashboards are built on visualization platforms that don't come with a native feedback mechanism other than simple usage statistics (i.e., who used the dashboard how many times).

It can be difficult to gather feedback directly from constituents who are scattered across the organization with multiple competing priorities.

Unlike with external products, there is no market pressure to continually improve the offering.

The data that feeds various dashboards and visualizations is often messy and stale.

OUTCOMES ARE NOT ALWAYS CLEAR

Consumer-facing products are designed to solicit a specific outcome from a customer— whether it’s measured in terms of clicks, revenues, likes, or some other metric. Data analytics solutions, on the other hand, are about improving decision-making. That’s a lot harder to measure. For example, if the solution is intended to help users select one vendor over another, how do you measure success? How do you even know what outcome you should be measuring? If the desired outcome hasn’t been clearly articulated, it’s impossible to measure and track progress.

ATTRIBUTION IS EXTREMELY DIFFICULT

Developers of externally facing products are continually tweaking their offerings based on feedback. They are able to quickly incorporate the most valuable features, in part because they can test them simultaneously and determine which ones generate the “best” response, often in the form of more clicks or increased sales. In other words, each change in customer response can be attributed back to a particular change made to the product. Many social media companies, including Facebook, Tik Tok, and Instagram, make highly successful use of this approach: They release new features,

monitor the response for each, and compare responses with one another. This enables them to quickly determine which new features produce the biggest “bang for the buck.” It is unusual for analytics solutions to have such a clear and high degree of value attribution. Furthermore, once an internal solution is live, the development team has usually moved on to the next project, making it unlikely that attribution will garner the attention it deserves.

THE END CUSTOMER IS LEFT OUT OF THE EQUATION

External products target specific customer groups and are designed to meet their particular needs. The product creates a direct link between the company and its customers. This is rarely the case with internal analytics solutions. In fact, in a situation where a development team is building a solution based on an internal request, it’s not always apparent who the ultimate consumers of the solution will be. For example, take a performance management dashboard for a manufacturing company. Are you building it for executives so they can track productivity across facilities for revenue planning and reporting, or for the facilities managers so they can monitor and maintain equipment more efficiently? Without knowing which individuals or groups are making decisions based on what you are building, it’s difficult to ensure you are truly creating value. As a result, the solution may need to be re-engineered or abandoned altogether.

Another issue internal data solutions run up against is that in the absence of a customerdefined problem: The data often defines the solution versus the problem defining the solution. For example, a common request is for a dashboard that displays specific data rather than for a solution that uses data to help someone make a particular decision better or faster. The upshot? A completed project: check. Value delivered? Not so much.

THE SOLUTION LACKS A PRODUCT CHAMPION

Oftentimes, the development of an analytics solution is headed up by a project manager. Their job is to fulfill the internal customer’s request.

The role of a product champion is something different entirely, and it’s typical of the Agile and Design Thinking approaches commonly used to develop externally facing applications. The job of the product champion is to deliver value.

How? It starts with asking the right questions.

Consider the following conversations:

TRADITIONAL APPROACH

Internal Customer: I‘m not sure what I want, just give me access to the data.

Project Leader: OK, let’s set up a meeting to discuss requirements, scheduling, and budget.

PRODUCT APPROACH

Internal Customer: I need a tool that downloads the data in this system.

Product Champion: Why?

Internal Customer: Because I need to dump it into a spreadsheet so that I can compare it with the forecast.

Product Champion: Why?

Internal Customer: Because I’m responsible for doing an actuals-to-forecast comparison every month so that managers can make decisions about inventory.

Product Champion: Then why don’t we build you something that makes the comparison for you? Also, this is similar to a problem that we started looking at in the logistics department, and if what we build here works, there might be a way to expand this to address both issues.

By continuing to ask “why,” the product champion can uncover the core issue, identify alternate approaches for solving the problem, and come up with ways that the solution can deliver value elsewhere in the organization.

A product champion doesn’t take an internal customer’s word for it that what they ask for is what they really need—any more than a physician would prescribe a medication to a patient simply because they think they need it. The remit of the product champion is to dig into the root causes of a problem and to find a solution that will resolve it. And because delivering value is their ultimate responsibility, they are accountable for keeping development efforts in line with the original strategic intent. Finally, a product champion is open to multiple paths to get to the right answer. They approach product development with the understanding that not every question needs to be resolved at the get-go. Rather, by continually iterating and adjusting, the product champion can shepherd the product towards maximum value delivery.

The problems that beset internal data solutions are not insurmountable. What companies need, however, is a different mindset and approach to developing them. Much has been learned by teams who build customerfacing applications. By taking a page from the product playbook and associated Agile methodologies—including assigning a product champion —analytics teams will be able to deliver real and sustainable value to their internal customers.

David Mobley

Chief Practices Officer

David.Mobley@aspirent.com

Howard Chalmers

Principal & Product Management Leader

Howard.Chalmers@aspirent.com

Mark Hodgdon

Principal & Senior Client Director

Mark.Hodgdon@aspirent.com

ABOUT ASPIRENT

Aspirent Consulting partners with the world’s largest organizations to simplify their most complex analytics and digital product development challenges—helping them cut through the complexities that slow progress, stifle innovation, and limit growth. Through a mix of proven frameworks, experienced teams, and unbiased technology expertise we deliver clientspecific solutions that simplify and speed the path to success. Learn more about us at www.aspirent.com