The Case for External Data: Why Sharing Insights Is Harder Than Sharing Files

A conversation with Solomon Kahn, Founder of Delivery Layer

For those who love to read, this blog post summarizes an episode of the Data Culture Podcast; that being said, we definitely recommend listening to the episode!

The Most Important Data Leaves the Building

Most use cases in data are internal, and for good reason. When you go from zero to one in data, you’re taking the information that exists across your company and using it to make better decisions. The tools, the talent, the investment — nearly all of it points inward.

But Solomon noticed something about the data that has to go the other direction. External data, the data that leaves your organization, is some of the most important data in your business. Unlike internal data where you’ve got tons of it, some useful, some not, you’re not sending data outside your company unless you absolutely need to. Either because you’re a data business like Nielsen, where the product is the data itself, or because customers and regulators are driving the requirement.

The problem: the tools built for internal analytics were never designed for this. And when companies try to use them for external delivery, things fall apart.

Sharing Data Is Not Sharing Insights

Solomon is careful to draw this line. Sharing data has plenty of solutions. You can put a zip file on a website, set up a cron job to an S3 bucket, stand up an FTP site. If you don’t care about data privacy, account management, permissioning, or consumer experience, those work fine.

But the reality of what most businesses need when sharing externally is much more. They need dashboards. They need permissioned file deliveries where different customers get different slices. They need APIs. And when you get into real-life use cases, you need all three, because here’s the core insight: you as the data creator don’t get to control how other people want to consume your data.

It’s like Walmart telling suppliers how things are going to work — if you have that kind of power in your market, fine. But if you’re on the other side and you need customers to have a good experience, suddenly meeting them where they are is your problem.

And where they are varies wildly. Hedge funds are notorious for wanting raw data sets, just hand it over and they’ll extract their own insights. Corporates, on the other hand, don’t want to put a data team on a data set to figure out relevance. They want you to tell them how this data matters to their industry and keep them updated. Same data, completely different delivery requirements.

Solomon reaches for the drill bit analogy: people don’t buy drill bits, they buy holes. And they don’t even really want holes, they want whatever they’re trying to build that needs a hole. For data, that means delivery lives on a spectrum between raw data and prepackaged insights, and most companies need to serve the full range.

The Tools Are There Internally. Externally, It’s the Wild West.

Solomon’s read on internal tooling is generous but clear: the tools are largely there. Ever since Redshift made it possible to put two petabytes in a data warehouse without managing infrastructure, a lot of the technical barriers dropped. The modern data stack works. The limiting factors internally are less about tools and more about how we use them.

External data is a different story. Snowflake, Databricks, BigQuery, they’ve all built data sharing features, and the adoption, even with severe limitations, is proof of how much demand exists. But those solutions only work when your customer happens to be on the same data warehouse. If you’ve got 20% market share, you’re solving the problem for 20% of your customers. The other 80% are out of luck.

And even when data sharing works technically, it’s still sharing data, not insights. An insight typically requires a formatted visual, a narrative, context that helps someone act on what they’re seeing. That’s a fundamentally harder problem.

The Complexity That Kills at Scale

Solomon has seen what happens when companies get further along in the external data journey, and the pattern is consistent: it starts simple and gets complicated fast.

A company builds a product-facing insights portal on an embedded BI platform. Before they know it, they’ve got 500 pages and it’s slow. Then they need a separate API platform. Then, and this becomes the biggest team of all, they need a group managing shared permissions and entitlements across both systems so customers don’t get the wrong data.

Your first two customers? Not a problem with any off-the-shelf solution. At scale, the complexity of managing account structures, permissioning, and multiple delivery formats becomes the dominant challenge. That’s why most companies that know they’re going beyond a handful of customers end up building custom.

Sid points out that government runs straight into this wall. Nearly every state or large city he’s worked with has a custom portal project in the works or delayed. Agencies genuinely want to share data with the public, but the legacy tools, Socrata, now Tyler Tech, only support publishing raw data, not insights. And when someone retires and nobody notices the data hasn’t been republished in six months, what Sid calls the “Willie Effect,” the whole thing quietly breaks down.

Data People See Things No One Else Can

Solomon frames external data not just as a delivery problem but as a strategic opportunity for data teams. Data people, by the nature of what they do, see opportunities that no one else sees. They’re looking at data in ways nobody else in the organization is. That applies internally, but it applies externally too.

The pitch is straightforward: if you as a data team can build something that drives new revenue for your customers, you become more important to the business in a way that internal work alone can’t match. And the spillover is real, the level of business understanding required to build external-facing data products massively improves your internal operations.

Solomon shares a moment that captures this. He was sitting in a beta demo meeting where a customer saw their new analytics delivery for the first time. The reaction was immediate: now that we have this data, we can change our internal processes, we can better manage our vendors. They left the meeting with three or four opportunities to expand the contract. That, Solomon says, is the payoff. And it’s uncapped. In baseball, the maximum you can score on any at-bat is four runs, a grand slam. In data, if you come up with an insight that lets your business start a billion-dollar revenue division, there’s no ceiling.

Business Acumen at the Level of SQL

The conversation turns to what makes data professionals effective, and Solomon lands on something sharp: business acumen is at the level of SQL. In the same way you can’t interact with data without SQL, you can’t interact with the business without business acumen. And in the same way there are various degrees of SQL skills, there are various degrees of business understanding.

There’s no single right data person. Everyone comes in with a different mix, and every role requires a different combination. If you’re interfacing with executives, strong business acumen is essential, as long as you can also figure out the technical side. Otherwise you’re just another person who can explain the problems but can’t independently solve them.

Both Solomon and Sid land on the same conclusion: data is a support function. That’s not diminishing, it’s clarifying. Product has features to build. Sales has revenue to bring in. Marketing has leads to generate. Data is there to help all of them do better. And that means data literacy should start with data people becoming more literate in the business, not the other way around.

You can’t just build a dashboard and expect impact. You need to make sure that dashboard is being used effectively. That second step is often missed.

The Industry Brand Problem

Solomon closes with a candid read on where the data industry stands. Companies have invested heavily in data with big expectations that didn’t always get fulfilled. Not because people didn’t work hard, data work is chaotic, but because the results haven’t been consistent.

The way he frames it: data professionals all win and lose together. Every success story shared at a conference or carried to a new job raises the industry’s brand. Every failure lowers it. Right now the perception is inconsistent performance, some real wins, some wasted money.

Getting that brand from inconsistent success to consistent success is one of the most important things the industry can do. And Solomon believes external data work, where impact translates directly to revenue and customer outcomes, is one of the clearest paths to proving that data teams are worth the investment.

This blog post is based on a conversation between Sid Atkinson and Solomon Kahn on the Data Culture Podcast. Solomon Kahn is the founder of Delivery Layer. Connect with him on LinkedIn.