Imagine you’re looking at the results of a blood test. One result is highlighted:

22%.

Is that good?

You probably have a few questions:

• What does this measure?

• What’s a normal range?

• Should I be concerned?

• What would cause it to change?

• Do I need to do anything about it?

Your doctor doesn’t just tell you the number. They explain what it means, how it compares to what’s typical, and whether it requires action.

The same thing happens in business all the time. Whether the number comes from a fundraising report, a marketing campaign, a financial statement, or a website dashboard, the number itself is only part of the story.

Most of us spend at least part of our careers translating numbers for people who aren’t close to the data behind them. Over time, I’ve realized I rely on the same set of questions almost every time.

Whether I’m explaining a metric to leadership, reviewing results with a team, or helping someone understand a report they didn’t create, these questions fill in the parts of the story a number can’t tell you by itself. And when I’m on the receiving end, they’re the same questions I want answered before I decide what to do next.

Q1: How do we make it safe not to know?

Before you even talk numbers, make it clear that nobody is expected to know all of this already. Remember that the person receiving this information didn’t build the report, and they may not even use the system it came from. They shouldn’t be expected to instantly understand every metric, assumption, and calculation behind it.

If you’re explaining:

“Before we dig in, let me give you some context on where this comes from. Some of this might be new.”

If you’re asking:

“I want to make sure I’m reading this correctly. Can you walk me through it?”

Good conversations happen when people stop pretending they already understand and the people doing the explaining avoid making others feel foolish simply because they have different expertise.

For example, a development director presents fundraising results to board members who don’t work with donor metrics day-to-day. Before discussing donor retention, campaign performance, or year-over-year giving, the director spends a minute defining the metrics and providing context so board members can focus on the discussion instead of wondering whether they’re missing something.

Two good things happen that turn this into a productive conversation. First, board members gain enough context to participate confidently. Second, everyone stays focused on the problem to solve rather than getting stuck on terminology or debating what a metric means. The discussion moves more quickly from “What are we looking at?” to “What should we do about it?”

Q2: What does this number tell me? What’s missing?

Every metric captures part of reality and ignores the rest. It’s useful to know where a number comes from, but you also need to understand what activity or action the number represents (and what it does not).

A website pageview tells us that someone visited a page. But it doesn’t tell us whether they found what they were looking for, stayed to read, or left immediately.

A customer satisfaction score isn’t just a number. It tells us how a group of customers responded to a survey. But it doesn’t tell us how the customers who didn’t respond felt about their experience.

If you’re explaining:

“This score comes from our post-purchase survey. It reflects the opinions of customers who chose to respond, but not those who ignored the survey entirely. It’s useful feedback, but it may not represent every customer’s experience.”

If you’re asking:

“What does this number measure, and what part is not included here?”

Q3: Why do we look at this number?

The easiest way to waste time in a data conversation is to spend twenty minutes discussing a metric that isn’t connected to the decision you’re trying to make.

If you can’t explain why you’re looking at a number, it’s hard to know what to do with it. And a number can be perfectly accurate and still be irrelevant to the question at hand.

If you’re explaining:

“We’re looking at email open rate because we’re trying to understand whether our subject lines are getting attention. This metric tells us whether people are interested enough to open.”

If you’re asking:

If this number went up, down, or stayed the same, what would we actually do differently?

For example, a retail store sees more visitors this month than last month, but fewer visitors are actually making purchases. Foot traffic and purchase conversion rate answer different questions. Until you know what the business is trying to achieve, you can’t know which number matters most.

Q4: What’s “normal?”

A number needs context, or it’s just trivia. Whether something is good, bad, or unremarkable depends entirely on what you’re comparing it to. This is where you need a reference point such as benchmarks, historical performance or industry trends.

If you’re explaining:

“For an email list like ours, a 20–25% open rate is typical. We’re currently at 22%, which puts us in the normal range.”

If you’re asking:

“Compared to what?”

For example, a nonprofit reports that 48% of last year’s donors gave again this year. Is that good? It depends. If donor retention is typically 40%, that’s very encouraging. If it has historically been 60%, it may signal a problem. The number hasn’t changed. The context has.

Q5: What makes the number move?

Knowing why a number moves helps you respond.

Numbers don’t just decide to be different. Something happened. Usually several somethings. Some of those factors are within our control. Others aren’t. The more clearly we understand the difference, the more likely we are to take productive action instead of reacting to noise.

For example, a nonprofit sees a decline in donations during the summer. Before sounding the alarm, the development team looks for possible drivers. Is this a seasonal pattern that happens every year? Did they do less outreach than normal? Did a major grant end? The answers matter because each explanation suggests a different response.

If you’re explaining:

“Donation totals are influenced by the number of outreach campaigns, donor retention, grant funding, seasonal giving patterns, and broader economic conditions. Some of those are within our control, and some aren’t.”

If you’re asking:

“What would have to change for this number to improve?”

Q6: What should we pay attention to?

Not every movement in the data deserves a reaction, and not every metric has the same clock. A weekly change might be meaningful for website traffic during a marketing campaign, but largely irrelevant for annual donor retention or employee turnover.

Want to create anxiety? Watch a metric more closely than it was designed to be watched. In some situations, moderate fluctuations in the numbers are normal. Some changes may be expected at certain points or only become meaningful when they persist over time.

For example, a Customer Support team sees a spike in tickets the week after launching a new product feature. On its own, that increase isn’t necessarily bad news. More customers may be using the feature, asking questions, and learning how it works. The more important question is whether ticket volume returns to normal after the initial adjustment period.

If you’re explaining:

“Support tickets increased after the launch, which was expected. We’ll continue monitoring for a few weeks, but a short-term spike isn’t unusual.”

If you’re asking:

“What amount of change would actually cause us to act?”

Why these questions matter

Every good data conversation touches on these six questions, whether they get said out loud or not.

When the questions are skipped, people fill in the gaps themselves. They make assumptions about what a number means, whether it’s good or bad, what caused it, and what should happen next.

When those questions are answered, people spend less time talking past each other and more time solving the problem in front of them. Decisions get made with a shared understanding of what the number represents, what it doesn’t, and why it matters.

Just as importantly, everyone gets better at these conversations. The person explaining learns to communicate more clearly. The person asking learns what to look for. Over time, both sides become more confident working with data they didn’t collect and metrics they don’t use every day.

Most questionable decisions aren’t caused by a lack of data. They’re caused by confusion about what the data means, what it doesn’t mean, or why it’s being discussed at all.

Ask better questions, and the numbers become a lot more useful - and the conversation does too.

Subscribe now

“Data” is too often a four-letter word that makes otherwise confident people feel stupid.

After launching We Dig Data, I consistently got the same question: “What do you mean by data?” It baffled me. To me, everything is data: numbers on a financial statement, an offhand comment in a customer interview, the fact that I’ve now heard someone mention the same book twice in one week, or that my kid is sleeping fewer hours than usual.

Anything that can be counted, observed, or treated as a signal? That’s data.

For me, data has always been a quiet superpower. It cuts through noise, helps me make decisions with confidence, and brings sanity to situations where politics might drown out facts. So, imagine my surprise when the main response to my carefully crafted elevator pitch was not “Cool! That sounds incredibly helpful. Let’s talk.”, but instead a request to clarify the fundamental noun (“data”)!

My first theory was that it was a vocabulary problem: maybe “information” or “insights” would land better. Wrong. I got the same question. My second theory was that data just felt boring or irrelevant to them. Also wrong. These people genuinely believed that good data could improve their work and their lives.

So as I continued to ask colleagues, clients, and friends about what the word “data” meant to them, I found an iceberg. The word “data” wasn’t triggering confusion; it was triggering shame.

“I know I should use it, but I don’t know where to start — and honestly, I don’t like it.”

“I am suffocating in data already. What more do you want me to do?”

“I’m not a numbers person.”

“I’m not technical.”

These aren’t lazy or checked-out people. These are driven, capable, goal-oriented people who regularly stretch outside their comfort zones. The problem wasn’t motivation, but the word itself.

What we learned is that the workplace data literacy gap isn’t just a skills problem. It is also a language problem that became an identity problem. The word “data” has quietly accumulated decades of baggage that makes capable, intelligent people feel inadequate before they’ve even looked at a single spreadsheet.

The word “data” comes with baggage.

When many people ask “what do you mean by data?,” they’re actually asking something deeper. Welcome to manager-turned-therapist territory. Here are four beliefs standing between many people and their own data, and what to do about it.

The word “data” can make someone feel exhausted before the conversation even begins. For many managers and business owners, the word conjures an already-overflowing inbox of dashboards, metrics, reports, and spreadsheets, none of which seem to connect to the actual problem weighing on them. When this group asks “What do you mean by data?,” they’re not asking for a definition. They’re really asking: “Which piece of this overwhelming pile are you about to make my problem?” Lower their resistance by focusing on the business issue they care about.

Instead of: “Let’s analyze your data”

Try: “To grow profitability so you can expand the business, let’s look at who your best customers actually are, which days of the week generate the most revenue, and where cash might be quietly leaking out.”

Some people hear “data” and worry they are about to be exposed as bad at math. This one surprised me. Many high-performing managers and successful entrepreneurs still carry an old belief that they “are not numbers people.” When they hear “data,” they brace for regression models or technical explanations that make them feel out of their depth. They want to know: “Are you speaking the language of business, or the language of statisticians and engineers?” The antidote is to focus on what to measure rather than how to measure it. People rarely fear evidence; they do fear looking stupid.

Try: “Before making staffing changes, let’s measure where your team’s time is going, identify the bottlenecks, and total how much time and money their activities save the company.”

Others hear “data” and assume you’re talking about technology. In many organizations, “data” historically belonged to IT. So they picture databases, cloud infrastructure, and cybersecurity. This group is often trying to clarify a practical question: “Are you talking about a dashboarding software or business insights I need to manage my team?” Anchor your conversation with the business insights and benefit, not with a discussion of the data. People do not wake up wanting cleaner data. They wake up wanting to grow lead pipelines, shorten project timelines, and retain more customers.

Finally, some people think “data” equals “Big Data”, not their everyday operations. Media coverage of data focuses on AI, machine learning, and privacy. These people look at their 5-person team and don’t see how it applies to them. What they miss is their data hiding in plain sight. The sticky notes on their desk. Which customers quickly go from quote to sale. The projects that always run late. This group asks for clarification because they don’t see how the concept applies to their messy, real-world operations.

Try: “Let’s keep track of which customers ghost you after sending them a quote, which customers responded quickly, and what the quotes’ services and terms. This will help us identify patterns that will help us make adjustments.”

Data as a supporting character.

Notice what all four reactions have in common: the remedy is to focus on an outcome the person already cares about, not the data itself. You probably can’t talk someone out of their reaction to the word “data.” That baggage is theirs to unpack. But you can stop making data the main character. When you focus on the outcome, data takes its proper place: not as the point of the work, but as a tool that helps the work get better.

Nobody lies awake worrying about their “data collection strategy.” But plenty of people lie awake wondering why a good client went quiet, whether their team is actually making progress, or where last quarter’s margin disappeared. Those are the conversations data was meant to support.

Someone’s reaction to the topic of “data” has been shaped by years of their own professional experience, assumptions, frustrations, and even identity. And that is certainly more baggage than I intend to raise and unpack during an elevator pitch.

So, we are practicing something different. We try to talk about what data does, rather than what it is. We talk about turning an existing, abundant asset (data) into a manager’s survival guide. We talk about finding proof instead of relying on guesses. We talk about spotting patterns before problems become expensive. By shifting the conversation from numbers to evidence and decisions, you lower anxiety and connect more directly to what people care about.

Easier said than done, of course. But if this resonates and you’d like to try it, here’s a cheat sheet we’ve started and are adding to as we go:

If nothing else, this prevents eyes glazing over when you mention the word “data” to someone who doesn’t work in data. :-)

What We’re Reading Right Now

In honor of this week’s theme, here are some articles where people are writing about data as an enabler to affect change in the tech industry, to lead better, to invest better, and to work better.

• and talk on about Substack Bestsellers lists and affecting change in Women Rising: Build the Flywheel. The Badge Follows.

• writes about whether the ‘rules of thumb’ for seasonality and stock market returns actually hold up The Calendar’s Seasonality Quiet Edge.

• writes about leadership and habits of winning teams in Progress Is Fuel: Why Perfectionist Leaders Never Win.

• talks about how to fix the process before jumping into a new tool in Process Before Platforms.

At some point during the analysis you stopped trying to understand the data and started rearranging it. Different date range. Another filter. The same report, broken down just one more way, just to see. Just in case.

That’s not a data problem. That’s a you-and-the-data problem. And more data is not going to fix it.

More data analysis feels productive. It looks like diligence. But past a certain point, it’s just procrastination via spreadsheet.

Why does this happen? Sometimes the stakes feel high, so you keep looking for a level of certainty that doesn’t exist. Sometimes you find one number you don’t understand and now you don’t trust any of them. And sometimes you’re hoping the data will make the decision for you, so you don’t have to.

None of this means that you're bad at data or bad at analysis. It means you're human, you have a real decision to make, and you're avoiding it in a way that feels productive.

Signs you’ve moved from analysis to avoidance

You’re running the same data again just to check. You’re reviewing fresh numbers every day. You’re adding filters and dimensions to reports you’ve already looked at multiple times.

But the biggest signal is simpler:

If you can’t answer the question, “What would change my mind right now?” you’re probably no longer gathering information. You’re avoiding a decision. One of the most common ways people avoid a decision is by convincing themselves that one more cut of the data will finally provide certainty.

Digging yourself into a hole with the data

One of the easiest ways to get stuck is to keep breaking the data into smaller and smaller pieces in search of an answer.

Most platforms, designed to work with datasets of all sizes, will happily calculate a conversion rate on 11 purchases and display it with exactly the same confidence as a number backed by 5,000 impressions.

Consider a small brand running ads for eight weeks, which seems long enough to feel like the data should be telling them something. So they start slicing it: age bracket, placement, device, day of week. By the time they’re done, they’re looking at 15 purchases spread across 24 segments. The platform shows them a conversion rate for every single one. These are confident-looking percentages. They have decimal points and everything!

None of those numbers mean a thing. Not because the math is wrong, but because there’s not enough signal there to support the conclusion.

Any tool that lets you filter data lets you drill deeper and deeper into smaller and smaller segments of that data. Sales data can be viewed by product, then by week, then by customer type until you’re looking at four transactions and calling it a trend.

Customer inquiry data can be viewed by source, then by month, then by service line until each cell contains single-digit counts and you’re making channel decisions based on them.

The problem is the same: the platform keeps showing you numbers regardless of whether those numbers are capable of supporting a meaningful conclusion.

The questions that actually help

