I read a piece in HBR recently by Marcus Buckingham called What Companies Can Learn from Their Biggest Fans. His argument is that most companies pour their energy into fixing what’s broken — low engagement scores, customer complaints, churn drivers — and not nearly enough into studying the people who are already deeply loyal. The ones who advocate without being asked. The ones who stay when it would be easy to leave.
Buckingham’s insight is that behavior doesn’t change in response to mildly positive experiences. It changes when experiences cross a threshold — when people don’t just feel satisfied, but feel something closer to love. And most organizations never get close to that line because they’re too busy patching holes to notice what’s actually working.
That’s a compelling argument for customer strategy and employee engagement. But it hit me differently. It made me think about how data teams serve their internal stakeholders — and how most of us have set the bar way too low for what that should feel like.
Here’s a phrase I’ve been sitting with lately: our job is not just to produce data feeds. Our job is to build data experiences for stakeholders.
That distinction matters more than it might sound. A data feed is a pipeline, a report, a dashboard — something that gets delivered. A data experience is something that gets felt. It’s the difference between shipping a number and shaping how someone makes a decision.
When I think about what a great data experience looks like, it comes down to four things. It makes decisions easier and faster. It builds trust, not confusion. It feels intuitive, relevant, and timely. And it turns data from a reporting function into a strategic advantage.
Most data teams — including ones I’ve led — don’t think in those terms. They think about accuracy, coverage, uptime, ticket velocity. Those things matter. But they describe the mechanics of delivery, not the quality of the experience. And the experience is where trust gets built or lost.
I’ve written before about why data teams shouldn’t operate as service desks — reactive, ticket-driven, optimizing for throughput instead of impact. This is the other side of that same coin. Even teams that have moved past the service model can still fall into the trap of measuring themselves by delivery instead of experience. Shipped is not the same as valuable. On time is not the same as trusted.
The Buckingham article gave me a sharper way to frame this. If your company’s purpose is to create fans — or anything resembling loyalty, trust, and advocacy — that standard shouldn’t stop at the customer. It should apply to how you serve internal stakeholders too.
Think about what that means in practice. Your partners across the business should feel the same things you want fans to feel externally: confidence that the data is right. Clarity about what it means. Trust that you understand their world. And a sense that every interaction with your team makes them better at their job.
That’s a different standard than “delivered on time.” And it’s a standard most data teams have never explicitly held themselves to.
I spent a few years at Rocket Companies, and one of their ISMs has stuck with me: “Every client. Every time. No exceptions. No excuses.” It’s a consistency standard — not just about doing great work occasionally, but about making sure the experience is reliably excellent no matter who the client is or what the situation looks like. That’s a useful lens for data teams too. It’s not enough to deliver a great experience for your most important stakeholder or on your highest-profile project. The standard has to hold across every interaction, every deliverable, every Slack thread. That’s how trust compounds. One great dashboard doesn’t make you trusted. Being consistently excellent across dozens of small moments does.
The shift starts with how you understand the people you serve. Most data teams know what their stakeholders ask for. Fewer understand how they actually work — how they make decisions, where friction slows them down, what keeps them coming back to your team versus pulling their own numbers and guessing.
That kind of understanding is the same muscle companies use to learn from their biggest fans. What do they need? How do they operate? Where does friction exist? What makes them trust you enough to keep coming back?
I’ve written about business context as a force multiplier for technical people — the idea that understanding the business deeply changes the quality of everything you build. This is what that looks like when applied to the stakeholder relationship. When a data team knows the stakeholder’s incentives, their language, their decision-making rhythm, the output changes. Not because the SQL is different, but because the framing is sharper, the timing is better, and the trust compounds over time.
There’s a real gap between a stakeholder who gets what they asked for and a stakeholder who feels like your team helps them win.
The first one is satisfied. They’ll say your team is “fine” in a survey. They won’t complain. But they also won’t advocate for your budget, pull you into strategic conversations early, or go out of their way to give you context that makes your work better.
The second one is a fan. They’ll defend your team’s priorities when someone else wants to jump the queue. They’ll bring you problems before they become fires. They’ll tell other leaders that your team is one of the best partnerships they have. That kind of relationship changes what a data team can accomplish inside an organization — not because someone gave you permission, but because the people you serve keep pulling you closer.
And you don’t cross that line by being fast and accurate. You cross it by making people feel understood.
So what changes day to day?
Understand the full picture, not just the request. When a stakeholder asks for data, there’s usually more to the story. They’re not just looking for a report — they’re trying to figure out how to acquire more customers, evaluate a new product launch, understand why retention is slipping, or build a case for a budget decision. Your job is to understand that full context, not just fill the order. The better you understand how the data will actually be used, the better the experience you deliver — and the more likely you are to give them something they didn’t know to ask for. That kind of closeness to the business doesn’t happen by accident — it’s a daily practice. I wrote about the specific habits that build that muscle in A Daily Checklist for Staying Close to the Business.
The box sells the cereal. There’s an old saying in consumer products: the box sells the cereal. The product inside might be great, but if the packaging doesn’t land, nobody picks it up. Data works the same way. A dataset or dashboard without context is just noise. How you frame a deliverable — what changed, what matters, what the stakeholder should do next — is as important as the numbers themselves. The packaging is part of the experience. If the insight is buried in a 15-tab spreadsheet with no narrative, you haven’t delivered value. You’ve delivered homework.
Proactive beats reactive — and it’s not even close. The highest-trust relationships I’ve seen between data teams and their stakeholders aren’t built on fast turnaround. They’re built on the data team surfacing something the stakeholder didn’t know to ask about. Maybe you notice a trend in the pipeline data that suggests a regional slowdown before anyone in sales has flagged it. Maybe you see an anomaly in customer behavior that changes the assumptions behind a planned campaign. When you bring that to someone before they had to ask, you move from vendor to partner in their mind. That’s what people remember — not the report that showed up on time, but the insight that showed up before the meeting. You can’t do that if your entire capacity is consumed by the queue. Proactive work requires protected time and a team that’s curious enough to look beyond the request in front of them.
Friction is signal, not a training gap. If a stakeholder keeps asking the same clarifying questions, or keeps pulling their own data instead of using what you built, that’s not a knowledge problem. It’s a design problem. Something about the experience isn’t working, and the fix is on your side, not theirs. I’ve seen teams blame low dashboard adoption on stakeholders not being “data literate.” That’s a cop-out. If someone with 15 years of domain expertise can’t figure out your dashboard in 30 seconds, the dashboard failed — not the user. Pay attention to where people work around your tools. Pay attention to what questions come in repeatedly. Those patterns are telling you exactly where the experience breaks down. The best data teams treat that friction the way a product team treats user complaints — as a gift that tells you what to fix next.
Treat your work like a product manager would. If you shipped a product and never checked whether anyone used it, you’d get fired. But data teams do this all the time — build a dashboard, deliver a model, publish a report, and move on. A product manager would ask: is anyone actually using this? How often? Is it effective? Are people making better decisions because of it? Start collecting real metrics around usage and experience. Track adoption. Run NPS surveys with your stakeholders. Find out whether the things you built are actually landing, or just sitting there. If you don’t measure the experience, you’re guessing — and you’ll keep optimizing for output when the real problem is impact.
None of this is easy. It requires a team that’s curious about the business, not just technically skilled. It requires leaders who protect time for relationship building and don’t treat every hour away from a keyboard as waste. And it requires a willingness to be honest about the gap between what you’re delivering and what your stakeholders actually experience on the receiving end.
But here’s the thing I keep coming back to. If you lead a data team inside a company whose entire purpose is about earning trust and loyalty, then the standard for how you serve internal stakeholders should match that purpose. You’re not just supporting the mission from behind a dashboard. You’re living it — or you’re not.
The bar I want to hold is simple: it’s not whether you delivered. It’s whether the experience you created improved confidence, speed, and quality of decision-making for the person on the other end. Hit that consistently, and you’re not just a data team. You’re a team people want to work with. And that changes everything.