#068: What's The Value of Analytics? (getting buy-in)

career leadership Jun 05, 2024

The value of analytics is not the data itself, it is the decisions the data makes possible. Inside most companies a data team is a cost center, so your budget gets weighed against the people and products that visibly bring money in. That means the case for investment has to be made in business terms: better decisions, hidden opportunities, and a sense of control over the operation. Benefits like a single source of truth matter, but what actually moves people is the result of those benefits. Back the argument with something real, a rough proof of concept and one end to end deliverable that solves a problem somebody already complains about. Buy-in follows visible results far more reliably than it follows a pitch.

Key takeaways

A data team is an expense on the company's books. Acknowledging that openly is the starting point for a funding conversation, not a reason to get defensive.
Stakeholders who route around you with spreadsheets are not being difficult. They are taking the fastest path to an answer, and they will keep taking it until yours is faster and more trustworthy.
The benefits worth naming are more and better metrics, a single source of truth, and consistent delivery people can rely on.
Outcomes beat benefits. Better decisions, hidden opportunities and a feeling of control are what leaders are actually buying.
Show instead of tell. A simple proof of concept opens more doors than a pitch squeezed into the end of a meeting.
Pick one deliverable, build it end to end, then move on. Counting tables built is being busy, not productive.
Every tool you add is harder to remove than it was to add. Start simple and expand only once you have proven the need.

Start by accepting the dynamics

Most of us in data assume everyone else can see the value, and that investing in it should be obvious. In practice it often is not. Understanding why makes the conversation much easier to have.

Data is an expense on the books

Whoever owns the budget is looking at one list of costs and another list of revenue drivers. Sales reps and the product sit on the revenue side. The warehouse, the ingestion tool and the data team sit on the cost side.

Data does drive revenue, just indirectly. At face value it is still an expense that supports whatever actually earns, and pretending otherwise does not help your case.

Stakeholders will route around a slow process

Business stakeholders prefer a quick workaround to waiting on your pipeline. They have their own deadlines, and an export into a spreadsheet gets them moving today.

That is not bad intent. It is people doing the best they can with what is in front of them, and it continues until something better and trustworthy exists.

There is a culture element too, in how much the company respects the data team's process. You will not fix that with a policy. You fix it by becoming the faster and more reliable option.

Lead with benefits, in their language

When you talk to the business, drop your framing and use theirs. Think about the questions people keep bringing you and what they are really trying to get out of them.

Three benefits land almost every time:

More and better metrics. People want more ways to evaluate how the business is doing, and a real architecture gives them that.
A single source of truth. One agreed set of numbers instead of every department maintaining its own version.
Consistency. The same metrics delivered the same way on a schedule, rather than numbers that shift depending on who pulled them.

Be honest with yourself on the single source of truth. It is a bit of a mythical thing, because there are always nuances and edge cases.

It is usually close enough to be effective, and that is the point. The goal is to drive decisions and make the company more effective, not to achieve perfection.

Sell the outcome, not the benefit

Benefits are a good start. The result of the benefit is better, because that is the part a leader can picture.

It sounds like a small distinction, but you are not selling the metric. You are selling what somebody gets to do with it.

Better decisions

When I worked at a logistics company we built reporting that let the business evaluate individual trucking routes. Which ones were cost effective, which ones were consistently losing money.

That changed behavior. The team stopped over committing to losing bids and doubled down on the profitable ones, and sales reps went into negotiations knowing the real picture.

Hidden opportunities

The second outcome is finding things nobody knew were there. A marketing campaign you can finally tie to specific sales, for example, turning out to be a far stronger channel than anyone assumed.

Without connected data you never see the full extent of that impact. Those are the insights that justify the investment on their own.

A sense of control

Control is underrated as a selling point. Business leaders are juggling a lot and mostly trying to keep things afloat.

Consistent information, delivered on a cadence, in a format they chose, makes them feel like they will not be blindsided. It is a cost, but it buys them control over their own operation.

Four ways to get buy-in in practice

All of that is framing. Here is how I try to make it concrete.

1. Avoid technical jargon