When you’ve reached the point where more reports aren’t creating more clarity, the answer isn’t “just decide.” Instead, ask yourself these specific questions to get unstuck:

What would change my mind right now? If you can’t answer this clearly, more data won’t help. You’re not looking for information at this point - you’re looking for permission. The data can’t give you that.

Is the data actually capable of answering this question? Sometimes the answer is no. Not because you’ve analyzed it incorrectly, but because the information simply can’t support the conclusion you’re looking for. When that happens, the decision either needs to wait for better evidence or be made using judgment.

Is this decision reversible? Most small business decisions are easier to undo than they feel in the moment. You can cut advertising spending back next week. You can revisit the product feature next quarter. Before you treat a decision like a one-way door, name whether it actually is one. More often than not, it isn’t.

What’s the cost of waiting versus the cost of a wrong call? Delayed decisions have consequences too - not just money, but time, or momentum. Factor in what you give up by continuing to wait, not just what happens if you’re wrong.

Let’s get practical

Write down three things: what you know, what you don’t know, and what decision you’d make right now with what you have.

That exercise often reveals one of two things: either you already have enough information to move forward, or you discover the specific gap that’s keeping you stuck. Both are more useful than adding another filter to a report that’s already told you everything it can.

Sometimes the gap is real. More often, it’s discomfort dressed up as due diligence.

Data reduces uncertainty. It doesn’t eliminate it. At some point, the job shifts from gathering evidence to exercising judgment. And judgment only gets better when you use it.

Everyone should have a power suit. Or an outfit that makes you feel stronger.

Earlier in my career, I was frequently the youngest in the room. Often the only woman. Sometimes the only foreigner. Occasionally all three at once. So I learned to project confidence that I didn’t often feel.

I found my ‘boss look.’ I bought heels that made me taller. I practiced carrying myself like someone who had been in that room a hundred times before. I trained myself to stop clenching my hands under the table when the conversation was heated and to stop jiggling my foot when I was impatient. I even learned to drop my voice at the end of sentences, because when everything sounds like a question, people treat you like you’re asking one.

And all of that helped, but it only takes you so far. Because once you’re in the room, you have to contribute something. And what consistently helped wasn’t appearance, posture or even confidence. It was data.

Not fancy data. Not a PhD in statistics or a team of analysts. Just the discipline of knowing the numbers before I walked in the door - of doing my homework and being ready to use it.

Confidence helps, but here’s where data changes the game.

When you’re new, the data is your map.

Every new job, new industry, new team is a foreign country. The temptation is to spend your first weeks nodding along and trying not to look lost. Hoping someone will show you the way. Don’t.

Instead, go find the data. It’s almost always sitting right there, buried in old decks, reports, and dashboards that nobody has really looked at in months. Industry size and trends. Where your company fits and how it stacks against competitors. Company financials. Client revenue mix. Product usage. Read it like you’re studying for an exam because you are. The exam is every meeting you’ll walk into for the next six months.

When you know the data, you stop being the new person who doesn’t know anything. You become the new person who sees things others have stopped noticing. That’s not a small thing. That’s your first move.

When you’re the most junior or inexperienced in the room, questions are not enough.

Most people will tell you: ask good questions. And yes, thoughtful questions matter. But questions alone mark you as someone who is learning. If you want to be taken seriously, you need to know something.

Every team has a set of metrics they care about. Find out what they are. Understand where those numbers come from, what’s included and what isn’t, how they’ve moved over time, and what actually drives them. Read the reports. Talk to whoever owns the data. Stay current on news alerts for your clients, your industry, and your competitors - and when something significant happens, actually dig in.

Then, when you speak in that meeting, you’re not asking. You’re contributing. You’re the person who noticed the three-month trend before anyone else raised it. You’re the person who connected the external news to the internal number.

That is a completely different kind of presence in a room. And it is available to you right now, regardless of your title.

You don’t need permission to measure your own work.

You can build a track record before anyone asks you to. Most people don’t realize this until years in.

Whatever you’re responsible for - an email newsletter, a client program, a campaign, a process - start measuring it. Track how many people open the email and then click. Note what changed and when. Run a small experiment. Look at the results. Try something different. Do it again.

This creates a feedback loop, and it does two things simultaneously. You get better at your work, and you build evidence of impact that you can use in a performance review, in an interview, and in the meeting where you make a case for more resources or a bigger role.

You will have evidence of meaningful progress. Not vibes. Not effort. Evidence of results. That is gold in most career conversations.

The most powerful thing you can do is tell someone something they didn’t know. And then tell them what to do about it.

This is where data stops being a confidence tool and starts being a leadership tool.

Every time you’re in a room with someone more senior than you, or a client, or a decision-maker — that’s an opportunity. Not to perform. Not to impress. To add something real.

What does the data say? Prospect leads were down again last month. That’s the third month in a row. What does it mean? A competitor just made a major push on a new product. Here’s what that product does. Here’s the feature that matters and here’s the one that doesn’t. What do we do? Here’s what we should prioritize in our development queue and why

That’s leadership. The data makes it credible, and the insight and recommendation make people listen.

Don’t stop at the insight. Bring a recommendation, even if it might be wrong. Tell them what you think they should do with the information. This is how you go from being someone who reports facts to being someone who influences decisions - and you don’t need a title for that. You need preparation.

Share

One more thing - and this one’s for life.

None of this works if you can’t communicate it.

Learn to deliver information clearly to any audience: your boss, your team, a client, a room full of people who know more than you or less than you. Learn to make people care. Learn to answer the question they didn’t ask but needed to: why does this matter, and what should I do right now?

This is a lifelong practice worth the investment you make in it. I am still guided by solid data-driven messages that I heard 20 years ago because the delivery was that powerful.

Data without communication is just a spreadsheet. Data mixed with extraordinary communication is influence and impact. It’s something people remember about you long after the meeting ends.

Bring the data.

As an introvert, I was not naturally the most commanding voice in the room. But I learned that you don’t need to be the biggest voice.

You need to walk in knowing something. You need the homework done, the numbers understood, and the recommendation ready.

Because in life and career, there will be moments of uncertainty, moments that will determine where future paths open or close, moments where you feel exposed, moments where the stakes are real and the room is not on your side. Those moments determine a lot.

The heels make you taller and the suit more confident, but the data makes you formidable.

Leave a comment

Share

We Dig Data helps you leverage data better at work and practice leadership while you do it. If you want to lead with clarity, strengthen your judgment, and amplify your impact, you’re in the right place.

Subscribe now

First you had to figure out which dashboard tool had the right data. Then you found two report views that seemed to cover it - except they showed different numbers and used the same name for both. No explanation. No warning label. Just two “conversion” numbers, silently disagreeing.

So you clicked around trying to get your bearings. Which turned into reading a tooltip. Which turned into a help article and a YouTube video. Which turned into wondering whether you even have the right tool open. Somewhere in there you saw something interesting, but unrelated to your original question. You followed it because you might need it later. Suddenly it’s been an hour. You saw some things. You’re not sure what they mean. You definitely still don’t have your answer.

It’s the analytics version of scrolling social media. Same vague, slightly guilty feeling at the end.

Nobody teaches you how to walk into unfamiliar data and come out the other side with something useful. Most people think the hard part is learning the platform. It isn’t. It’s knowing how to orient yourself quickly and to figure out what matters and what doesn’t. This is that process.

Before I start…

Before I start digging into a new dashboard, I write down the question I’m actually trying to answer. That sounds simple, but it keeps me from wandering into every interesting metric or report the platform puts in front of me.

First, don’t touch anything.

Before I do anything, I take a few minutes to understand how the tool is organized. I look at the menus. Note how the interface is organized. Get a feel for where things live - settings, search, help - not just how to get to the reports. I ask myself basic orienting questions: what’s the difference between these sections? Where do I go if I need a definition? How do I change my settings?

This sounds obvious, but if you skip it, the danger is that you land on a default dashboard or report view and start reacting to the first numbers you see, but those aren’t usually the numbers that matter.

Here’s what that looks like in practice. When I open Google Analytics for We Dig Data’s website, the first thing I see on the “Home” screen is a chart with active users, event count, and real time data from the last 30 minutes. Below that, a map of where users came from. The prominent positioning feels like that information is important, but none of it may be relevant to my actual question. In fact, the metrics I actually need are tucked into the bottom right, half hidden. I’d miss them entirely if I started analyzing the data before orienting myself.

Turns out you can’t always see everything.

Before I can understand the data, I need to understand my permission levels. Am I an admin or a read-only user? Can I see all reports or only some? Can I export, or just view?

This matters because the answers shape what information you can validate, what gaps you may be missing, and how confident you should be that you’re seeing the complete picture.

So before you go further, note what you can and can’t access. If something is greyed out or locked, that tells you there is more to the picture than your current view. Even if your access is limited, the help materials are not. That’s often the fastest way to understand what you’re not seeing.

Recently, I was set up in a marketing tool as an “analyst,” which meant reporting-only access. I could see the left navigation, but I couldn’t click into most of it. That told me there was more to the workflow and reporting structure than my current view. That’s useful information.

Those words don’t mean what you think they mean

Once I know the boundaries of my access, I start scanning everything I can see: report names, metric labels, filters, definitions, tooltips, and any built-in documentation the platform provides. I’m not trying to answer my analysis question(s) yet. I’m trying to understand how this platform thinks about the business.

The terminology might feel familiar, but don’t make assumptions. Words like “users,” “sessions,” “customers,” and “revenue” sound standardized, but they really reflect decisions made when the platform was set up - product decisions, business rules, and platform assumptions. If you assume you know what a metric means just because you recognize the word, it will cost you later. Take the time to clarify those definitions.

I take notes as I go. I flag the things I can’t fully explain yet and come back to them later once I have more context. I save links to reports that seem relevant or confusing. I look at the dashboards - not to analyze the numbers yet - but to see the metrics and time periods and filters the platform offers.

Here’s why this matters. One platform’s “conversion” may include abandoned checkouts. Another may not. Two dashboards can use the exact same word and be measuring completely different things. That’s how you end up with two reports showing different numbers for the same metric.

A client has multiple marketing platforms. Three use the metric “sessions,” but each has a different way of measuring. I rely on help documentation to clarify the meanings, and then I note down definitions to refer to later.

What was the question again?

This is the most important step. I am now ready to begin analysis. But before I dig further, I anchor on the business goal or objective. What are we trying to change? That question helps me focus.

Not “What does the dashboard show?” That’s the wrong starting point for analysis.

The right questions are:

• “What decision are we trying to make?”

• “What outcome are we trying to improve?”

• “What problem are we trying to understand?”

That distinction matters more than it sounds. A dashboard that initially felt overwhelming becomes much more manageable the moment you realize you’re only looking for the pieces that influence one specific outcome. Everything else can wait.

I was recently working with a client whose goal was conversion. Specifically, understanding where people were dropping out of the sales funnel. That single objective immediately clarified which reports mattered, which metrics deserved scrutiny, and which sections of the platform could safely be ignored for now.

Without that anchor, it’s very easy to spend hours exploring data that never changes the decision. Sound familiar?

Subscribe now

Same metric, different tool, completely different number.

If you’re working across multiple tools (and most businesses are), the same metric will often appear in several places. But that doesn’t mean each platform is equally reliable for your specific question.

Each tool sees a different slice of the customer journey. Traffic in your web analytics platform is not the same as traffic in your email tool. Conversion in your e-commerce platform is not the same as conversion in your ad platform. Each one has blind spots, timing differences, and assumptions built into how it measures behavior.

Part of the job is deciding which platform should serve as the source of record for which metric and understanding why.

For that client concerned with conversion, we compared three platforms. Each measured a different part of the customer journey: browsing behavior, marketing engagement, and completed transactions. We ultimately chose one as the source of record for conversion because it had the most reliable count of completed purchases, and then we documented why we made that decision.

That last part matters. If you can’t explain why you trust one number over another, the conversation quickly turns into debating the numbers themselves instead of making decisions.

The report got you 80% there. Now what?

No platform sees the whole picture. There will almost always be questions the default reports can’t fully answer. Sometimes the gap is small. Sometimes it’s glaring. At that point, you usually have two choices: customize the reporting inside the platform or export the data and do the analysis yourself.

Sometimes I end up doing both. In Google Analytics, I might customize a report to provide some detail needed for deeper insight. But then I often need to extract the data into Excel for further analysis or reporting to my colleagues.

A surprising amount of useful analytics work is not advanced modeling. It’s identifying the gap between the business question and what the default dashboard happens to show, and then finding what’s missing.

Future you will thank present you for this.

The final step is the one that makes the work sustainable.

Once I’ve found the answer or built the view that surfaces it, I make the process of getting back there repeatable. That might mean saving a filtered view, bookmarking a customized report view, documenting what a metric means, or writing down how I got to the answer so I (or someone else) can recreate it next time.

This is how the hour compounds. The first session is always the hardest; you are orienting, mapping, and figuring out what to trust. But if you leave something behind for yourself, the next session starts where this one ended. You’re not rebuilding from scratch. You are building on it.

The goal isn’t a sophisticated analytics setup. It’s a simple, reliable path back to the answer - one you can follow yourself, without starting over every time.

Platforms change. The process doesn’t.

It doesn’t matter whether you’ve seen the tool before. What matters is knowing what you’re looking for, understanding the limits of what you’re seeing, and being willing to go get what’s missing.

That’s what this process gives you. Not a shortcut - the hour is still the hour. But at the end of it you’ll know what the data actually covers, which numbers you can trust, and you’ll have a view you can come back to without starting over. That’s not a small thing. Most people never get there because nobody gave them a map.

Now you have one.

Leave a comment

You’ve updated your resume, but there’s the uncomfortable thought: “What if my numbers aren’t impressive enough? Other candidates will have larger budgets, bigger teams, or have grown revenue faster.”

This isn’t a test where bigger is always better. Numbers get attention, but the explanation behind it is what makes a hiring manager believe you can do the job.

My experience as an interviewer

We are not recruiters or HR professionals. However, my co-author and I have 20+ years of experience building teams: brand new teams, tiger teams, cross-functional teams, and transforming existing teams.

Through this work, we have interviewed people for a wide range of professional roles and seniority levels, from interns to executives. We’ve listened to hundreds of people explain their accomplishments.

How people solved problems - what challenges they walked into, what tradeoffs they faced, and how they figured it out - is one of my favorite aspects of interviewing.

So I want to share what we’ve seen makes for a truly epic interview story.

Because while incorporating data into your resume is important, it’s the story behind that data that gets you hired.

Data on the resume vs. the story behind it

Many candidates worry that others have ‘better’ numbers. But as an interviewer, I don’t just look at the numbers.

