Why I Built Clarivant

Someone in the C-suite asks a simple question:

"What's our customer lifetime value by region?"

Silence.

"How much did we spend on marketing last quarter compared to forecast?"

Someone mumbles something about "pulling that together" and "getting back to you." Three weeks later, an Excel file appears. It's wrong. Nobody trusts it. Decisions get delayed.

I've watched this happen at every mid-market company I've talked to. And it's not because they lack data — they're drowning in it. The gap is between having data and using it to make decisions.

That gap is why Clarivant exists.

Why the gap persists

Big companies solve this by writing large checks. They hire a name-brand consulting firm, buy the enterprise stack, build a 10-person data team, and wait 18 months for results.

Mid-market companies can't do that — and shouldn't have to.

They're too big for Excel and Power BI. Too small for enterprise budgets. Too lean to wait a year and a half. So they limp along with spreadsheets, manual reports, and decisions made on gut feel.

The conventional wisdom — that enterprise-grade analytics requires enterprise-level spend — is wrong. The frameworks that power billion-dollar operations aren't inherently expensive to run. They're expensive because of how they're delivered: layers of project management, junior consultants learning on your dime, and discovery phases that produce nothing but slide decks.

Strip all that away, and what's left is a pattern. A very repeatable one.

My own path to this

I discovered data analytics the way most people do: out of desperation.

Early in my career, someone handed me an Excel file with 60,000+ rows. The file wouldn't open — Excel at the time couldn't handle it. That moment forced me into Access, then SQL, then automation. What started as a workaround became a revelation: if you knew pivot tables and conditional formatting, you were in the top 1% of any company's Excel users. If you could automate it with macros, you became indispensable.

That curiosity became a pattern. At P&G, when Excel and Access weren't enough, I learned R, KNIME, and Hadoop. At eBay, when I needed to process millions of transactions across 15 countries, I learned machine learning at scale. The progression wasn't planned — it was driven by increasingly complex problems.

And here's what I realized along the way: the tools matter far less than knowing which problem you're actually solving.

Every mid-market executive I spoke to said some version of the same thing: "We need what you built at those companies, but we can't afford the enterprise price tag." And they were right — they couldn't afford the delivery model. But they could absolutely afford the solution.

What Clarivant stands for

I'm not building a consultancy that scales by adding headcount. There's a version of this work where the consultant becomes a dependency — where the client needs you forever because you built something only you understand. That's not what I'm after.

Every system I build, you own. Every pipeline is documented, tested, version-controlled. When I leave, your team runs it.

What that actually looks like in practice: I show up as a senior practitioner, not a partner who sells and a junior who delivers. I measure success against business metrics — margin, cost, churn, revenue — not dashboard counts. And I work fast enough that something useful exists within months, not fiscal years.

That's the model I'd want to buy if I were on the other side of the table.

The point of view

The question I start every engagement with isn't "what tool should we buy?" — it's "what decision are you trying to make, and what's stopping you from making it with confidence?"

Start there, and the architecture follows. Skip it, and you end up with a warehouse full of tables nobody trusts and dashboards nobody opens.

Most analytics projects don't fail because the technology is wrong. They fail because nobody asked the right question first. That's the lens I bring — not a methodology deck, but "what's actually broken, and what's the fastest path to you trusting your own numbers?"

Frequently asked questions

What makes Clarivant different from a traditional analytics consultancy?

The delivery model. Most consultancies scale by adding junior staff who learn on your project — you get billed for the learning curve. At Clarivant, you work directly with a senior practitioner who built analytics systems at P&G and eBay. The goal is to leave your team more capable than when we arrived, not more dependent.

Do mid-market companies really need the same analytics stack as enterprise companies?

The architecture patterns, yes. The enterprise price tag, no. What makes enterprise analytics work — clean data models, version-controlled pipelines, governed metric definitions — isn't inherently expensive to build. It's expensive because of how it's typically delivered. The frameworks are repeatable. The billing model doesn't have to be.

How long before a typical analytics engagement produces something useful?

Something useful should exist within the first month — not a strategy deck, but a working pipeline or dashboard that answers a real question. Full production delivery typically runs three to five months depending on complexity. If a vendor or consultant tells you to expect 12-18 months before results, that's a delivery model problem, not a technology constraint.

What happens after the engagement ends — does our team need ongoing support?

Everything built is documented, tested, and version-controlled so your team can maintain it. The intent is that when we leave, you own the system completely — no dependency on Clarivant to keep the lights on. Some clients choose to continue with advisory work, but that's a choice, not a requirement.

What's the first question you ask when evaluating a new analytics project?

"What decision are you trying to make, and what's stopping you from making it with confidence?" Technology questions come second. Starting with the decision frames the entire project around business value rather than dashboard counts or model counts — and it usually reveals that the problem is narrower and more solvable than it first appeared.