Technical people love talking about technical things, and it gets us into trouble. This is not about anyone's ability to understand. It is that the detail is not necessary and it pulls the conversation off the point.

You will have to discuss tool selection and cost at some level. The deeper technical debate belongs inside the data team.

2. Show instead of tell

Nobody is going to fully buy in from a pitch at the end of a meeting. They have too much else going on.

Build a small proof of concept instead, which is a working but throwaway version of the idea. A playground stack on open source tools is enough, even if those are not the tools you would buy.

Seeing one report move through a real pipeline gives people a taste of what is possible. That is what gets them to take the first step.

3. Focus on quick wins

Data projects have a reputation for taking forever, and the reputation is partly earned. Migrations slip, things break, and momentum is hard to hold when that happens.

The fix is to scope the first win small enough to finish. Pick a single deliverable, bring in only the sources that deliverable needs, and build just the models behind it.

That gives you one end to end pipeline you can prove out. End users get a result quickly, and you get time to work out conventions and rough edges before the second one.

The alternative I see often is a team that ingests everything at once, divides and conquers, and reports progress as number of tables built. That is busy rather than productive, and nobody outside the team can see the needle move.

To choose the deliverable, find a current problem somebody already has:

A report that is a mess today and could be rebuilt properly
A process stuck in a spreadsheet that belongs on the data platform
A data feed somebody keeps asking for and never gets

4. Avoid shiny object syndrome

Shiny object syndrome is the pull to add the next new tool because you read about it and feel behind without it. It makes a stack complicated far too early.

The asymmetry is what gets teams. Adding a component is easy, removing one is painful, so each addition is close to permanent.

Start bare bones. Simple stack, simple conventions, and maximize the few tools you have. When something genuinely breaks down under load, add the tool that fixes that specific problem.

Key terms

Cost center

A function the company books as an expense rather than a revenue driver, which is how internal data teams appear on a budget.

Single source of truth

One agreed place where a metric is defined and read from, so departments stop maintaining conflicting versions of the same number.

Playground data stack

A throwaway environment, often on open source tools, built to demonstrate the concept of an architecture before anyone commits budget to it.

Single deliverable

One specific report, feed or process chosen as the first thing to build end to end, instead of ingesting every source at once.

Shiny object syndrome

The habit of adding new tools because they are new and exciting, which over complicates a stack long before the complexity is needed.

Common questions

How do you explain the value of analytics to a non technical executive?

Talk about decisions, not architecture. Name the decision they are making today with incomplete information and describe what they would see instead. Cost, risk and missed opportunity are the three angles that tend to land.

What do I do when stakeholders keep using spreadsheet workarounds?

Treat it as feedback on speed rather than a discipline problem. People use the workaround because it answers their question today. Rebuilding one of those workarounds properly, and making it faster to use, is usually the most persuasive thing you can do.

What should the first data deliverable be?

Something that already annoys somebody. An existing report nobody trusts, a process living in a spreadsheet, or a feed that keeps getting requested. Pick one, build the pipeline end to end for it, and let that be the proof.

Should the proof of concept use the tools we plan to buy?

Not necessarily. The point is to show the concept, so open source or free tier tools are fine. You are demonstrating what the workflow produces, not making a final tooling decision in front of an audience.

How do I keep momentum after the first quick win?

Keep the same pattern instead of scaling up all at once. Take the next single deliverable, reuse the conventions from the first one, and let the pipeline grow through repetition. Each round should be smoother than the last.

Is it worth asking for budget before showing anything?

You can, but expect it to be harder. A conversation that starts with a working example, even a small one, changes the question from whether this is worth trying to how far it should go.

Final takeaway

Across the teams I work with, the ones that get funded are rarely the ones with the best architecture diagram. They are the ones that shipped a single useful thing early and let the business feel the difference. Make one decision better, visibly, and the rest of the conversation gets easier.

Additional Free Resources

Starter Guides & Checklists

Explore additional free resources built on the same patterns I use with real clients so you can build your own with structure and confidence. Topics include data architecture, modeling and more specifically for small data teams.

Browse Resources