For instance, a product manager who grew product revenue by 50% or 20% may be as interesting as one who grew it 300%. A marketer with 45% web traffic growth may be more appealing than one with 6000% social media growth. Similarly, a blogger who gained 10K subscribers in 6 months might be less of a fit than someone who built an engaged audience of 4K over 2 years.

Both candidates are impressive in these examples, but the stories behind their results will reveal very different journeys. The context in which they operated and the actions they took to achieve those outcomes are what truly distinguish them.

Setting the stage

If a number is on your resume, there is likely a good story behind it. And every good narrative needs the stage set.

As a potential employer, I want to hear the context around your numbers. Job search coaches call this step the “Situation” or “Context” or “Challenge.”

The most memorable interview answers will have tension. What needed to change? What problem were you facing? Was there risk? Pressure? Uncertainty? Was it:

• A new opportunity to be conquered, such as a new product launch or a new company that’s going to change how the market operates.

• A villain to fight, like a competitor stealing market share or a sudden market disruption.

• Desperate stakes to overcome, like financial or operational troubles or the cancellation of a major client or grant.

This set-up helps the interviewer quickly grasp the scope of the problem and your role. With smaller problems, I look for a story that showcases a variety of your skills. Larger scopes often involve teams, so I look for you to tie the results to your individual contributions.

With a compelling set up complete, you move onto the best part of the story.

Your hero story

The story behind the data is a tale where you are the hero. How do I know that? Because I’ve already seen the end - the data, the results, on your resume.

This should be the biggest part of your story and be focused on what you did. It features your unique contributions, judgement, and problem solving.

• “I suspected the problem was …… but then learned that was incorrect. So I analyzed ……, and found that we needed to do this instead.”

• “We had budget and time to pursue only option 1 or option 2, but not both. So I…..”

• “Overnight, our most lucrative line of business was made obsolete. I worked with ….. to build a plan to …..”

It is the story of how you faced the challenges in front of you and solved the problems you encountered. Many people can 3x their revenue, but how you achieved that is your differentiator.

The data on your resume are the quantified results. They are the ‘happily ever after’ or the resolution of your epic hero’s journey.

When you bring all three of these together, this becomes the story of your impact that your interviewer wants to hear.

Relevant interviewing frameworks

This approach maps to common frameworks (CAR - Circumstance/Action/Result and STAR - Situation/Task/Action/Result) recommended by job search coaches. They can feel mechanical, so use them to structure your hero story, but not as a rigid script. Focus on telling the story of your unique journey and actions.

Final thoughts

When preparing your resume and quantifying your accomplishments, spend the time to craft your hero story. If writing about yourself feels challenging, imagine a loved one or friend is telling this story about you, celebrating your achievements honestly and vividly.

From an interviewer’s perspective, I have thoroughly enjoyed hearing hundreds of these hero stories, which highlight human creativity, judgment, resilience, and smart risk-taking.

While a resume is like a sales brochure and the interview part of a sales process, the goal is never overselling. It’s about helping the interviewer understand your potential fit for the role and the organization. So be proud of your numbers and accomplishments, and confidently share the compelling story behind them.

Leave a comment

Subscribe now

I ask the dumb questions in meetings. I always have.

It used to make me self-conscious. Now I consider it one of the most useful things I do.

Here’s what we’ve learned about why nobody asks, what happens when someone finally does, and the exact words I use when that someone is me.

Nobody asks because it feels risky

Last week’s post on sneaky metrics got a comment that stuck with me. Ankita wrote: “The part that matters most is getting really concrete really fast…who owns the metric, what’s in, what’s out.” She’s right. But to get concrete, someone has to start the conversation. And that’s the part nobody talks about.

So why don’t people ask? It’s not because people don’t care. It’s because asking feels scary.

It feels like admitting you should already know, but don’t. It can sound like you’re challenging the person who owns the number. And when meetings move fast - nobody wants to be the one who slows everything down for a question that might have an obvious answer.

So people stay quiet. They go back to their desks and work from numbers they don’t fully understand, or they quietly calculate things their own way. And that’s how you end up with two people presenting different revenue figures in the same meeting.

You ask the “dumb” question, and then what…?

A few years ago, we were working to automate financial reporting for a subscription business - analyst reports, multi-year contracts, revenue recognized on release. The setup seemed clean. Then someone asked: “What do we do when a report is released late?”

The room got quiet.

It turned out late releases weren’t unusual. And the harder part was that there wasn’t one clean answer waiting to be unlocked.

The question didn’t just surface the answer. It surfaced the fact that nobody had one and an important discussion was needed.

This situation happens way more than people admit. And when it does, the path forward is usually the same.

First, bring in the person closest to the data - not the person with the biggest title. They’re the ones who have been quietly making the call.

Second, run scenarios out loud: “If this report releases on the 3rd instead of the last day of the month, which period does it land in?” Concrete examples cut through abstraction faster than any definition will, and will raise decisions that need to be made. Use the examples to clarify the boundaries. Perhaps 3 days late doesn’t change anything - but 7 days does.

Third, consider any downstream effects from your decision. If you decide late reports count in the next month, what happens to monthly revenue targets? Do they shift? Do commissions change? Does finance need to adjust forecasts?

Finally, write it down before you leave the room and communicate that decision. Even a Slack message counts! The goal isn’t a perfect policy document, but making sure that information doesn’t go back to living in one person’s head.

This is why I embrace asking those “dumb” questions. Because that question - the one that felt disruptive to ask - was the one that surfaced a problem everyone needed to resolve anyway. The report automation project didn’t create it. It just made it impossible to keep absorbing in silence.

What to actually say

The question itself doesn’t have to be brilliant. It just has to be asked. Here’s what I actually say in different situations. These are not scripts, but starting points.

When I don’t understand a number:

“Can you walk me through what’s included in this?”

Simple and non-threatening. It puts the burden on understanding, not on challenging. Nine times out of ten, the person explaining it discovers something in the telling.

When something feels off:

“I want to make sure I’m not missing something - this looks different from what I expected. Can we look at it together?”

“I might be missing something” does a lot of work. It’s honest, it’s humble, and it makes it about understanding rather than accusation. But you’re still asking.

When you suspect two people are measuring differently:

“Before we go further - are we calculating this the same way? I want to make sure we’re comparing apples to apples.”

This one is especially useful when two numbers don’t match and everyone’s being polite about it. Name it directly. It’s almost always the issue.

When you’re presenting and want to get ahead of confusion:

“Quick note on this number before we dive in. Here’s exactly what’s included and what’s not.”

If you define it first, nobody has to ask. This one takes 20 seconds and saves 10 minutes.

In all of these examples, the common thread isn’t the exact phrasing, but the framing. Curiosity, not accusation. You’re not challenging anyone. You’re making sure everyone’s working from the same understanding.

You don’t have to ask it in the room

Not every question needs to be asked in the middle of a big meeting. If you’re earlier in your career, or just not in a position to break the flow, you still have options.

Listen closely. Take notes. Then follow up with someone close to the number. That’s often the analyst who built it, or the person pulling the report each week.

And use the same language:

“Can you walk me through what’s included in this?”
“I want to make sure I’m interpreting this right…”

These conversations are often easier one-on-one. People will go deeper. You’ll get a clearer answer. And if something important comes out of it, you can bring it back to the group:

“Quick follow-up on that number from earlier - here’s how it’s actually defined…”

You’re still creating clarity. You’re just doing it in a way that fits the moment.

Want more? This article by Gustavo Razzetti has great ways to “unblock” conversations with reframing - not fighting.

Share

Asking “dumb” questions is a superpower

When one person asks, it gives everyone else permission.

Someone senior might assume everyone else already knows the answer. But from the junior person who is afraid to look inexperienced to the new team member who doesn’t want to slow things down or even the long-timer who has been pulling that same metric for years - they all need someone to go first.

The whole dynamic shifts when a group sees that clarifying a definition isn’t a challenge, it’s just good practice. Meetings will (eventually) get faster, not slower. Decisions get cleaner. People stop quietly disagreeing in their heads and start actually resolving it out loud. Real conversations can happen.

And the people who were already doing this? They tend to be the ones others describe as “easy to work with” or “really sharp on the data.” It’s not that they know more. It’s that they’re not pretending to know things they don’t.

Go on - ask those “dumb” questions.

I still ask the dumb questions. I probably always will.

Sometimes I even ask when I think I already know the answer, because I’ve seen too many times what happens when nobody does. The number that everyone nodded at turns out to mean three different things. The decision gets made on a metric nobody fully understands. The rework shows up two months later.

Asking isn’t the dumb thing. Staying quiet is.

Share

Subscribe now

Related articles:

Most data mistakes don’t look like mistakes. They look like smart, reasonable decisions—but based on numbers that weren’t fully understood.

Teams often think they’re aligned because they’re using the same words:

“Revenue.” “Users.” “Customers.”

But they’re not.

They’re working from different definitions and no one realizes it until something breaks. Then it shows up as rework, wasted time, and wrong turns.

This is a problem of false alignment. It’s common, it’s frustrating, and it’s almost never talked about directly.

Let’s change that.

Here are 7 common offenders that wreak havoc on well-meaning teams, and what you can do about it.

Share

The Sneaky Seven: Metrics that always need a definition

#7: Leads

“Leads” (or prospects) sounds simple, but can have very different meanings across teams. Marketing might count a whitepaper download. Sales may only count someone who requests a meeting.

Depending on the system used to capture them, leads coming from different channels (sales vs. web vs. social, etc.) aren’t always captured or categorized consistently.

Now layer in intent and timing. Are all leads equal? Probably not. And how long is someone considered a lead if they don’t convert into a sale - days, weeks, months?

#6: Traffic

“Traffic” can mean foot traffic at a store or event, or digital activity online. And within each, there are multiple ways to measure it.

At an industry event, traffic could mean total attendees or only the people who stopped at your booth. On a website, it could be page views, sessions, engaged sessions, users, or unique users. Each of these tells a different story and has a different context.

#5: New Product Revenue

“New product revenue” is often used to measure innovation and growth, but there’s usually a lot of debate about what counts as “new.” Timing might be limited to products launched just this year, or, if a product has a long sales cycle, it might include the first few years of a product’s lifecycle.

The type of product also needs definition. Teams differ in whether they count only new standalone or if major new features for existing products are included as well.

Don’t forget to clarify revenue. Some teams use projections. Others use actual revenue. Others use sales booked.

#4: Users and Usage

“Users” and “usage” are highly dependent on your product and distribution model, especially in businesses that deliver services online like banking, software, streaming, or gaming.

A user may be anyone with a login or only someone that is active. But what counts as ‘active’ also varies and needs definition. Perhaps it is someone who accessed the system in the past 30 days, or who took a specific action, or spent a minimum amount of time.

#3: Customers

Counting customers gets surprisingly complicated, and definitions can vary between teams or product lines within the same organization.

In B2B, the first question is usually whether the number is counting companies, contracts, or individual users. One company might have multiple contracts and thousands of users.

In both B2C and B2B, the buyer and the end user may not be the same person - like a team signing the contract while another uses the product, or even a parent buying a toy for their child. This is also an important distinction.

Then there is timing and services. A customer who purchased last year, but not this year, may not be counted by one team, but is included by another. How free subscribers or limited trial / promotional customers are counted may also be a discrepancy between teams.

#2: Retention

Retention (or renewal rate) is the percentage of customers, or revenue, you keep over a period of time.

This metric gets muddy quickly and needs clarification on whether it’s measuring:

• customer retention or revenue retention

• a specific cohort (”customers who signed up in January”) or the whole customer base

• upsells, new customers, or pricing changes

Depending on what is included, retention can exceed 100% and mask churn rates, or not. For this reason, the team might decide for multiple retention metrics based on their objectives.**

#1: Revenue

“Revenue is revenue”… until it isn’t.

Sales vs. revenue. Recognized vs. booked. Gross vs. net.

Revenue is one of the most misunderstood numbers because a few key distinctions get blurred.

Sales and revenue are often used interchangeably, but they’re not the same. Sales reflect what was sold in a given period. Revenue reflects what the company is allowed to recognize as earned.

When looking at revenue, you need to understand how it is “earned” or “recognized.” Depending on the product or service, revenue might be counted when a product ships, when it’s delivered, or as it’s used. Or it might follow a defined schedule - so a 12-month subscription sold today might have revenue that is split over 12 months.

And what counts as revenue isn’t always obvious either. In marketplace models, like Etsy or AirBnB, $100K in transactions might translate to $5K in revenue from fees or $105K, depending on how it’s defined.

Why are these metrics so “sneaky”?

With so much variability, you’d think that we’d always want to clarify the definitions. But we don’t.

Familiar words create a false sense of clarity.

Revenue. Users. Customers.

They sound obvious. So teams assume alignment without confirming what’s actually being measured.

And even when something feels off, people often don’t ask. They feel like they should already know. Or they don’t want to slow the meeting down. Or it’s uncomfortable to challenge a number someone else owns.

So instead, people stay quiet and move on.

When you combine:

• One word that can mean many different things

• A tendency not to pause and clarify

You get false alignment. Nothing breaks right away. It shows up later as confusion, rework, wasted time, and mediocre to poor decisions.

How do you get clarity?

Start here: ask the question. What is included in this metric? How is it defined? Just ask.

Yes, it might feel uncomfortable. But chances are, someone else is wondering the exact same thing and once you say it out loud, you’ll realize the room wasn’t aligned after all.

And when the conversation gets fuzzy, use this playbook:

1. See it for yourself. Go to the source. If it’s a lead, walk through the website or flow. What actually happens when it is captured?

2. Run a quick scenario. Get clear on yes/no cases. “If I download the e-book, am I a lead? What if I request a demo? What if I chat with the bot?”

3. Clarify what’s included. “Does this lead number include only website activity? Or also social, CRM, and sales team inputs?”

4. Tie it back to the report. “So 108 leads in April means 108 people completed web forms or chats, and this excludes phone calls and sales-sourced leads. Correct?”

Your goal: understand it well enough to explain it to someone else simply.

And if you’re being measured on it? Don’t leave the conversation until you know exactly how your actions move that number.

Thanks for reading. Do you have another “sneaky” metric we should add? We’d love to hear it!

Leave a comment

Share

**If you want to dig into more on retention, this article from Churnzero is one of the more helpful explanations we’ve seen. We have no affiliation, we just appreciate their clear explanation of retention and when to use it.

Bonus Reading: Other sneaky metrics (but for different reasons)

Percentages add another layer of confusion because they depend on multiple underlying definitions, especially when it comes to conversion rates and trends. We’ve covered these in more detail in other articles. You can read more below.

We have a lot of new subscribers here this week. Welcome! We are glad you are here. This is a longer post than normal because we detail how we are extracting our Substack data for analysis, where we use AI and where we don’t (and why).

