One person should own your stats refresh process

You publish a piece with ten killer statistics. It lands well. Traffic spikes. A competitor cites your number. A podcast host quotes it.

Then, six months later, someone on your team pulls the same stat for a deck, and you realize: the source link is dead, the methodology is fuzzy, and nobody remembers who calculated it in the first place.

One-off content wins feel great until they become liabilities. The stat you published in Q1 gets reused in Q3 without anyone checking whether it's still true. Your Head of Marketing drops a number into a pitch deck. Your CEO repeats it on a panel. And if that stat was wrong—or just stale—you've now compounded a credibility problem across every channel.

This is the gap between publishing statistics and running a stats program. Publishing is a campaign task. A program is a company asset. And most startups treat proof like a campaign task, which is why their data credibility decays the moment the article ships.

The real question isn't "should we use data?"—it's "who makes sure our data doesn't turn into a liability?"

Most founders skip this step entirely. They'll assign someone to write the piece, pull together sources, and hit publish. But nobody owns the system that keeps those numbers credible after launch. No refresh cycle. No validation layer. No central record of what's been published, where it came from, or when it expires.

That's how you end up with a stats graveyard: a folder full of PDFs, screenshots, and half-remembered Slack threads that nobody trusts enough to reuse.

One Person. One Throat to Choke.

If nobody owns your stats program, it doesn't exist. You need one person—a DRI (directly responsible individual)—who wakes up knowing that every public-facing statistic your company publishes is either credible or their problem.

This is usually a Head of Content, a Research lead, or someone in Data/Insights who sits close enough to marketing to care about external credibility but far enough from campaign execution to enforce standards. It's not the person writing the blog post. It's the person who decides whether the blog post is allowed to ship with that number in it.

The DRI's job is not to generate every stat personally—it's to build and enforce the operating system for how statistics get collected, validated, published, updated, and retired.

That means maintaining a source-of-truth database—a single spreadsheet or Airtable base where every published stat lives with its definition, original source, date validated, owner, approval status, and expiration date. It means setting the refresh cadence—quarterly or biannually, depending on how fast your market moves—so numbers don't go stale. And it means running cross-functional validation before anything goes live: if you're publishing a revenue benchmark, Finance signs off; if it's a product usage stat, Product Analytics confirms it; if it's a customer outcome, Customer Success validates the claim.

Without a single throat to choke, this work gets delegated into oblivion. Marketing assumes Data owns it. Data assumes Marketing owns it. And six months later, you're citing a benchmark that's two years out of date because nobody felt responsible for checking.

Validation Isn't a Formality. It's Structural.

The worst stats programs treat validation like a formality—a quick Slack ping to "check this looks right" before hitting publish.

Real validation is structural. It means the person who owns the underlying data has to explicitly approve the stat before it's allowed into the wild.

If you publish "our customers see a 40% reduction in churn," Customer Success should have signed off on the sample size, the timeframe, and whether that 40% is a median, a mean, or a cherry-picked success story. If you publish "the average SaaS company raises $3M at seed," your Research lead should be able to show you the dataset, the date range, and how "average" was calculated—mean, median, or mode all tell different stories.

This isn't about slowing down publication. It's about not shipping a liability. The five minutes it takes to get a Finance lead to confirm a revenue stat is nothing compared to the reputational cost of having a journalist fact-check you and find your number inflated.

Build a simple approval flow: before any stat goes live, the DRI checks the source-of-truth database. If the stat isn't already validated and logged, it doesn't ship until the relevant team confirms it. Once validated, it gets added to the database with an expiration date—usually six months to a year, depending on how fast your industry moves. When that date hits, the stat either gets refreshed or pulled from circulation.

Statistics Are Infrastructure, Not Ingredients

Here's the shift most founders miss: statistics aren't blog post ingredients. They're company infrastructure. If you're citing a number publicly—on your site, in a deck, in a press quote—it's now part of your brand's credibility surface area. And credibility, like security or compliance, requires ongoing maintenance.

That means your stats database isn't a nice-to-have—it's as essential as your pitch deck or your cap table. You wouldn't let your fundraising deck sit unchanged for two years. You wouldn't let your revenue model reference outdated assumptions.

So why would you let your externally cited statistics drift into irrelevance?

Set a recurring calendar event: every quarter, the DRI audits the database and flags any stat approaching expiration. If the underlying data still holds, mark it validated for another cycle. If the number has shifted, update it everywhere it's been published—or at minimum, stop using it in new content. If the methodology no longer makes sense, retire the stat and remove it from circulation.

This is unglamorous work. It will never be someone's favorite responsibility. But it's the difference between being a source other people cite and a risk other people avoid.

Here's What You Do This Week

Assign a DRI. If you don't have a Head of Content or Research lead, give it to whoever currently owns your external credibility—your Head of Marketing, your data lead, whoever would get blamed if a journalist called out a bad stat.

Have them start a simple stats database with five columns: the statistic, the source, the date validated, the owner, and the expiration date. Log every number you've published in the last six months.

Then set a quarterly review to refresh them.

That's the program. Everything else is just execution.