Kill your data team: why product teams should own data

"We need to build a Data Center of Excellence." These words have launched a thousand failed data initiatives. Nothing makes me more skeptical than the term "Center of Excellence" - it's corporate-speak for "expensive silo that will struggle to deliver actual value."

If you're reading this, you've probably experienced the typical data team dysfunction:

• endless request queues,

• insights that arrive too late to matter,

• and the constant refrain of "we're working on infrastructure" while business questions go unanswered.

I’m arguing here for an embedded approach, one that dismisses any central arguments for “a central team is more efficient” and instead starts with a simple idea: central data teams mostly don’t deliver, so why not start on the other end?

---

If you only have 5 minutes: here are the key points

• Centralized data teams often become bottlenecks, delivering delayed and misaligned insights.

• Embedding data professionals directly into product teams boosts speed, context, and business impact.

• Real-world examples from companies like HubSpot, Booking.com, Snaptravel, and Stash show that decentralized or hybrid models deliver superior results.

• Transitioning effectively involves hybrid approaches, domain ownership, strong communities of practice, and redefined central data functions.

• Tools like dbt are valuable but should support your org model—not dictate it.

---

Let's explore why some of the most innovative companies are dismantling their centralized data teams, what they're building instead, and how you can make this transition work in your organization.

How centralized data teams became the problem, not the solution

Before we look at what works, let's understand why traditional data teams fail. (According to me, and some other sources)

Have you ever played the telephone game as a kid? Whisper a message from person to person and see how garbled it becomes by the end. That's essentially what happens in most companies:

1. Product team has a question about user behavior

2. They submit a ticket to the data team

3. A data analyst who doesn't understand the product context tries to interpret the request

4. After several back-and-forths, they deliver an analysis

5. The product team says, "That's not quite what we needed..."

6. Repeat until everyone is frustrated

Meanwhile, dbt Labs and the "modern data stack" crowd keep pushing solutions that centralize data work further. They've convinced you that the path to data excellence is through more layers, more abstraction, and more specialized roles. The result? Your company now has data engineers, analytics engineers, data analysts, and data scientists—all working in separate teams, all with handoffs, all creating friction.

Here's the uncomfortable truth: centralized data teams incentivize the wrong things. They optimize for perfect data models rather than business outcomes. They value technical elegance over speed of insight. They encourage building impressive data infrastructure rather than answering the questions that matter.

How real companies killed their data teams (and what they built instead)

Let's look at how four companies rejected the centralized model and restructured their data functions to deliver actual value.

HubSpot: 120 "data analyzers" distributed across the business

HubSpot dismantled their centralized Business Intelligence team as they scaled to 3,000 employees. Instead of a single team handling all analytics, they embedded analysts within each department while maintaining a core data-engineering group for infrastructure.

The result? About 120 "data analyzers" now work directly alongside their business colleagues. These analysts aren't just serving the business—they're part of it, understanding context deeply and responding faster to questions.

What makes this work is that HubSpot maintained a central team for data engineering and infrastructure while pushing analytics capability closer to decision-makers.

Ironically, this study is published on the getdbt blog, the tool driving a modern data stack which relies mostly on centralized data teams and infrastructures.

Booking.com: From central data science to embedded product squads

Booking.com, one of the world's largest online travel platforms, intentionally moved away from a single centralized data science team. In their embedded model, each product team has its own data scientist working alongside engineers and product managers.

This change was driven by the need for speed and relevancy. A centralized team had become a bottleneck, and data scientists lacked the context to make meaningful contributions.

After embedding data scientists into product squads, Booking.com saw greater agility and business alignment. Teams now run continuous experiments and rely on their embedded data scientists to interpret results and suggest optimizations in real time.

Interestingly, Booking.com found that embedding worked best when combined with central guidelines (for experimentation, tooling, and metrics definitions) and a "guild" structure for data scientists to share knowledge.

Snaptravel: Five structures in nine months

Snaptravel, a travel startup, went through a fascinating evolution—trying five different data team structures in just nine months:

1. Initial Embedded "Growth" Team: Analysts assigned to different departments

2. Agile Central Team: Analysts pulled back into one team for better collaboration

3. Full-Stack Pods: Merged data engineers and analysts into combined pods

4. Domain-Aligned Pods: Split into smaller pods focused on specific business areas

5. Hybrid Domain-Based Structure: A senior data team member serves as "domain lead" for each key business area

Their final model hit the sweet spot: data experts remained one organization but worked in domain-focused units embedded with business stakeholders. This structure gave data team members true ownership of outcomes rather than just completing tickets.

For example, the "Bookings" domain data lead owned all analytics and data projects driving booking conversions, working continually with product managers in that area. This ownership boosted motivation and ensured that analyses were acted upon.

Stash: Data scientists in every product squad from day one

Stash, a fintech startup focused on personal investing, didn't disband a central team—they skipped having one altogether. From early on, they embedded data scientists into every product squad.

Each squad (onboarding, transactions, growth) had a data scientist as a core member, involved in sprint planning and product roadmap discussions. These data scientists would identify user drop-offs, hypothesize causes, collaborate on experiment design, and evaluate results alongside their squad.