For those of you not on Substack, while the example is focused on a specific platform, the general ideas and findings are similar to what we see when looking at data coming from other platforms like Google Analytics, Shopify, etc. We are in learning mode, so if you have any suggestions on tools or things that worked well, we’d love to hear them!

- Rachel

Leveraging data to accelerate results. That’s what we help managers and entrepreneurs do - by using a disciplined approach defining objectives, selecting supporting metrics, evaluating data inputs, and making sense of the outputs. As we build our company, we turn that tough-love advice on ourselves, especially when it comes to our Substack newsletter.

So this week, we share how we’re handling Substack performance data. While it’s a workable model specific for our Substack goals, it is also adaptable for other creators’ goals.

Initially, we used Substack’s native dashboards. While they’re helpful, we soon found that they didn’t fully answer the questions we care about. So we built a more hands-on process, focused on understanding what drives success for us.

In this post, we will:

• Explain how we use Substack data and where we ran into limits.

• Argue why you should look at the data itself and why AI alone is not enough.

• Detail the steps we followed to unlock our Substack data and what we learned.

Substack metrics we care about (right now)

We identified early on what we were not trying to do: we weren’t focused on paid subscribers or trying to maximize every possible metric.

We focused on building the right audience for us, and understanding what content was resonating. That’s what supports our larger goal, which is helping managers and entrepreneurs build a data feedback loop into their everyday work to accelerate their success.

Along the way, we refined our core metrics to a targeted set:

• Relevant audience growth: subscribers and followers, across Substack and LinkedIn.

• Content engagement, such as shares, restacks, and comments

• Community building: interactions, connections and participation

But all of these metrics are not easily viewed over time and analyzed in the Substack dashboards.

How we use these metrics

We are leveraging the data in two key ways:

1. Ongoing monitoring. We review our target metrics regularly - usually weekly, some monthly - alongside what we actually did in that time period.

2. Analysis. We also wanted to compare different types of posts, notes and other activities. But we needed the data to support looking for patterns between effort and response.

Getting closer to the data

To achieve this, dashboard summaries or just feeding it into AI for analysis were not enough. We needed access to the underlying data so we could explore it directly and see what was being captured (and what wasn’t).

We wanted to build our own understanding of what is happening rather than rely on the conclusions coming from dashboards and AI.

These were good instincts because the dashboards didn’t tell the whole story, and the AI made assumptions and had incomplete conclusions.

So we set up a process and supporting system to extract, store, and explore our Substack data outside the platform.

Here’s how we did it - the quick version

Here’s the overview of what we did. If you want more detail, we have you covered. There is a step-by-step guide on how to do it yourself at the end of this post.

Extract the data
We use StackContacts (from ) to pull Substack data, including subscribers, posts, and engagement, into a local database. This saves us from building API integrations ourselves and gives us access to more than what’s visible in the Substack dashboards. Once configured, the data syncs from Substack to a database, and can be automated to run regularly.

Store the data
The data is stored in a local DuckDB database. That means we own it and can query it directly. We aren’t dependent on a platform interface, and we can preserve our history.

Query the data
We created a handful of SQL queries to pull the data related to our key Substack metrics, such as audience growth and content engagement. As we learn more about the data, we refine the queries.

Connect the data to Excel
Our queries are embedded in an Excel file that we refresh weekly after syncing the data via StackContacts. We used an ODBC connection to directly tap the database from inside Excel.

Use the data to monitor progress and build a feedback loop
The Excel file gives us a consistent view of our key metrics over time, alongside what we actually did that week. It supports a simple, repeatable, review process with familiar tools and a critical subset of our data. Now that this is set up, it takes us only a minute to refresh the data.

Explore the data using AI
Of course, we’re also experimenting with AI tools to analyze the data. This can be helpful for generating queries and surfacing patterns - but only once we have a solid understanding of the underlying data. In our case, the Claude desktop app is accessing the DuckDB database via Model Context Protocol (MCP). This configuration is part of StackContact’s installation process.

Overall, this setup isn’t particularly complex once broken down into its parts, and it gives us something we didn’t have before: direct access to our own data, and the ability to shape how we measure and interpret it.

Want more details? A deeper dive is at the end of this article.

Why we collect more than we need right now

Even though we focus on a small set of metrics, we’re intentionally collecting more data than we actively use. Our early-stage history is valuable - and we don’t know yet what we might want later. Patterns that don’t matter now might matter at scale. Older behavior might become useful for comparison. Additionally, platform definitions can change; we’ve already seen shifts in how metrics like open rates are reported on Substack.

Keeping more complete data now gives us flexibility later.

Why the data was harder than expected

Once we had the data, we ran into something we often experience with clients: the Substack data itself was not cleanly organized.

• There were many tables, with many fields, but no data dictionary with definitions.

• Some fields looked similar, but meant different things.

• Other fields were empty or inconsistently populated.

• Mapping fields back to actual Substack activity took work, and several iterations.

In other words, the data didn’t immediately tell a clear story “out of the box.” We had to look at the actual data to get familiar with it - what the fields meant, which similar sounding field was the right one, how tables related to each other, and what was actually reliable.

For example, we track subscribers and followers weekly. We have been doing this manually, and wanted to pull richer data from Substack in a more automated way. So we developed a SQL query via the AI and produced a tidy data output - except for one problem. It said our followers went back to 2021, which isn’t possible. The issue? The field used in the query was the date our followers created their Substack profiles, not the date they began following us.

These structural issues and lack of data definitions are important to know when considering how you apply AI to analyzing your data.

Where AI helped and where it didn’t

Part of our setup allows AI tools to query and analyze the data. It would be tempting to leave it to AI to learn the structure and quirks of the data itself, but in practice, this can (and did!) backfire.

The detailed data is where you learn what your dashboard really summarizes and when to question the overly confident responses AI gives you.

The first question we tested with the AI was subscriber count. The resulting total subscribers was correct, but all free subscribers were labeled as “unsubscribed.” That was a fundamental misunderstanding of the data - and if that is wrong, everything built on top of it is wrong.

We had given the AI little context or instruction, and it was easy enough to prompt for correction. But even after iterating and guiding the AI through the database, there were still issues.

But if you operate with caution, the AI does bring real value. It helped:

• Explore the data structure: it reliably identified which tables could be safely ignored for our purposes, and teased out relationships much faster than we could have. It was also significantly faster in working through the many fields looking for relevant data. Even when there were errors, the second review generally picked up the right field.

• Generate queries: You don’t really need to know SQL (though a little bit always helps so you know what your query is doing). Rapid development and editing of queries saved hours. We know our strengths, and SQL syntax is not one of them.

• Quickly surface key insights: Simple quick analysis, such as top performing posts by a variety of measures, tended to be reliable. We also tried out topical analysis, having the AI classify our posts and break down performance by theme. The groupings were very close to how we think about our content, which gave us confidence in the approach. More importantly, it highlighted both areas of strength and gaps where we may want to develop new content.

Going forward, given that we now better understand the detailed data, we will continue to use that knowledge to prompt AI to generate additional queries as well as be an analysis partner. We may also use it to run data quality checks when we update and refresh the data.

Summary: what this gives us

This process gives us a more useful set of numbers and a way to work with our data more deliberately.

We’ve chosen a small set of metrics to guide decisions, while keeping a broader record so we can learn over time. We’ve built a simple process we can repeat, refine, and actually use. And we’ve tested where AI can help - and where it can quietly lead us in the wrong direction if we don’t understand the data ourselves.

This is what it looks like, in practice, to build a data feedback loop: define what matters, get close to the data, and use it to inform what you do next.

If you’re interested in how this is set up in more detail, we’ve outlined the technical setup below.

Step-by-step guide: How to do this yourself

We’ll walk step-by-step through the setup. Note that we’re operating on PCs, not Macs. So while you can do all of this on a Mac, it’s going to look different.

In addition, the install manual for StackContacts is extensive, and we will not repeat all of that detail - but it may help you to see some of the setup screens and understand where things went right and wrong for us.

Step 1: Extract your data

1. Purchase StackContacts.

Obtain ’s StackContacts. Note that there are a number of editions to fit your environment: we have just one publication (Practical Data Foundations) and do not need the Gumroad or Kit integrations, so we bought the Hobbyist edition.

Note, this part of the process took us a little while, so set aside a few hours (and possibly more) to do this.

2. Review the install manual and complete prerequisite installations.

Read the install manual! It’s long. It’s dense. But very helpful. There are prerequisites before you can install StackContacts itself, including Node.js, npm, and the MCPB CLI tool. You need to know how to open a command prompt or PowerShell, and how to run those as an administrator. (Don’t know how? Do a search - AI results and lots of helpful shortcuts will pop up). In addition, you’ll need to install either the Claude desktop app or Cursor AI app (we used Claude).

3. Install StackContacts

The install manual will direct you to the product page for the latest installer. Run the installer, follow the prompts and then launch StackContacts. Be patient - it took a couple of minutes for our initial launch of the software.

If you run into difficulty: in our case, the Visual Studio install was accidentally interrupted at some point, which led to failures later in the install process. We went back and installed Visual Studio again, manually. Worst case? Uninstall, then start over.

4. Setup StackContacts with publication and cookie info

Follow the install guide to set up your publication. First, you’ll need to tell StackContacts how to communicate with your Substack publication. Using that login, a cookie is pulled from a specific Substack page, establishing the connection between StackContacts and your Substack stats.

When you click Login, the app will give you the following window:

The automated process described in the manual and what the app defaults to did not work for us, producing login errors. We had to manually pull the cookie values. It’s described in the manual, but here’s what it looks like in Chrome.

5. Sync your data

Once login was set up, the sync process itself was smooth. We’re pulling every possible metric we can from Substack. Our syncs are taking about 30 minutes, so be aware that if you have a lot of data or multiple sites, this may take a while. Our install is running on one local PC; the app is not kept running all the time so we’re not using the automatic syncing (it will fire only when the app is open and your PC is “awake”), but you can set up a date and time for an automatic sync.

Tip: When you sync, you are pulling all available data. What you had in the database before is overwritten - you’re not just appending data that’s new since last time. This has implications; notably that if you want to preserve history as it was, you’ll need to periodically back up your database. For example, say Substack stops making data on DM threads available. If you allow the database to be overwritten, you will lose that particular historical data.

6. Finish AI integrations

From here, you finalize the install by configuring either Claude or Cursor AI to enable AI-powered insights atop the data. For Claude, this meant creating and enabling the appropriate extensions. This process was smooth, aligning with the instructions in the manual.

A step we recommend: once you have completed the actual install, open Claude and instruct it how to find the database. Our initial prompts (e.g. show me my last 10 subscribers) were not successful because Claude had no idea what we were talking about. StackContacts is a “deferred” tool - meaning it didn’t load automatically. Claude could only find it after being told the name, triggering a tool_search to load it. So use a prompt like: “Use tool_search to find any connected database tools, then connect and show me what’s available.”

Step 2: Store your data

As part of the StackContacts setup, you will also set up DuckDB, an open-source SQL database. When Substack data is synced down to your local computer, this is where it will be piped. The database is not proprietary to StackContacts. This is positive because we can’t get locked out of our data even if we uninstall StackContacts. We own it, we manage it, we back it up. And even if you’re a large organization or scaling up, you can operate nicely for quite a while with DuckDB, whether locally or in the cloud.

StackContacts’ data screen gives you quick access to database information and tools, including backup and restore of your database, a summary of records and tables, and a list of all tables from your publication.

Take note of the Database Location (circled) - you’ll need that if you choose to connect to it from Excel.

Want to see your data up close and personal?

Download a tool to browse it. We are using DBeaver - a free, open-source tool for database management. From here you can browse through the database structure, view the actual data, write and run queries and export data.

Step 3: Query your data

One of the things we learned in testing the AI integration was that the data structure and definitions were sufficiently complex that Claude could not do analysis without more significant familiarity on our part with the data to instruct it well. We knew we wanted the underlying data, but those experiments with Claude made it clear that we needed it.

So the next step was to set up standard queries for metrics we wanted to follow regularly. And just like we wanted to avoid writing any API calls, we also wanted to avoid writing the SQL queries - this author is great at defining the logic, but self-admittedly, terrible at syntax. This was a perfect use of Claude.

We started with a set of 6 queries that addressed our key needs: post and notes performance, top content by a variety of measures (engagement, subscriptions, shares), subscription activity over time and by source and a rolling summary of all engagement. (Interested in the queries? Send us a DM). We saved the queries in DuckDB (where they were originally tested), documented them in a text file, and began to build an Excel file that could be refreshed weekly after syncing the data.

(Wondering if you can do this with Google Sheets? There are ways, but they’re clunky - the big constraint is that your DuckDB database is local. If you move it to the cloud the path is easier).

Some tips:

• StackContacts and DBeaver want exclusive access to the database while they’re running. So if you would like to run both at the same time, you will need to have DBeaver work in read-only mode.

• Have one place where you keep your master copy of your SQL queries. You can modify them in DuckDB, in text, and in Excel - and it’s easy to lose track of which is the master. Just choose one, and remember to always update that documentation.

Because we are still refining our queries, we test them in DBeaver, keep a backup in a master text file and copy them into Excel. You’ll see how that works below.

Step 4: Connect the data to Excel

We have long used Excel to manipulate and analyze data. In order to be able to run queries from inside Excel, we had to do a couple of one-time setup tasks that enable the connection:

1. Download and install the DuckDB ODBC driver from duckdb.org (free)

2. Configure the ODBC connection on my computer.

To set up the ODBC connection, click on the Windows key on your keyboard or click the Windows key + S to search. Type in odbc and select ODBC Data Sources (64-bit)

• Click on the SystemDNS, then click Add.

• Choose the DuckDB Driver, then click Finish.

• Type in a Data Source name and the path to your database

Now you’re ready to make the final link between Excel and your data.

3. Connecting to your database from Excel

Open an Excel spreadsheet. From the Data tab, click Get Data | From other sources | From ODBC and select the StackContacts data source.

When you select StackContacts from this list, you can either click on Advanced and paste in a query. Or click OK to navigate the tables, preview and load the data into a worksheet.

Once you establish the connection, there are a number of different ways to explore the data in Excel. Because we had already written our SQL queries, we went to a blank worksheet, connected to the database (following the steps above), pasted in a query and loaded the data in the tab. We did those steps for 6 metrics-focused queries plus one to remind us when the data had been synced.

You can view, edit and refresh all your queries by clicking Queries & Connections from the Data tab.

This queries and connections view is really useful on its own - by right clicking on any item, you have a number of actions you can perform - making Excel a suitable place to explore the data without something like DBeaver as an exploratory tool.

Step 5: Use the data to monitor progress and build a feedback loop

