A dashboard can calculate perfectly and still mislead the person reading it.

The query can be correct. The source data can be complete. The visualization can be clean. And two teams can still mean different things by “active customer,” “qualified lead,” “retained revenue,” or “launch.”

I’ve learned to be particularly interested in the moments when people stop trusting the official number.

If a team repeatedly exports data into a spreadsheet before a meeting, for example, I don’t immediately assume they’re resisting the system. I want to know what they’re repairing.

Maybe there is a definition the system doesn’t capture. Maybe the timing is wrong. Maybe two sources disagree. Maybe the official metric is technically accurate but missing something everyone in the room knows matters.

The spreadsheet isn’t necessarily the problem. Sometimes it’s evidence of the problem.

The numbers are connected even when the dashboards aren’t

At one company, a new CRO came in as we were beginning to move into the enterprise market. Historically, we hadn’t done much with multi-year contracts. He wanted more of them, and the new commission structure reflected that.

There were accelerators and incentives for the behavior we wanted. We configured the CPQ system to calculate them correctly.

Then we started seeing the results.

On some multi-year deals, the combination of incentives meant commission expense was consuming the profit margin. In some cases, we could pay more in commission than we received from the customer in the first year.

Nothing was broken in the calculation.

The system was doing exactly what we’d asked it to do.

But compensation turned out to be only one part of the problem.

Our product couldn’t actually consume a multi-year contract. It still behaved as though the customer’s term ended annually.

So we built a process around the limitation. Someone had to know the contract was multi-year. The salesperson had to be alerted. Support had to get involved. Eventually an engineer had to manually “renew” the product so the customer could continue using something they had already purchased.

The workaround solved the immediate problem. It also created several new ones.

Our systems could still treat these customers as though they were approaching renewal. Reporting couldn’t cleanly distinguish an actual renewal from the artificial renewal we had created to keep the product running. Dunning and customer communications could operate on the wrong assumptions. A customer on a three- or five-year contract could receive messaging based on an annual lifecycle because one part of the company knew what we had sold and another part couldn’t represent it.

Each team could look at its own system and see something internally reasonable.

Sales saw a multi-year booking. Finance saw the contract and its economics. The product saw an annual term that needed to be renewed. Support saw a task that had to happen for the customer to retain access. Engineering saw an exception requiring intervention. Reporting saw events that looked like renewals.

The customer, meanwhile, had simply bought a multi-year contract.

The original mandate had essentially been: start selling multi-year.

The question we hadn’t asked first was: What would it take for us to sell multi-year?

Those are very different questions.

The second one forces the commercial opportunity into contact with the rest of the organization. Can the product represent it? Can billing support it? What happens at the end of year one? What happens if the customer changes the agreement in year two? What does it do to margin and cash? What manual work are we creating? What will our reporting call these events?

And then, with those answers in front of us: is the opportunity worth the cost and risk right now?

Maybe it is. Moving into enterprise and securing longer contracts can be worth accepting some temporary complexity. The problem wasn’t necessarily the decision. It was making the decision in one part of the organization and distributing its consequences across several others without seeing them together.

This is where metrics become more than reporting.

Attach a number to compensation, performance, or executive attention and people learn very quickly what the organization values. A salesperson who maximizes a multi-year contract because the compensation plan rewards it isn’t behaving irrationally. They’re responding rationally to the system they’re in.

But if we only look at bookings, we see the behavior we intended to create. We don’t see the engineering intervention, the support work, the confused renewal reporting, the incorrect customer communication, or the margin disappearing into commission.

The booking is real. So are all the things it caused.

Sometimes the metric changes what you think the problem is

I saw another version of this at a company spending heavily on customer support.

From one vantage point, the diagnosis was straightforward: customers needed too much support, so support needed more capacity.

But when I started following what customers were actually asking support to do, a different problem appeared.

The product’s data model assumed something like: one customer → one environment → one user identity

That wasn’t how increasingly complex customers actually worked.

A customer might have several teams doing different kinds of work, with different administrative needs, requiring separate environments. But the product couldn’t cleanly represent one person administering multiple environments within the same organization.

So people found workarounds.

A user might exist once as admin@company, then again as something like admin+1@company to administer another environment.

From the support team’s perspective, these were customer requests that had to be serviced.

From the product’s perspective, they could look like separate environments.

From the user-account data, they could look like additional users.

From another dashboard, some of that might even resemble growth.

These weren’t separate phenomena. They were different measurements of the same architectural constraint.

Putting more money into support could make the symptom easier to absorb. It couldn’t remove the reason customers needed support in the first place.

And the distorted data created another problem. Once the underlying model was wrong, the organization couldn’t easily answer basic questions about itself. How many actual users do we have? How many environments does a customer need? How many support interactions are really product workarounds? What does an “account” even represent?

This is why I’m wary when departments review their numbers entirely in isolation.

Sales has its MBR. Support has its dashboard. Product has adoption metrics. Finance has margin and cash. Customer Success has retention.

Each view may be accurate.

But the business happens between them.

A booking becomes implementation work. A product limitation becomes a support ticket. A pricing decision changes customer behavior. A compensation plan changes what gets sold. A data-model decision changes what looks like a user.

The interesting question isn’t only whether each number is correct.

It’s whether we’ve put the numbers close enough together to see what is actually happening.

When a metric changes, I want to know what changed underneath it. Who did more work? What moved somewhere else? What became more expensive? What behavior did we reward? Which cases disappeared from the denominator? What became harder to see?

Those aren’t soft questions in opposition to hard data.

They’re how we figure out what the hard data means.

A dashboard is a lens, not the landscape. The danger isn’t that measurement compresses reality—we need it to. The danger is forgetting that it did.