The results were dramatic. In one case, embedded data scientists identified the root causes of failed payments and informed product changes that reduced return payment incidents by 90%. This not only solved a critical business issue but improved their app store ratings and reduced user acquisition costs.

The speed of insight-to-implementation improved dramatically because there was no hand-off between a central analyst team and the product team—the data scientist who uncovered an insight was sitting with the developers who could act on it immediately.

After all of these examples two things show:

1. Central data teams suck and should not be the default solution!

2. A large degree of decentralization, of embedding data people into the business functions, into the product teams is needed to allow for speed and proper alignment

The organizational antibodies that still kill data value

Why do centralized data teams persist despite their failures? Because large organizations develop antibodies that protect the status quo:

1. The expertise fallacy: "Data work is too complex for product teams to understand"

2. The scale illusion: "Centralized teams are more efficient" (they're not when you count the true cost of delays and miscommunication)

3. The control bias: "We need governance and standardization" (which often means bureaucracy that slows everything down)

4. The skill mismatch: Data people still are trained in the “old world.” And it is particularly hard to adjust to a decentralized world where business and domain knowledge is a top 1 priority - making it hard to find even a test set of people to try this out.

All of these are solvable problems, as our case studies show. But they require acknowledging that the goal isn't data excellence—it's business excellence enabled by data.

How to transition from centralized to embedded data teams

If you're convinced that embedding data expertise into product teams is the way forward, here's how to make the transition:

1. Start with a hybrid approach

Don't disband your entire central team overnight. Begin by keeping core infrastructure and governance centralized while embedding analysts and data scientists into product teams.

HubSpot, ResearchGate, and Snaptravel all landed on hybrid models that balance centralized infrastructure with embedded analytics. This maintains data quality standards while pushing insight generation closer to decision-makers.

2. Assign clear domain ownership

Snaptravel's domain lead structure provides an excellent model. Assign a senior data person to each major product area with accountability for outcomes, not just completed tickets.

This person should be measured by product improvements, not data deliverables. Did their work drive more conversions? Reduce churn? Increase engagement? Those are the metrics that matter.

3. Create communities of practice

One legitimate concern about embedding is the loss of knowledge sharing and skill development. Address this by establishing communities of practice where data professionals across product teams can share techniques, tools, and learnings.

Booking.com's "guild" structure and HubSpot's central enablement function are good examples of maintaining cohesion without recreating silos.

4. Redefine the central data function

Your central data team shouldn't disappear (it doesn’t have to at least)—it should transform. Instead of being the bottleneck that handles all requests, it should focus on:

• Core infrastructure and data quality

• Training and enablement

• Cross-team coordination

• Governance and standards

Think of it as a platform team that empowers embedded data professionals, not a service team that does the work for them.

5. Hire and train differently

The skills needed for embedded data work differ from centralized teams. You need people who are:

• Comfortable with ambiguity

• Strong communicators

• Business-outcome focused

• Technically versatile

Stash found success by hiring data generalists who could handle both analytics and some machine learning, rather than hyper-specialists who could only do one thing well.

What About dbt and the "Modern Data Stack"?

Let's address the elephant in the room. Companies like dbt Labs have built impressive businesses around centralized data engineering and the "modern data stack." They'll tell you that you need analytics engineers, transformation layers, and complex orchestration. Yes, they also publish lots of studies on distributed teams, but if you take a close look, these example companies were all also locked in on a central structure by using dbt in the first place.

Here's what they don't tell you: all that infrastructure becomes vastly simpler when your data people sit with product teams. When you eliminate handoffs and context switching, you reduce complexity. When data professionals understand product context deeply, they can create more targeted, efficient solutions.

Does this mean tools like dbt are useless? Of course not. But they should serve your organizational model, not dictate it. Use these tools where they add value, but don't let them push you toward an organizational structure that creates more problems than it solves.

So what? The real-world impact of embedded data teams

When data professionals are embedded in product teams, several things change dramatically:

1. Speed increases - Stash went from insight to implementation in weeks, not months

2. Context deepens - Data people understand product challenges intimately

3. Ownership emerges - Analysis isn't just delivered; it's championed and implemented

4. Value improves - Work focuses on business outcomes, not data perfection

Most importantly, data professionals become happier and more fulfilled. Rather than being ticket-takers isolated from impact, they become core contributors to product success. They see their work changing the product, delighting users, and driving business results.

Questions for your organization

1. How many steps separate your data people from the product decisions they inform?

2. What percentage of data requests get implemented into product changes? (If you feel like you can’t find that number, let me tell you: it’s zero)

3. How long does it take from question to actionable insight in your company?

4. If you embedded your analysts tomorrow, what organizational "antibodies" would resist?

5. What's stopping you from trying a hybrid approach with a single product team as a pilot?

The answers might be uncomfortable, but they'll point the way forward. And if you're looking for a place to start, remember: you don't have to transform everything overnight. Begin with a single product team, a single embedded analyst, and a willingness to experiment.

After all, isn't experimentation what data work is all about?