We use this Excel file to focus our discussions when we meet to develop a content calendar, refine our messaging, and decide what we want to test next - whether that’s new topics, formats, or ways of engaging.

While we sync our data weekly, we don’t review every metric on that cadence. Instead, we use the data when it’s most useful. Sometimes that’s weekly, sometimes monthly or higher when patterns take longer to emerge.

What matters is the data feedback loop:

• We look at what we did

• We look at how it performed

• We decide what to adjust

Then we repeat.

Having the data at this level of detail makes that possible. We can go back and isolate the impact of a specific post or outreach effort, compare across time, and test whether changes in what we write or how we share it actually make a difference.

When volumes are small, we aggregate to monthly or even quarterly views to get a clearer signal. Over time, this helps us move from reacting to individual results to recognizing patterns, and using those patterns to guide what we do next.

Step 6: Explore the data using AI

Earlier we described some pros and cons we experienced working with Claude. How you use AI will depend on your objectives, but the real value shows up once you understand your data well enough to ask better questions.

Here are a few ways we’ve used AI to extend beyond hands-on analysis:

Content strategy analysis

AI can help you step back and look at your content more systematically:

• Topic and theme analysis
  Have the AI classify your posts and notes into topics, then compare performance across those themes. Review and refine the categories - s a starting point, not a finished taxonomy.

• Format and channel performance
  Look at how format (short vs. long, structured vs. narrative) and channel (posts vs. notes) influence engagement. Different types of content often perform differently in each format.

• Timing and mix
  Identify periods of stronger performance and examine what you were publishing at the time - topics, formats, and frequency.

The goal here isn’t just to find “what works,” but to understand why it works and where you might want to experiment next.

Audience and subscriber analysis

AI is also useful for understanding how your audience is behaving over time:

• Engagement patterns
  Identify which subscribers are consistently active vs. going quiet, and track how engagement changes over time.

• Growth and re-engagement signals
  Look for moments where activity spikes. Did a particular post or note correlate with new subscribers? Who might need re-engagement?

Perfect attribution is less important than spotting directional signals you can act on.

Tips for getting the best out of an AI for analyzing data

Tell the AI what you already know about your data. As we saw when we experimented with Claude immediately after setting up the StackContacts integration - Claude will make reasonable assumptions, but we need to know the quirks of our own data. Surface those to the AI early and the analysis will immediately get sharper. That can include things like:

• How key fields are defined (e.g., free vs. paid subscribers)

• Which fields or tables to trust or ignore

• How you define engagement or success

• Any transformations you’re applying (e.g., weekly/monthly aggregation)

• The specific question you’re trying to answer

Ask the AI to check the data structure before analyzing it. Asking the AI to look at the columns and a sample of rows first. A prompt like “before you analyze, show me what’s in this table and confirm what each key column means” saves a lot of back-and-forth.

Be specific about what question you’re trying to answer. “Analyze my notes” is not a useful prompt for an AI. Questions such as “Which note topics get the most reactions, and does a short vs. long format change that?” provides a clear target.

Correct the AI when something doesn’t look right. For example, an initial topic analysis of notes was off because the AI was mixing original notes with replies and restacks. Flagging that immediately led to a much more accurate analysis.

We were learning while we were building, and we continue to refine our queries and our analysis. We’ve tried to capture our steps - and our missteps - here. If you have tips and ideas on how to do it differently, or if something isn’t clear, we would love to hear from you. Please comment or send us a message. We reply to them all.

Leave a comment

When a workflow feels clunky, it’s tempting to start looking for new tools - a slick new platform, a better tool, AI, the software equivalent of a fresh start.

But the real fix usually starts somewhere else: understanding what’s actually happening beneath the surface. If you skip that step, you’re likely to treat the symptom, not the cause.

It’s like replacing all your light fixtures when the problem is faulty wiring. Flashy fix, same old flaw.

Before you overhaul anything, pause. Assess what’s actually happening. Understand what you already have and what it really needs.

Step 1: Get clear on the goal

“The process is inefficient!”
“This platform is ancient - it’s time for an upgrade!”

Valid frustrations. But not goals.

A good goal gives you direction. It’s something clear - a specific, actionable outcome - that you can work toward and use as a gauge for whether a change is having an impact.

For example:

“We need to shorten the time between content submission and publishing.”
“We want to eliminate manual data errors.”
“With AI’s capabilities, let’s rethink how we deliver client value on this part of our service.”

Before making any changes, ask: What are we really trying to accomplish?
Speed? Accuracy? Better value? Less frustration?

If no one can give you a clear answer, your job might be to help shape that goal. You can’t fix a process - or choose a tool - if you don’t know what problem you’re solving.

Step 2: Map the people and the process

People are great at describing their pain points. The hard part is figuring out what is actually causing them. That’s where mapping helps.

Why mapping matters:

• It reveals disconnects and redundancies.

• It surfaces silent pain points.

• It gives you clarity - and credibility.

In siloed organizations, one team may offer a detailed view of a single step, but not how that step fits into the broader picture. But without the full context, you can end up solving the wrong problem entirely.

Tips for documenting workflows

If you’re lucky, your teams already have documentation. If not, or if it’s outdated, roll up your sleeves!

Try this:

• Shadow people as they perform common tasks.

• Make it clear you’re observing, not evaluating.

• Ask: “Who does this task? What happens next? Who touches what system, and when?”

• Diagram hand-offs. Make it visual. Review with the people who do the work.

Accuracy matters! These diagrams are not just for clarity. They become the foundation for tool evaluations or change management later on.

(Pro tip: Workflow diagrams are a great way to bring objectivity when operating in a low-trust or “finger-pointing” environment.)

Step 3: Analyze and quantify

Now that you have goals and workflows, dig into what you’ve learned.

Ask:

• Where does time pool up?

• Are there steps we can skip or streamline?

• Where do delays or mistakes happen most?

• Do certain approvals always slow things down?

Look for patterns:

• Bottlenecks

• Points of friction

• Risky or error-prone hand-offs

• Bright spots that could scale or add significant value

Focus on moments in the workflow where a small change could have a big impact. These are your biggest potential opportunities for automation.

Step 4: Pinpoint needs, priorities, and risks

With real data in hand, start identifying:

• What needs to change?

• What’s a process issue vs. a tool issue?

• What are the benefits and risks of each path?

With this information, you can evaluate your real options.

Example:
A research team pushed for a new data platform to fix persistent errors. But when they mapped the workflow, the real issue turned out to be inconsistent formatting in client-submitted spreadsheets. Research analysts and data operations were using different templates.

The solution? Align the templates. The errors disappeared. No new system required.

Takeaway: Sometimes the fix is smaller, cheaper, and right under your nose.

The real cost-benefit calculation

Automation projects require money, time, and people. But most teams only ask one question:

“Is the benefit worth the cost to build?”

That’s too simple.

When you evaluate automation, you need the full picture:

a) Build cost (what everyone sees)

• Development time

• Tools / platforms

• Internal or external resources

b) Implementation cost (what gets missed)

• Training your team or clients

• Rolling out new workflows

• Supporting adoption across the organization

c) Opportunity cost (what no one talks about)

• What are your people not doing while this is happening?

  For example, a sales team learning a new forecasting automation tools isn’t meeting prospects. That’s pipeline you’re trading for process.

Don’t get us wrong - automation can absolutely drive value. But only when you weigh it against everything it displaces.

Too often, teams underestimate effort, overestimate speed to value, and ignore the hidden costs of change.

A better question to ask.

Instead of:

“Should we automate this?”

Ask:

“Is this the highest-value investment, right now?”

Step 5: Get ready to recommend and present

By now, you have done something powerful: not only have you identified a problem, but you have built shared understanding around it.

When you present:

• Don’t go for a dramatic reveal. Show how you arrived at your recommendations.

• Share your findings to test understanding.

• Walk through assumptions and risks.

• Invite feedback. Clarify tradeoffs. Be honest about what is still uncertain.

Frame your presentation as a shared discovery, not a pitch.

What makes you invaluable

You don’t need to be an AI or systems expert to lead this kind of change. Curiosity, persistence, and thoughtful observation go a long way.

The hard part is taking the time to understand what’s really happening. It’s the step many teams skip, yet makes the difference between a failed automation effort and a lasting one.

This kind of attention doesn’t just improve processes. It builds lasting value, clarity, and alignment. And that’s what makes your work truly invaluable.

Leave a comment

More Reading: The “AI at Work” Series

• The Human Factor

• Frame the Problem

• Why Data Inputs Matter

• When to Trust, Adapt, or Toss AI Outputs

• Translating AI Results into Decision and Action

• Using AI in a Lean Marketing Machine

There are moments in almost every career where you realize you’re a little out of your league. You’re expected to have an answer, but you’re not entirely sure what’s actually going on.

Maybe it’s your first role and you want to contribute something meaningful. Or you’re stepping into a new team or business and trying to get your bearings. Or you’re running your own operation and every decision feels high stakes.

Data should help in these moments, providing clarity and direction.

But for many people, it does the opposite. The dashboards look polished and the reports look definitive. Yet there’s a worry: What am I looking at? What does this number represent? What if I’m wrong?

So we rely on analysts. We lean on tools. We increasingly turn to AI.

All of these help, but they don’t solve the core problem. If you’ve only seen the final numbers - and not what they’re built from - it’s hard to feel confident acting on them.

What we’ve found is simple: confidence doesn’t come from better tools or delegating. It comes from spending a little time with the data itself looking at real rows, real customers, real events.

In other words, you have to touch the data.

This feels counterintuitive. With all the technology available, it seems like we should be able to skip this step. But you can’t outsource that familiarity. A polished dashboard or AI output can look convincing, but if you haven’t seen what it’s built on, it’s hard to fully trust or interpret it.

We wanted to understand why this step matters so much. So we looked at how people actually learn. It turns out there are three well-established principles that explain what’s happening.

Share

Why touching the data works: three learning principles

1. People learn through concrete examples, not abstractions

Data is abstract. Summaries and dashboards make it even more so. But learning science shows that people understand concepts better when they start with concrete examples and then move to abstraction - not the other way around.

A marketing professor we know teaches a well-known behavioral economics concept about how people overvalue what they own. For years she explained it through a lecture. Students were skeptical — it just didn’t ring true. So she started running a simple experiment: she gives half the class a Kit Kat, asks them how much they’d sell it for, and asks the other half how much they’d pay. Almost every time, the Kit Kat owners demand more than buyers are willing to pay. The concept sticks because students experience it firsthand.

We are wired to learn this way. We remember what we can see, experience, and interact with.

Looking at the data itself works the same way. When you’re looking at actual customers, transactions, and events, you see the building blocks before it gets rolled up into a summary. Once you’ve seen that, the dashboards start making a lot more sense.

2. Better judgment starts with understanding what’s underneath

Research on expertise shows that people who understand how something is constructed make far better judgments than those who only see the final output. Experts organize knowledge around core concepts and relationships; novices rely on what’s visible on the surface. It’s like the physics student who memorizes formulas versus the one who understands the underlying forces. One will have context that sharpens his or her answer significantly.

The same applies to data. Dashboards summarize. AI spots patterns. Neither tells you about the data below it and that gap matters more than most people realize.

Take a simple example: “Average revenue per customer is $40.” That number could reflect two very different scenarios:

• 1,000 customers all paying between $35–$45 (stable, predictable)

• 1,000 customers ranging from $4–$75 (highly variable)

The dashboard shows the same number either way. Seeing the data itself gives a foundation to better understand what that information means and what it does not.

3. Learning and “transfer” (a.k.a. apply what you’ve learned elsewhere)

Research shows that people apply what they learn to new situations more effectively when they understand the underlying principles and structure, not just the outputs.

This means that when you’ve spent time with the data itself, you understand how it is organized, detailed, and start to recognize familiar patterns. You can then apply this when similar data shows up in different reports and contexts.

Instead of starting from scratch each time, you can get oriented faster because you recognize the building blocks. You have seen before how this kind of data works.

Share

What about analysts and AI?

Analysts, dashboards, and AI tools are genuinely valuable. We use them. But they can’t replace your own grounding in the data.

Analysts bring expertise, but not your day-to-day context. They don’t know what feels off in the business right now. And their analysis is always shaped by their own experience and framing.

AI has a different limitation: it can produce excellent analysis, and it can also miss context or make incorrect assumptions. Sometimes it’s hard to tell which is happening.

If you’re not confident with the data yourself, you’re exposed to both of these limitations. You’re relying on someone else’s interpretation without a reliable way to evaluate it.

Even a small amount of time with the underlying data changes that. It gives you enough familiarity to work with analysts and AI tools more effectively, rather than simply deferring to them.

Why this matters

In a world full of dashboards, reports, and AI-generated answers, it’s easy to skip the step of actually looking at the data. Instead choose to actually understand the data. That small step in looking at real rows, real customers, real activity is what builds skill and confidence.

When you’ve seen the data, you build your understanding to judge when an analysis is overreaching, when something looks off, or when a result doesn’t quite line up with reality.

The three learning principles above explain something we’ve observed repeatedly: people who spend even a little time with the data develop a fundamentally different relationship with it. They are not intimidated or afraid. They are more confident and end up using the data well.

Getting started: building confidence with data

Here’s a practical sequence to work through with your team.

1. Choose one report tied to a real question you care about like revenue, leads, customers, usage, donations, support tickets.

2. Export the data. Look for “Export” or “Download.” A CSV file type is usually the easiest place to start.

3. Open it in Excel or Google Sheets. If it opens as a CSV, save a working copy as an Excel file.

4. Set a 15- or 30-minute timer and get curious. Keep a notepad nearby for observations and questions. The goal is familiarity, not a full analysis.

   • Start by scanning the columns. What does each field appear to represent? What looks complete or incomplete? Are there blanks, duplicates, or labels that seem inconsistent?

   • Sort one column at a time - by highest and lowest values, alphabetically, by date. This is the fastest way to spot ranges, outliers, and patterns that disappear in a summary.

   • Filter the data to ask simple questions. Look at one segment at a time: one month, one region, one product type. Move from “What is this report saying?” to “What is actually happening here?”

   • Do one basic summary. Add up a column, calculate an average, count rows in a category. Even simple calculations connect the row-level detail back to the bigger picture.

   • Build one pivot table. If you haven’t used one before, a quick YouTube tutorial will get you there in minutes. Put one category in the rows, one metric in the values, and see what shifts — product line by revenue, region by customers, month by support tickets.

5. Review your notes. What did you notice? What surprised you? What would you now ask an analyst, colleague, or AI tool?

Leave a comment

Share

Subscribe now

Some references

1. Johnson-Laird, P. N. (1983). Mental models: Towards a cognitive science of language, inference, and consciousness. Harvard University Press.

