You Don't Have a Data Problem. You Have a Definition Problem.
Gohvio ยท 2026-05-26
"We have a data problem." No -- you have a vocabulary problem.
Every ops conversation eventually arrives at the same complaint: "We have a data problem."
The complaint takes different shapes. Pipeline numbers don't match between Sales and Finance. The MQL count Marketing reports doesn't tie to the SAL count Sales tracks. Customer Success thinks there are 1,200 customers; Finance thinks there are 1,140; the website says 1,300.
The teams point at the data. They run reconciliation projects. They hire consultants. They buy new BI tools.
The data isn't the problem. The problem is that "MQL," "customer," "pipeline coverage," and a dozen other foundational terms mean different things to different people at the same company. Every team is correctly counting what they think they're counting. The counts don't agree because the things being counted are different things.
It's not a data problem. It's a vocabulary problem dressed up as a data problem.
The four MQLs.
Take "MQL" -- marketing qualified lead. At one company I worked with, four different teams used the term and meant four different things.
Marketing said an MQL was any contact who scored above a threshold in their lead-scoring model. That model included demographic, firmographic, and behavioral signals. The threshold had been adjusted three times in the last year as the team tuned for sales acceptance.
The Marketing Ops team said an MQL was any contact in HubSpot with a specific lifecycle stage. The lifecycle stage moved when the score crossed the threshold, but it also moved via various automations that ran on form submissions, content downloads, and event attendance. So the lifecycle-stage MQL count and the score-based MQL count were always slightly different.
Sales said an MQL was anything Marketing had handed over to them. So if a lead skipped the score and went directly to a rep via an event lead capture, that was an MQL too. If a score-qualified lead never got routed (because the routing rule was paused, or the rep was out, or the geography didn't have coverage), it wasn't an MQL by their count.
Finance said an MQL was anything that showed up in the MQL column of the marketing performance dashboard. That dashboard pulled from a Salesforce report owned by Marketing Ops. The Salesforce report used the lifecycle-stage definition, but with a 30-day lookback that nobody else was using.
Four definitions. Four numbers. One word. Every quarterly business review started with twenty minutes of trying to reconcile the four. No one had ever written down the canonical definition.
That is the definition problem.
Why this happens, predictably.
The pattern is the same everywhere.
A term enters the company casually. Someone says "MQL" in a meeting. Everyone nods. Each person mentally fills in their working definition.
Tools are configured around those mental definitions. Reports get built. Dashboards get launched. The mental definitions calcify into system behavior.
Nobody ever writes down the canonical definition because, in any given conversation, everyone "knows" what an MQL is. They don't notice that they don't all know the same thing.
Six quarters later, the company has four definitions, four tools enforcing them differently, four teams that are sure they're right, and a CEO asking why the numbers don't add up.
Cleanup projects can't fix this.
This is why "data cleanup" projects rarely solve the underlying problem.
You can dedupe the database. You can fix the email validation. You can scrub the historical records. None of it touches the definition disagreement underneath. After the cleanup, the same four teams will look at the cleaned data, apply their four definitions, and produce four different numbers again.
The data was never the constraint. The definition was.
You can't fix a vocabulary problem with a janitorial project. You have to actually write down what the word means.
How to fix a definition problem.
Three steps. None of them are technical.
Step 1: Surface the disagreement. Get the relevant teams in a room. Ask each one to write down their working definition of the contested term -- without checking with each other first. Then read them out. The disagreement, which felt invisible, becomes visible. People are usually shocked at how different the definitions are.
Step 2: Pick one. Document it. Decide which definition will be canonical going forward. This is the hard conversation. Some team's working definition will lose. That's OK. What matters is that there's one. Write it down in plain English. Name the source of truth (which system holds the master data). Name the refresh cadence. Name the owner who's responsible for the definition staying current.
Step 3: Migrate the systems. Update the tools so that every report, dashboard, and automation that uses the term uses the canonical definition. This is the easiest of the three steps once the definition exists. The hard part was getting agreement, not deploying it.
That's the playbook. It works for "MQL." It works for "customer." It works for "active user," "pipeline coverage," "ARR," "churn," and every other term that's been quietly meaning different things to different teams.
The benefit, immediately and over time.
The immediate benefit is the disagreement stops.
The longer-term benefit is bigger. Once the definition library exists, every new tool, new report, new hire, and new integration inherits the standards. Drift becomes harder. Onboarding becomes faster. AI tools layered on top start producing consistent answers because the inputs are consistent.
And the cleanup work shrinks dramatically. Most "data quality" problems were definition problems in disguise. Fix the definitions and the data quality issues you were chasing turn out to have been arithmetic disagreements all along.
Start with the words that fight.
You don't need to do this for every term in your company. Start with the three terms that show up in the most arguments. For most companies, that's customer, MQL, and pipeline. Sometimes it's deal, ARR, or revenue.
Run the three steps for one term this quarter. Watch what happens to the meetings that depend on that term.
Do the next one next quarter. Inside a year, you'll have a working definition library for everything that matters. The arguments you've been having for the last three years will stop happening.
The bottom line.
If your data feels broken, check your definitions first. Most companies are dragging janitorial cleanup tools across what is fundamentally a vocabulary problem. The numbers don't match because the words don't match.
Write down the words. Pick the definitions. Document them. The data, suddenly, gets a lot less broken.
Want to find every data gap in your CRM in one upload? Start your free trial -- free.
Frequently asked questions
What's the difference between a data problem and a definition problem?
A data problem is when the data itself is wrong -- typos, duplicates, missing fields. A definition problem is when the data is "correct" by each team's definition, but the teams are using different definitions of the same term. Most cross-team disagreements are definition problems wearing data-problem clothing.
How do I tell if my data quality issues are actually definition issues?
Ask each team to write down, separately, their working definition of the term in dispute. If you get more than one definition, you have a definition problem -- the cleanup project alone won't fix it.
What goes into a canonical definition?
At minimum: plain-English definition (what is included, what is excluded), source of truth (which system holds the master data), refresh cadence, and named owner. Without all four, the definition will drift again within a year.