Realizing Gains in the Face of Difficult Data: Taking a Decision-First Approach

Many “data-driven” projects fail to deliver tangible results in a reasonable timeline or even at all. Their focus is on data, reporting, or modeling rather than making better decisions that improve a business objective such as profitability. Instead, I advocate a decision-first approach, which is effective in its ability to deliver impact quickly, facilitate cross-functional buy-in, and maintain team alignment.
Decision-First
Business-Impact
Project-Implementation
Objectives
Author

Louis Boguchwal

Published

April 11, 2023

We are in the age of data. Companies are collecting more information than ever, employing data teams, and spending money on data tools and technologies. This “data-first” approach often involves meaningful investments to build out numerous datasets and metrics before crafting a concrete strategy regarding how to use them.

While there is certainly value in creating a basic foundation of data and metrics, it seems the pendulum is swinging the other way. Data for its own sake does not generate cost savings, revenue increases, or customer growth. In other words, data collection, manipulation, and storage do not magically improve business fundamentals.

Advocating a “Decision-First” Approach

In contrast, company investments in staff time, databases, software, and documentation should be in service of making better decisions. Therefore, the shortest path to business impact starts with how decisions can improve, rather than how input data can improve. Granted, real world data is rarely in an immediately usable form. Among other reasons, information that does not accurately reflect a concept cannot be used to represent that concept. Additionally, if the way something is counted in a system is flawed, then the data could either under- or over-state the quantity in question (e.g., warehouse touchpoints or user clicks).

But as soon as the input data is sufficiently representative it should be leveraged.

This decision-first approach that uses data “as soon as reasonable” yields the following benefits, even if executing on a small scale:

  • Measurable Validation of Success: Before a project begins, success metrics should be established using reliable output data1. With these metrics in place, any version of project implementation can be evaluated.
    • When the team is able to visualize and explore success metrics, the value of the work delivered so far is clear, invigorating the next phase of the project.
    • Additionally, the team might find that results are better than expected in early phases, thereby saving time on future data cleaning.
  • Rapid Impact: If there are gains to realize, why not start realizing them sooner rather than later? Even a small scale implementation can yield benefits, which can grow with each successive project phase.
  • Quick Learning and Iteration: The team can quickly evaluate the merits of the project, any course correction, and ultimately whether it is worth continuing. Projects that spend inordinate amounts of time on data exclusively risk discovering low return far too late.
  • Motivating: Rapidly executing, even a minimum viable product, motivates the project team with quick delivery.

The Show Must Go On: Implementation in the Face of Imperfect Data

However, there is a valid concern that conclusions reached will lead to misguided decisions if the company accepts its input data as-is and moves forward with the project. But this concern often goes too far, derailing progress and more importantly, business impact. Just as “perfection is the enemy of the good” so too is data perfection the enemy of project execution and profitable outcomes. Note that I have seen stakeholders as well as data teams focused on perfect data.

Though sometimes the input data coming from source systems and databases is truly unusable. For example, necessary data components might not be collected, or the staff resources required to correct existing data errors could be cost-prohibitive.

Is the project and its impact doomed in this case?

Not on my watch.

A decision-first approach is resilient against data issues that arise. In my experience, partnering with business stakeholders and subject matter experts fills in formerly-blocking data gaps. Specifically, this means providing an interface for the team to bring its on-the-ground knowledge to the project. For example, the team could enter information into a simple user-interface or form. Additionally, leveraging stakeholders’ domain knowledge involves them in the process. Consequently, (rightful) skepticism in the data turns into trust, as project stakeholders provided the data themselves.

Data-Second: Better Data is Still Valuable

All this is not to say that input data should always remain merely “sufficient,” without improvement, but instead suggests that data quality is not the absolute top priority. If we have a project that already drives impact, then we stand to increase that impact with better data through iterations over time.

This creates a feedback loop of benefits that eventually yields diminishing returns. At some point applying better data to a project process does not meaningfully change company decisions compared to former data.

Try Out a Decision-First Approach

Many “data-driven” projects fail to deliver tangible results in a reasonable timeline or even at all. Their focus is on data, reporting, or modeling rather than making better decisions that improve a business objective such as profitability.

I have found a decision-first approach to be effective, benefiting from its ability to:

  • Deliver impact quickly and iteratively, even in the face of erroneous or insufficient data.
  • Maintain team alignment regarding objectives and how to achieve them.
  • Facilitate cross-functional buy-in.
  • Motivate the team.

Try executing with this approach. Did it accelerate timelines and unblock your project? Did it clarify objectives and increase impact?

This post introduced and advocated going decision-first. The next post will expand on this with a step-by-step implementation guide for your organization.


Get Insights

Stay up to date on our articles, approaches, and methods

Footnotes

  1. Output data should be quite reliable, as distinguished from the input data↩︎