2. Chi, M. T. H., Feltovich, P. J., & Glaser, R. (1981). Categorization and representation of physics problems by experts and novices. Cognitive Science, 5(2), 121–152.

3. Bransford, J. D., Brown, A. L., & Cocking, R. R. (Eds.). (2000). How people learn: Brain, mind, experience, and school (Expanded ed.). National Academies Press. https://doi.org/10.17226/59.

More Reading

Most people think of data problems as typos, duplicates, and broken formats. You’ve probably run into it yourself: you open a dataset expecting to run an analysis, and quickly realize you can’t sort it, filter it, or trust the totals.

But not all issues show up that clearly. Ask five people in your organization what “active customer” means, and you’ll get five answers. Maybe six. And every one of them will be right based on the data they’re looking at.

Someone will say it’s anyone who made a purchase in the last two years. Someone else will say it’s anyone who logged in this month. Marketing will count qualified leads. Finance will only count currently paying subscribers. And the person who built the dashboard three years ago? They’re not quite sure anymore, because the logic changed and it was never documented.

Now you have two different problems: data that doesn’t work when you try to use it, and data that seems clear but means different things to different people.

Both show up all the time, and both can quietly derail your analysis. And as more teams rely on AI tools to summarize, transform, and act on data, these issues don’t go away - they get harder to spot and easier to scale.

So what makes data “clean”?

Clean data is data that is consistently understood and reliably usable when it matters.

It doesn’t have to be perfect or exhaustive. It does have to be trustworthy for the job at hand and interpreted the same way by the people using it.

Two things tend to go wrong:

• Meaning problems: what does this actually represent?

• Quality problems: is this usable and consistent?

Both matter. Most teams only focus on one.

The data problems you can actually see

These are the kinds of “messy” data you can spot right away - what most people think of when they hear “dirty data.” You open a customer list expecting to run a quick analysis. Instead, you get this:

At a glance, it looks fine. But look closer:

• Date formats don’t match

• Status values don’t match

• Revenue is stored inconsistently and is undefined

• One record has no customer ID

• One customer appears twice

Teams focus on this because it’s visible, and because it will actively break your analysis if you don’t fix it first.You can’t reliably:

• Sort or group by date: 03/04/2024, 2024-04-03, and April 3rd won’t sort or compare without standardizing first.

• Filter categories: Active, active, and ACTIVE look the same to you. They aren’t the same to a database.

• Sum revenue: mix currency symbols with plain numbers and you’ll get errors or wrong totals.

• Join to your customer database: a missing ID isn’t just blank. It’s a record you can’t link.

• Trust your totals: Customer 1042 appears twice with different data. Which is right?

Even simple questions like “how many active customers do we have?” can give you the wrong answer because the data doesn’t line up.

This kind of mess is frustrating, but it’s also fixable. Most of it comes down to standardizing formats and making sure fields are structured consistently.

The usual suspects: messy data in the wild

Once you know what to look for, these patterns show up everywhere:.

Even if you clean all of this up - standardize formats, fix duplicates, fill in missing fields - you can still end up with the wrong answer if a more basic question hasn’t been answered: what does “active customer” actually mean?

When the same data means different things

This is easier to miss: the data looks clear, but people are using it differently.

We dug into this last week, but you’ve seen it:

• Revenue → gross or net? recognized or booked?

• New customer → signed up or paid?

• Traffic → sessions, visitors, or page views?

• Active user → depends who you ask

None of these are unreasonable. They’re just not defined consistently. So two people look at the same report, both are “right,” and still walk away with different answers.

Quick rule of thumb: if you don’t know the definition, you don’t know what you’re looking at.

Share

Clean vs. messy: five questions to ask yourself

You don’t need to audit every field in every report to catch most data quality issues. But you do need to slow down and ask these questions before acting on the data.

1. Do you know what this field is measuring - and would your colleagues agree? If you had to explain this metric out loud, could you? If the answer is “sort of,” that’s your sign to pause and clarify before you go further.

2. Are there values that look the same but are formatted differently? Scan the unique values in a column. Variations in capitalization, spacing, abbreviations, or symbols can affect filtering and totals. If they should be the same, standardize them.

3. Does the total hold up if you check it a different way? If your report says you have 500 active customers, try counting a different way. Pull raw data, check another system, or ask someone else to run it. If the answers don’t match, take a closer look.

4. Do you know where the data came from and how fresh it is? “I got it from the dashboard” is not the full picture. What is the source? How often is it updated? Who owns it?

5. Are you clear who is included in a category or type? If you filter by “active customers,” could you explain exactly who qualifies? If not, the data isn’t ready to drive a decision.

Subscribe now

Clean data in practice

Clean data isn’t about getting everything perfect. It comes down to two things: shared meaning and data you can actually use. Everyone understands the data in the same way, and when you use it, it supports the analysis or decision you’re trying to make.

Formatting and consistency issues make your data hard or impossible to analyze. You can’t sort it, filter it, join it, or trust the totals. Definition issues are quieter, but just as important. They lead to inconsistent assumptions, miscommunication across teams, and decisions that look right but aren’t grounded in the same reality.

The good news is that both are fixable.

On the technical side, establish standards (consistent date, currency, and number formats), clean up duplicates, and structure fields so data is entered reliably (dropdowns, required fields, validation rules). You can also ensure each field contains a single piece of information, choose a clear system of record, and standardize data before it’s used in reporting.

On the definition side, get clear on what key metrics actually mean and document those choices so they hold over time. In practice, that means defining metrics in plain language, pressure-testing them across teams, and making sure everyone is using the same definition when decisions are being made.

Your data doesn’t have to be perfect, and you don’t have to solve everything at once. But it does require a habit: taking the time to make sure you and your team agree on what you’re looking at - and that the data will support the analysis or decision you’re about to make. As AI becomes part of more workflows, these issues don’t just affect reports - they shape the outputs you rely on.

Leave a comment

Related articles from We Dig Data:

We see numbers all the time at work. We track progress, allocate resources, consume research, and pitch ideas. But how well do we actually understand what we’re looking at?

If you’re making decisions or supporting the people who do, you are accountable for the number and for understanding what is behind it.

Today we’re talking about how to critically shine a light on data you use to make decisions at work. We’ll cover:

• Why to revisit what you think you know about your data

• How to determine data’s strengths and limits by looking at its source

• Uncovering hidden assumptions

• Balancing the decision against the risk, ambiguity, and bias in the data

This isn’t about becoming a data analyst. It’s about strengthening the skills to size up data and then use it to confidently choose a path forward.

Share

Get to know your data

Most misunderstandings begin here. We too often believe that we are clear on familiar metrics…until someone asks us to explain them. That’s when we realize the gaps.

When we don’t fully understand what the data represents, we draw incorrect conclusions. Everyday sources of confusion include:

Familiar terms that are used loosely. Customers and users. Sales and revenue. These sound interchangeable, but aren’t, and the data can show up differently. For example, let’s say you sell a $1200 annual subscription. Sales will show up the month the sale closes, but the business recognizes revenue evenly over the duration of the subscription.

One label, many definitions. Metrics like “traffic” sound intuitive, but have many meanings. “Traffic” can mean page views, sessions, visitors, or unique visitors.

Missing context. A percentage or rate change sounds clear until you ask: from what to what? Statements like: “Lead conversion rates have grown 10%!” have little meaning until clarified into: “Last year, the internal sales team converted 10 out of every 100 website leads into a sale. This year, they are converting 11 out of every 100.”

Vague or inconsistent classifications. A report documents “adverse reactions” for a new drug. But what does that mean? A mild rash or hospitalization? Definitions and classifications vary by industry or even by department in the same organization.

Even if a term seems obvious, confirm that what you think the data represents is accurate. Clarify and define, don’t assume.

The source shapes your interpretation

Where the data came from reveals its strengths and its limits. This context will determine how much trust you put into a number’s accuracy and reliability.

For EXTERNAL data sources, ask:

1. Who published the data? Established, credible sources - like census data or a reputable research firm - are generally more reliable, especially when the organization specializes in data and has a verifiable track record. In contrast, vendors or lobbyists may provide research, but they also have incentives that could bias how results are framed or interpreted.

2. Where do they get their data? How did they collect it? Does the data adequately represent the population being measured? What is the sample size? Strong data sources explain how they collected their data and acknowledge limitations.

3. Is the methodology available? How information is collected, defined, and calculated determines whether it is actually relevant to your situation. Credible sources will usually explain how they collect and analyze their data and what limitations apply. If someone dodges your questions, be cautious.

For INTERNAL data, ask:

1. What is the data source? Some systems cover only part of the business when you are trying to understand the whole. Others may have known quality issues when you need greater accuracy.

2. Is it a recurring report or a one-off request? Ad-hoc reports require more scrutiny. Regular reports have usually been stress-tested and refined over time.

3. Who built the report? Different departments bring different lenses. Finance may be more conservative than Sales. Marketing may define ‘customers’ differently than Operations. Each team has different data access, expertise, and perspectives. These factors influence what gets measured and how it gets presented.

No data is perfect, but solid data can withstand scrutiny.

Uncover assumptions behind the data

Every number is built on choices. Some choices are clear (like a time frame), but many are invisible unless you ask. Let’s start with a few that cause the most trouble:

The sample population. Don’t assume a data point represents the full picture. If a survey on fried chicken sandwiches is conducted with 1,000 college students, it doesn’t represent national preferences - it represents college student preferences. So always ask: Who’s actually included in this data? And who’s missing?

Projections and estimates. These are built on assumptions, and you may not agree with the approach nor the level of risk represented in those choices. For example, a revenue forecast will include assumptions like: average sales price, expected growth or decline, revenue from new clients vs. existing clients or new products vs. existing products. Don’t hesitate to have these discussions. They are usually an invaluable step for refining estimates and projections.

Check the math. You don’t need to audit everything, but a quick spot check often catches errors before you get too far. A 2025 Canva survey reported that 57% of respondents said they make spreadsheet errors that impact their work. With numbers like that, it’s not worth just assuming the math is right.

Data skeptics remember to probe on these areas because they’ve learned (often the hard way) how easy it is to act on a false assumption.

“Good enough” is a real answer

You won’t always have perfect information. The question is whether it’s good enough for the decision you are making.

Match the scrutiny to the stakes. Low-stakes decisions, like an A/B test tweak, may not require bulletproof data. High-impact decisions, like a large investment or launching in a new country, warrant more scrutiny.

Watch for false precision. Specific numbers can signal more certainty than actually exists. For example: “40.2% of the population will go on vacation this summer, up from 39.8% last summer.” But if these are based on two consumer surveys of 100 people each, that extra decimal is indicating a level of certainty that does not exist.

Treat surprises as signals. If something looks off - up, down, or just unexpected - pause. Surprises are your cue to investigate. It might be a real shift. It might be a data issue. Either way, it’s worth understanding.

Ranges can be good enough too. If you have a small client base, it could be good enough to use a small range when analyzing annual client survey data. “Approximately 3%-5% of clients plan to increase their marketing budgets, which is about the same as last year.” Being directionally right is sometimes enough, but you need to know that going in.

Spot the bias

Information is produced and interpreted by people. Everyone has a lens, and sometimes an agenda. This doesn’t make their data wrong, but it does mean you should consider that bias in how you apply that information.

Motivation matters. Incentives shape how data is framed. That doesn’t make it wrong, but it does affect how it’s presented. A pharmaceutical company wants positive results for a new drug or product. A salesperson’s forecasts are influenced by how they are compensated. From students to policymakers, people interpret data through their lens. Know the agenda, and factor it in.

Over-generalizing. When data is missing or hard to find, it’s tempting to apply one piece of information to perceived similar situations. But what is true for one group, market, or channel may not apply more broadly. Instagram users do not necessarily represent all social media users. New York City restaurant trends don’t predict what’s hot in Texas, and the top-selling toys in the U.S. won’t match those in France.

History doesn’t always predict the future. Past patterns can break. A competitor has a breakthrough moment. There’s a technology shift, a viral moment, or a market trend that quietly hits a tipping point. ‘It’s always been this way” is an assumption, not a fact.

Why data skepticism matters

Data is never just numbers. It’s a set of choices about what to measure, how to frame it, and who it represents. Your job isn’t to audit every figure. It’s to stay curious enough to ask the right questions, and confident enough to push back when something doesn’t add up.

Leave a comment

Share

Subscribe now

Additional Reading

Here are two excellent resources from fellow Substack writers if you want to go further on assessing external resources:

• , author of Card Catalog, recently wrote a guide to evaluating information sources in the AI age.

• , author of Slow AI, wrote about how to spot a fabricated source and created a game, Dead Reference, to test your skills.

More related articles from :

You are in a meeting. A dashboard is shared, and a report appears on screen. A number jumps out - maybe it’s higher than expected, or maybe lower. Way lower.

Someone says what everyone else is already thinking: “Those numbers can’t be right.”

And sometimes they aren’t. But just as often, the number itself isn’t the problem. What’s actually being challenged is our expectation of what the number should be.

These moments are signals to slow down and take a closer look.

Despite the internal groan, great data conversations happen when the numbers don’t match the story in our heads.

In this post, we will walk through an example of how one product team handles this situation as well as the process that great teams use for investigating data that doesn’t match expectations.

Subscribe now

When the numbers don’t make sense.

Imagine a product team that has recently introduced a new feature inside their main product that allows users to generate a report, a task previously requiring cumbersome manual work.

Customers have been clamoring for it. The internal team is excited about it. They’ve highlighted the new reporting feature in release notes, mentioned it in onboarding messages, and demoed it internally. Everyone assumes clients will jump in right away.

Two weeks later, after a robust launch campaign, the internal team pulls up a usage dashboard. The usage number is… surprisingly low. Only a tiny percentage of users appear to have engaged with the new reporting tool at all.

Around the table, people start doing the quick mental math. Something about the number doesn’t feel right. What’s going on?

There are a few possibilities. And in practice, it’s often a mix of them.

There is a problem with the data.

Sometimes the issue really is the data.

Our product team’s usage metric depends on analytics signals that fire when someone uses the reporting tool. After digging into the setup, the team discovers those signals were only triggered when users opened the tool from one specific place in the product.

But many people were reaching it through other paths like shortcuts, saved links, or existing workflows. Those sessions simply weren’t being counted.

There are many alternatives that may cause problems with your data, even it is an established report. Data pipelines break. Dashboards miscalculate. Definitions drift over time.

The metric isn’t measuring what you think.

In another scenario, the data itself is fine, but the metric isn’t measuring what the team assumed.

The team thought the metric would count people who opened and used the tool. Instead, it counted only people who successfully finished creating a report.

All those users who explored for a moment or found the data to answer a quick question, and then left? Ignored. The dashboard reflected only users with reports completed, not usage.

Once the definition was clarified, the problem to investigate was no longer, “why isn’t anyone using the tool?” but “why are people starting the process, but not finishing it?”

The underlying assumption is wrong.

Sometimes the number is accurate. Disappointing? Sure. But wrong? No.

When reviewing the data more closely, our product team notices something interesting: the reporting tool is being used only by a few users, but they have logged in multiple times. They identify that only the power users who regularly analyze large datasets are the ones logging in. And most customers only need that kind of reporting occasionally.

The new feature isn’t failing. It’s just for a more specialized audience than the team originally expected.

That realization changes how the team thinks about improving the tool and how they introduce it to customers going forward.

This is often the most difficult situation to accept. In this case, the feature wasn’t as applicable as they’d assumed, so hopefully they learned how to pressure test customer feedback better.

Share

These moments show up everywhere

Mismatches between data and expectations appear across all types of organizations:

• A customer service team runs their quarterly client satisfaction survey and sees scores plummet unexpectedly.

• A small business owner notices a shift in sales patterns that doesn’t match their day-to-day experience.

• A library checks its children’s program dashboard and finds attendance numbers that feel surprisingly low.

In each case, the number doesn’t quite line up with what people thought was happening.

And the best teams investigate…doggedly

Sometimes the explanation is technical like a data pipeline problem or a change in how the metric is calculated. Other times the number is pointing to something real that simply hasn’t been noticed yet.

Strong teams resist the urge to immediately defend or dismiss these situations. Instead, they treat the moment as a serious investigation. When pursuing an explanation, they typically follow this path:

1. Check the source
Is the data pulling from the right system? Are records missing, duplicated, or only partially captured? Has the calculation changed? Has the report been refreshed?

This requires investigative effort for you and your technical partners. If you aren’t familiar with how that report is created, now is a good time to start learning about the data pipeline.

The good news? In this situation, once the issue is corrected, the numbers change significantly and tend to return to “normal.”

2. Confirm the definition
What exactly does this metric measure? Is it counting the thing people assume it is?

Data’s intangible nature means that we often are not speaking the same language. In this case, a picture is indeed worth a thousand words. If you suspect your metric is not measuring what you think it is measuring, meet the report builder and sketch or show the behavior that you think you are measuring.

Even if you both are using the same words, don’t assume that their definition of ‘customer’, ‘sales’, ‘conversion’, or ‘traffic’ is your definition.

3. Revisit assumptions
If the number holds up so far, then it’s time to re-assess your assumptions. What else might explain the results? Are we expecting something that isn’t actually happening?

This is when you find your assumptions need adjusting. Sometimes, you even discover that a fundamental belief or ‘truth’ about your business or industry simply is not accurate.

These perspective-altering pieces of information are incredibly valuable, but can be difficult for you, or your organization, to accept. If this is your situation, triple check the data and look for explanations that might help you interpret what you are seeing.

Subscribe now

Why this matters

Handled this way, the moment of skepticism becomes productive. It helps the team surface the real issue and focus on the problem that actually needs solving. Teams clarify what their metrics actually mean, surface hidden data quality issues, and notice real patterns that might otherwise go unnoticed.

This effort strengthens the team’s relationship with their data and with this familiarity, they also gain more confidence in the numbers they rely on. Just as important, the culture around data shifts. Instead of defending assumptions or dismissing surprising results, teams get more comfortable investigating what’s really happening.

So when someone looks at a report and says that number can’t be right, they might be correct. But even when they aren’t, the reaction is still valuable.

It’s an invitation to pause and ask a few better questions: Where did this number come from? What does it actually measure? And do our assumptions still hold?

Have you ever had a moment where the numbers didn’t match what you expected?

Leave a comment

Related articles

If you’re an entrepreneur, product manager, or basically anyone who builds stuff, you’ve probably felt that tension that surfaces when engineering pushes back on your desired launch timeline. Or the data team challenges the data sources behind your projection. Or IT wants to review security and integration before approving the new tool that is going to save you a ton of time and effort.

It can feel like resistance. But it might actually be a sign of a healthy system.

Technical teams optimize for different priorities, and those differences can be genuinely valuable to the organizational mission. While you might be optimizing for speed to market, customer impact, or feature delivery, your technical partners may be focused on system reliability, scalability, data quality, and long-term maintainability.

While your priorities and their priorities often don’t naturally align, both are necessary. And when you harness that tension, it produces better decisions. You’ll even find that great products or results often emerge from the space between those two sets of perspectives.

Vision vs. Feasibility
Someone pushes the idea forward. Someone challenges how it will work.

Speed vs. Durability
Someone wants to launch now. Someone is thinking about after launch and the ongoing user experience.

Business Outcomes vs. System Health
Someone focuses on growth metrics. Someone fortifies the system that growth depends on.

Healthy organizations don’t eliminate this tension. They encourage learning how to leverage it to their benefit.

When perspectives collide and you work through those constraints, stronger solutions emerge. When you don’t, you often end up with brittle or broken systems, unrealistic roadmaps, or solutions that look good, but arrive too late.

The goal of working well with your engineering, data and IT/ops partners isn’t to eliminate friction. The goal is to make that friction productive, to navigate the different, seemingly competing, priorities and to treat pushback as an opportunity rather than as a roadblock.

The best partnerships with these roles rarely feel effortless. More often, they feel like two smart people pulling the same problem from different directions until the right answer emerges. That creative tension, when managed well, can develop into one of the most valuable, and rewarding, working relationships you have.

Why It Matters

This post may sound a bit like a love song to partnerships between business and technical teams. In some ways, it is. Over the years, we’ve watched difficult working relationships evolve into genuine partnerships, and we’ve coached dozens of product, business, and technical professionals through that transition. When those partnerships take hold, something remarkable happens: products move faster, solutions improve, and problems get solved at a level that wouldn’t have been possible otherwise.

So, if you are looking to improve your relationship with a technical partner, here are three mindset shifts that can accelerate the journey.

Lean teams don’t measure everything, and they don’t wait until they’re bigger to start. They decide what matters most right now and measure that.

Growth rarely moves in a straight line. It happens through experiments, plateaus, and jumps. Data provides the feedback loop and without it, you’re guessing.

And yet, many teams avoid the data they already have. They don’t ignore data because they don’t value it. They ignore it because it’s overwhelming.

They have too much data, and that information is spread across different systems. The definitions are often unclear, and measurements may not tie together. Plus when numbers are small, it is hard to know what’s meaningful.

How can you leverage data to accelerate your progress? And how can you integrate this into your operations without feeling like you are just adding one more thing to your “to-do”?

Going from overwhelm to focus

Instead of tracking everything (or the wrong things), you intentionally narrow the field. You choose a very targeted subset of your data.

Which data? The data that measures your current top priority(-ies).

Priority —> Drivers —> Data

What’s your priority?

What are the drivers?

What data do you need to measure progress?

1 | Start with one priority.

• “Grow referral business.”

• “Improve checkout rates.”

• “Build an engaged email list.”

• “Increase net subscription enrollment.”

• “Increase on-time payments.”

2 | Next, identify the drivers: the actions that will, or could, create movement and momentum in that priority.

If your goal is “improving checkout rates” on your online shop, drivers might include:

• “Increasing traffic to product pages”

• “Improving ‘add to cart’ conversions”

• “Sending cart reminder emails”

• “Testing time-bound promotions”

3 | Narrow the list to 1-3 drivers, and for each one, choose at least one clear way to measure progress.

Start with drivers you are already focused on or plan to start working on in the near-term.

For example: “Increase traffic to key parts of our website as measured by “weekly product page views.”

Now your data conversation has focus.

Example: How We Are Doing This

One of our priorities is “building an engaged, relevant audience” not simply increasing raw subscriber counts.

Once we clarified that, we asked ourselves which actions would actually attract that audience. Knowing we couldn’t do everything at once, we then narrowed our focus to just a few of those drivers:

• Grow our email list

• Increase meaningful engagement with posts

• Expand awareness on LinkedIn and Substack

For each of those drivers, we chose simple measurements we could review each week:

• Monthly net email subscriber growth

• Engagement per post (comments, restacks, shares)

• Follower and subscriber trends across platforms

We didn’t decide to track everything Substack or LinkedIn offered. We chose a handful of signals tied directly to what we are trying to create. Reviewing those consistently helps us decide where to invest our time - and where not to.

Use data to go further, faster

Using data to fuel your progress requires focus. And that is what you’ve done here. So far you’ve identified a few metrics that measure the drivers for a top priority. Integrating data into your regular operations is simple in comparison, but it does require some set up and consistency.

What gets measured gets done. BUT those measurements need to be kept visible. To implement a data feedback loop:

1. Assign an owner for each metric to pull and review it.

2. Schedule regular review time on a weekly or monthly basis.

3. Discuss what changed and why, allowing time to problem solve, brainstorm, and hypothesize.

4. Test and experiment - try something new.

5. Review next time. What worked, what didn’t? Why or why not?

Make this a habit and you will not only see accelerated progress against your priority, you will also begin to expand this method to other priorities and data.

Want help applying these concepts? We Dig Data is bringing our workshops to a group format. These workshops help individuals and lean teams use data better to accelerate their impact. Learn more here or send us a note.

What if your numbers are still very small?

When you are starting out or have a specialized mission, data volume is often low making trends are harder to read.

Two approaches to try:

• Aggregate the data over longer time periods (example: monthly instead of weekly)

• Group similar activities together (emails categories, not individual campaigns)

They may not be statistically perfect, but you are looking for hypotheses and signals you can test.

Even when numbers are small, record them consistently. Add notes on activities that might have impacted that metric. Over time, you will see patterns emerge.

Summary

You don’t need perfect data. You need aligned data. When your metrics connect directly to a clear priority, the noise fades and the next step becomes obvious. Start small. Choose what matters now. Measure the drivers that move it. Review consistently. Over time, the habit of focused measurement won’t just help you grow faster, it will help you grow on purpose.

Tell us how you are measuring your key priorities or the roadblocks you run into!

Leave a comment

Share

Subscribe now

We work with a lot of people in small businesses or lean teams that are part of larger businesses or non-profit organizations. They are smart, passionate and resourceful. They’re juggling a lot as they pursue meaningful objectives.

Data? It’s rarely at the top of the list.

We hear:

“We are still too small. The data isn’t useful yet.”

“I have bigger priorities right now.”

“Reviewing my data is just one more thing on my list of urgent tasks. And I’d have to figure out the tools. And I don’t even like data!”

We get it. We’re also a startup. We’re less than a year old. We’re strapped for time. We’re small in numbers. Really small. We’ve had a handful of client engagements and fewer than 1,000 subscribers across Substack and LinkedIn, our primary platforms.

Given that, you might think that this is an absurd time to be thinking deeply about analytics. And yet - here we are.

Here is why, despite being small, we review our (very minimal) data regularly - and why lean teams should too.

Reason #1: A Few Select Metrics Create Focus When Resources Are Tight

When there’s too much to do and not enough time, you have to focus somewhere. If you don’t, you end up spread too thinly. And when you’re building toward something larger, the signals you pay attention to matter - even if the signals are still small.

For us, those signals currently live on Substack.

Substack is not our product. It’s a platform where we’re cultivating community ❤️, testing ideas, earning trust, and attracting the kind of curious, builder-oriented audience that might eventually want to go deeper with courses and workshops.

Because of that, we intentionally invest time there to become a valuable part of the community.

Reason #2: Growth Isn’t Linear. Data Gives You a Feedback Loop.

Building anything involves experimentation. Data gives you something to react to.

It helps you adjust more quickly, even when the numbers are modest. No matter how much we might love a feature or a “brilliant” idea, it may not resonate, or it may need refining.

Over the past few months in Substack, we’ve:

• Experimented with format, features, and cadence.

• Written more Notes.

• Tried Recommendations.

• Shared workshop concepts to gauge interest.

• Promoted differently on LinkedIn.

Each week, we document a small set of Substack metrics, review Google Analytics and track LinkedIn engagement. The numbers are modest, but we’re starting to see small pockets of traction. We’re learning what’s resonating and with whom. That clarity guides our efforts and shapes where we invest our limited time. Without that feedback loop, we’d be guessing.

Reason #3: Data Helps You See Progress When It Feels Slow

There are stretches in any builder’s journey where you hit setbacks, or momentum feels invisible. It’s easy to compare yourself to another lean team that seems to be skyrocketing. It’s easy to question whether the effort is worth it.

This is where tracking a small set of meaningful metrics over time becomes grounding. When you look back at your numbers - subscriber growth, engagement patterns, steady increases - you often see forward movement that didn’t feel obvious at the time.

Data helps you see how far you’ve actually come.

How to Get the Biggest Return on Your Data (With Minimal Effort)

Start with priorities, not dashboards. Not all movement is progress- start by deciding what kind of movement you’re actually trying to create.

For us, the priority right now is building a relevant audience, not just a larger one. We want to know whether our ideas resonate meaningfully. And we want to steadily grow an email list we can responsibly market to when we bring our client-specific methods to a broader audience through courses and workshops.

Once priorities are clear, the data conversation begins to gain focus.

We typically see lean teams will engage with data in two ways: analysis projects and indicator metrics.

• Analysis projects are deeper efforts to understand patterns of behavior. Mapping how someone moves through a website. Establishing a baseline before changing strategy. Answering a strategic question that can’t be resolved with a single dashboard metric.

• Indicator metrics are the signals that our platforms generate to tell us what is happening. Traffic trending up. More people commenting. Subscriber adds per post increasing.

At We Dig Data, we’re focused on indicator metrics right now.

Analysis matters - especially baselines - but our current priority is directional clarity: Are the experiments we’re running creating movement in the areas that matter?

So we track a small number of Substack metrics tied directly to our priorities. That doesn’t mean other metrics aren’t important. It means they aren’t the ones guiding our weekly decisions.

Next Up

Next week, we’ll share more specifics about challenges you may encounter and how to navigate them. We’ll also walk through the exact metrics we track and why we’re intentionally ignoring the rest.

In the meantime, if you’re looking for step-by-step guidance on setting up Google Analytics in Substack or understanding the Substack dashboard, several strong walkthroughs already exist. Two good starting points:

• breakdown of Substack analytics

• Google Analytics setup guides by

What’s one metric you pay attention to right now - and why? Leave a comment. We’d love to compare notes.

Leave a comment

You are responsible for the data you use to make decisions. But there’s more data, more claims, and more “insights” than any reasonable person can thoroughly vet. A key skill today is deciding what deserves scrutiny and how much. But if you burn out fact-checking the data source for every stat that crosses your screen, you’ll end up trusting nothing - or worse, trusting everything because you’re too tired to care anymore.

So how do you evaluate a source in a world of information overload?

Ignore Unsourced Claims

If someone makes a data claim without citing where it came from, skip it. If the author didn’t take the time to source their data, then it’s not worth your mental energy to consider it as proof. Following this rule alone will filter about 80%* of what comes your way.

(*See what we did there? That 80% isn’t sourced because we made it up. The right move was to question it or ignore it!)

Evaluating Data, and an Example

With so much data, it is relatively easy to find a piece of data that supports a point you want to make. And someone making a claim using data is usually trying to convince you of something. That something may be true, but as with anyone trying to influence you or inform you, it’s worth asking:

Where did the data come from?

Let’s walk through a real example from 2025. This is a Canva press release citing data about data usage (yes, it’s meta, but it’s a good example).

Consider Who Published the Data

Data from established, credible sources - like census data or reputable research firms - is generally more reliable, especially when the organization specializes in data and has a verifiable track record.

Be more cautious with research from vendors, industry organizations, or think tanks. It may be solid information, but it usually aligns with their goals. It doesn’t mean the data is wrong, just that the data publisher has incentives that could bias how the results are framed or interpreted.

In our example, Canva - a company that makes online design tools - launched a 2025 product focused on packaging data visually. That gives them an incentive to highlight findings that make their product seem essential. We don’t automatically reject the data, but we do read it with that incentive in mind.

How Do They Get Their Data?

Context shapes how you interpret the data and how much trust you put into its accuracy and reliability.

Understanding who the data represents, how they were selected, and how much of that audience is actually captured is key. A small, well-defined sample can still be meaningful. A large, skewed one can be misleading. You need to ask whether the data appropriately represents the population behind the claim.

Who got surveyed? Too often, a data claim is attributed to a broader audience than it supports. In our example, Canva’s headline claimed “89% of professionals work with data weekly.” However, the Canva survey only targeted marketing and sales professionals and not operations, IT, finance, or product. That’s a significant gap.

Understanding who the data represents, how they were selected, and how much of that audience is actually captured is key.

Methodology Matters

All sources require a critical lens, including government agencies or official statistics. How a metric is defined, calculated and scoped determines whether it is actually relevant to your situation.

For example: Did you know that measures like GDP and inflation are calculated differently across countries? In the US, multiple official measures of inflation exist, and the most commonly cited one excludes food prices. If your industry depends on food costs, that number may not tell the story you need it to.

Transparency

Strong data sources explain how they collected their data and acknowledge limitations. If methodology is unclear or hard to find, that’s a signal to dig deeper. No data is perfect, but credible data can withstand scrutiny.

In our example, Canva shared methodology details and worked with an outside survey company to conduct the research. That level of transparency is meaningful even if there are still limitations to consider.

The Reality: Most Data Won’t Be This Transparent

The Canva example is somewhat unusual in that it clearly states who published the data, where it came from, and how it was collected.

More often, you’ll see something more like this from The Economist:

No source for the estimate. No footnote. No context. Just a number presented as fact. At that point you either accept it as face value or go hunting for the original source yourself. (We did. Here’s the link.)

“This Is a Lot of Work. Can’t I Just Use AI?”

Yes, with some caveats. Despite AI’s well-earned reputation for occasionally making things up, it can be surprisingly useful for the legwork of validating sources.

AI can usually help you:

• Find and summarize the original source

• Interrogate the methodology and limitations

• Search for alternative data from credible sources that support (and contradict) what you are reading

• Flag potential conflicts of interest based on available context.

For a structured approach to research using credible sources, this article from offers a helpful framework and case study using Google’s NotebookLM.

AI should not replace your judgment on whether to trust a piece of data. It can however reduce friction and mental load of evaluating the data that crosses your screen.

More Reality: Everyone Has an Agenda

Everyone has goals, and those goals shape how data gets framed. A pharmaceutical company wants to show positive results to the FDA. A salesperson might tweak forecasts based on how they’re compensated. From students to policymakers, people interpret and feature data through their own lens.

Motivation doesn’t make data invalid, but it absolutely shapes presentation, emphasis, and interpretation. Factor in their agenda to interpret data responsibly.

Canva’s Study: What’s the Verdict?

Overall, the Canva study is directionally useful - with limits. We wouldn’t make high-stakes decisions based on it alone, but it’s reasonable to say that a large share of marketing and sales (not all) professionals are using data weekly and many of them feel anxious about it or would like more support.

We also keep in mind the context: Canva wants these findings to support their product launch, and the survey reflects marketing and sales professionals - not all professionals. Even within that group, results likely vary by industry.

One unexpected insight stood out more than the headline statistic:

That finding is less about Canva’s product than a universal risk; if nothing else, it’s a reminder to spot check a spreadsheet before acting on that data.

Why All of This Matters

Your decisions are only as strong as the data behind them. In a noisy world saturated with numbers and claims, your advantage is knowing how to discern what data deserves your confidence and how much.

That said, scrutiny has its limits. You can’t fully investigate every statistic you encounter. The goal isn’t perfect; it’s the discipline you can sustain.

Filter out unsourced claims. Prioritize transparent research. Leverage AI to help shoulder the investigative work. The result isn’t just better data consumption, but clearer conclusions and stronger decisions.

Share

Leave a comment

Subscribe now

Subscribe to Practical Data Foundations

You start a new role and inherit a set of dashboards you didn’t build. Or you’re running a small business that’s finally growing, and you realize gut instinct isn’t enough to make the next decision. Or perhaps you’re looking at new systems, sitting through demos and trying to imagine what the data would look like once it’s actually yours. Different situations, same feeling: suddenly there’s a lot of data on the table, and an unspoken expectation that you should be able to make sense of it.

In those moments, the data itself isn’t the hardest part. It’s the space between knowing the business and knowing the systems: recognizing familiar metrics, but not trusting the numbers or being clear on what they stand for; feeling like you should have some answers while still trying to understand what you’re even looking at. And particularly in small businesses, it’s a space you’re in without the staff or time to reconcile everything. It’s where many people get stuck.

And when you’re there, there can be a temptation to start analyzing just to have something to say. Any answer can feel better than no answer. But that’s like moving spontaneously through unfamiliar terrain just because you have a map in your hand. Before you head off in any direction, you stop and orient yourself. You figure out where you actually are, what landmarks you can trust, and which tools will help you make sense of the surroundings. Working with data is no different. You need to get your bearings.

When you have data but not a clear answer

Consider an established HVAC service business serving a core geographic area. Demand is steady, crews are close to capacity, and leadership is starting to ask whether it makes sense to expand service into neighboring ZIP codes or towns. On the surface, it sounds like a simple data question: Do the numbers support expanding our service crews?

The business has data, but it’s scattered across systems built for different purposes. Scheduling and dispatch data documents where crews are already going and how long jobs take. Billing data shows revenue by job and customer. Customer records reflect repeat service and maintenance plans. Lead intake data captures calls and requests, including inquiries from areas they don’t currently serve. Website data may hint at interest beyond the core territory.

Some of these systems will overlap. The same customer, job, or dollar amount may show up in more than one place. That’s not a flaw. It’s a clue. Overlap usually means the data is being used to answer different questions, from different angles.

Taken together, these datasets don’t add up to a single answer. Before modeling or projecting anything, the business needs to get oriented. Which data speaks to demand? Which reflects capacity? Which helps frame financial risk?

At this point, the goal isn’t to find the answer yet. It’s to understand what each dataset is actually good for. After that, you can move forward without guessing.

Build your data map

When you’re surrounded by data from multiple systems, the most useful thing you can do is stop treating it as one big pile. Instead, create a simple map that connects different types of data, usually contained in different systems, to the kinds of questions they’re designed to answer. This isn’t documentation or cleanup. You’re just trying to make the landscape visible.

Start by listing the systems and the data from those systems that you have. For each one, answer three basic questions:

• What kinds of questions was this system built to answer?

• What does it do particularly well?

• What should it not be used for?

For our growing HVAC service business, that might look something like this:

• Operational systems (scheduling, dispatch, job tracking)
  Show capacity and how crews spend their time, not unmet demand.

• Financial systems (billing, accounting, invoicing)
  Show revenue and margins, not why demand exists or where it’s coming from.

• Customer systems (service history, maintenance plans)
  Show repeat behavior over time, not early interest or acquisition.

• Lead intake systems (calls, forms, service requests)
  Show demand signals, not completed work or guaranteed revenue.

• Digital behavior data (website activity, service pages)
  Show awareness and interest, not operational or financial reality.

One metric, multiple locations (and definitions)

Sometimes the same activity shows up in more than one place. A service call appears in the scheduling system, in the billing records, and in the customer history, each time with slightly different context. A lead might show up as a missed call, a website request, or a note in a customer record, depending on where it entered the system. The overlap isn’t accidental. Each system is capturing the same moment from a different angle.

The goal here isn’t to decide which system is “right.” It’s to understand what role each one plays. Once you do that, overlapping data stops feeling like a contradiction and becomes context: different views of the same business, answering different questions.

Create a small shared vocabulary

Once you’ve outlined your data sources and mapped those to the kinds of questions they answer, it helps to pause and agree on how you’ll describe what you’re seeing. With data coming from multiple systems, alignment with your team matters.

Pick a short list of terms that keep coming up and agree on what you mean by them. For example:

• What counts as a customer?

• What do you mean when you say demand?

• What does revenue include? What’s not included?

• When you talk about a job, lead, or request, where does it show up first?

These don’t need to be perfect or permanent. They just need to be clear enough to keep conversations moving without constant clarification.

Once you’re oriented, take the next step

For our HVAC business, being oriented means they know what data they have in their landscape and can make intentional choices about which systems to rely on in different situations.

When considering expansion of their service crew, they know which systems they look to for capacity and scheduling lead times, which ones they use to understand demand, and which ones they trust when evaluating financial risk.

They understand what the data means, and what it doesn’t. So when lead counts don’t match completed jobs, that difference isn’t treated as an error to fix. It’s expected. Lead data is used to gauge interest and potential demand; completed jobs are used to understand what the operation can actually deliver. Each number has a role.

One last note: once you have your bearings, the next step isn’t to answer everything at once. It’s to choose where to focus; to choose your next destination.

Understanding the landscape gives you a way to be deliberate. You can decide which question matters most right now, and which view of the data is most appropriate for that question. And instead of reacting to every number on the page, you prioritize the signals that fit the question and let the rest stay in the background.

Then, when you are ready, you choose the next question or destination, and map how you will get there. Orienting with your data soon turns into forward motion step by step.

You get an alert saying the weekly dashboard is ready. You click the link and start scanning the numbers. Some are up. Some are down. You close the dashboard and move on to the next thing on your to‑do list.

Either that dashboard shouldn’t exist, or you’ve fallen into a common, but very understandable, trap: stopping at review instead of turning what you see into a conclusion and then a next action.

We’re not picking on you. Turning information into a conclusion and next action is genuinely hard work. It requires practice and repetition, plus the confidence to know which numbers matter and say what they imply.

Go Beyond Reporting

Reporting is the starting line, not the finish. To move from dashboards to decisions, we hold ourselves accountable by using this template when reviewing a metric, analysis, or report at work: Say – Mean – Do.

Start with a regular dashboard that reflects your team’s goals or priorities. Then pick one or two changes and ask yourself: What does the data say, and what does it mean? Numbers tell you what happened, but insight comes from explaining why. Context matters because data rarely speaks for itself. Next, comes the harder question: What am I going to do? This is where insight earns its keep, by turning into action. Insight without a next step is just trivia.

This is easier than you think.

Instead of: “Attendance was down 10%.” [Say]

Try: “Attendance was down 10%, likely because of last week’s snowstorm.” [Say + Mean]

And then identify a step like: “Next time, let’s plan a few programs that work better for families during bad weather.” [Do]

Or sometimes, no action at all. “Snowstorms are rare. Let’s make sure attendance rebounds next week.” [Do]

That’s still a decision.

The Say–Mean–Do Template

This is what you practiced above in a format you can reuse.

[What does the data say] because [why / what it means].

My next step(s) is [what will you do].

That’s it. Say. Mean. Do.

Using Say-Mean-Do in Meetings

You don’t need to formally introduce this framework for it to be useful. Used in a team setting, these questions shift the conversation from reporting to thinking together. They’re not about challenging authority or catching mistakes. They’re an invitation to think together, opening the door to curiosity, problem-solving, and shared judgment.

• “Let’s slow down. What do we see in the data?” [Say]

• “Okay, what does that mean?” [Mean]

• “So what’s the move?” [Do]

This kind of discussion enlivens the process of turning data into action. Over time, it weaves data naturally into your day-to-day operations and workflows, strengthening decisions and improving outcomes (without anyone ever having to say “Say, Mean, Do”).

Design Dashboards for Action

A big roadblock in data analysis is going from insight to action. Why? Because it will require time, energy, knowledge, confidence, navigating uncertainty - or any combination of these factors.

To reduce this friction, design your dashboards for decisions. We are not saying that your dashboard should tell you what to do and when. That type of design is development intensive and usually ends up being too rigid.

Instead, integrate the “Do” portion of Say-Mean-Do by defining up front what decisions that dashboard is meant to support. Draft a short statement clarifying why the dashboard exists, who it’s for, and, most importantly, what decisions it’s meant to inform.

Doing this work streamlines the data analysis piece of your workflow, and prevents dashboards from growing bloated - which also saves time on report production and review.

Template for Your Dashboard “Do” Statement

This dashboard exists to help [who uses it] decide [types of decisions it should support]. It’s reviewed [how often].

When a metric changes, the expected actions are [what we would do differently]. —> Spend your energy defining this portion, and refining as needed over time.

If a metric would not change a decision or action, it doesn’t belong here.

Share

Here are some examples with different contexts, but the same principle: decisions first, metrics second.

For a Marketing Team

This dashboard exists to help the marketing team decide where to invest next quarter’s budget. It’s reviewed monthly by the VP of Marketing and channel owners.

If a metric moves meaningfully, the expected action is to reallocate spend, pause underperforming campaigns, or double down on high‑performing ones. [DO]

If none of these decisions would change based on a piece of data, it doesn’t belong in the dashboard.

For a Yoga Studio

This dashboard exists to help the studio owner decide which classes to offer and where to focus outreach. It’s reviewed monthly.

When attendance or engagement changes significantly, the expected action is to adjust class times, class formats, or marketing efforts.

If a metric wouldn’t change those actions, it doesn’t belong here.

Leave a comment

Summary

Information is powerful, but it’s also easy to get lost in it. When there’s too much to review, you can lose sight of why you opened the dashboard in the first place and what decision you were trying to make.

With practice, you can build the habit of turning information into impact. Name what you see, say what it means, and decide one possible move. You don’t need perfect certainty. You just need to move from looking at data to using it.