“People don’t buy the best solution. They buy the one they understand.”

Today, we’ll look at why great data teams still struggle with adoption and how you can fix it.

Why this matters

I learned the hard way that you can build the most advanced data platform in the world.

Perfect models. Clean pipelines. Beautiful dashboards.

And still fail.

In my first data leadership role, I did all the right things - but at the wrong time and place.

It cost me a promotion and it almost cost me my job.

The gap between success and failure is rarely technical.

It’s the gap between what stakeholders need and what they actually use.

The story: a perfect solution that no one wanted

Imagine this.

An artisanal baker moves from New York City to a small village. Population: 1,000.

He brings everything:

• Imported grains
• Wild fermented sourdough
• A $20,000 stone oven

He’s successful, respected, and passionate. His goal is simple: bring “real” bread to the countryside.

He opens his bakery.

People come in. They’re curious. Some try the bread.

But they don’t come back.

Meanwhile, an older baker down the street sells simple white loaves. No fancy equipment. No trends. By noon, she’s sold out every day.

She knows every customer by name.

She was worried about the new competitor.

She didn’t need to be.

Why?

Because the new baker built what he loved - not what the village needed.

The same mistake in data teams

At Rocket Internet, I saw this problem play out at scale.

When I joined to lead their data team, Rocket was the world’s largest venture builder, launching companies like Delivery Hero, HelloFresh, and Zalando.

The business model: combine startup speed with centralized expertise in areas like marketing, tech, finance, and data.

One standout success was Zalando - now the leading online fashion business in Europe.

They built a strong data infrastructure early on, including advanced marketing attribution. This allowed them to understand customer lifetime value far better than their competitors and confidently outspend them to fuel rapid growth.

Seeing this, I thought the path was obvious.

We decided to copy-paste Zalando’s data setup into all the new startups.

Our goal was to give every new venture a “best-in-class” data infrastructure from day one. They should have a world-class data setup before they even made their first dollar in revenue.

But it didn’t work.

Adoption was low. Teams didn’t use what we built. The systems didn’t stick.

We built the right thing for the wrong people at the wrong time.

Our solution didn’t fit the context these early-stage companies were operating in.

The core problem: starting with the solution

Here’s where things go off track.

Data teams often think like this:

• “We know what good looks like”
• “We’ve seen this work before”
• “This is the best practice”

So they start with the solution.

Instead of asking:
→ What problem are we solving right now?
→ How do people actually work today?
→ What constraints do they have?

They assume.

In the Rocket Internet case, my assumption was:

“These are all e-commerce companies. They even use the same tech stack. They must have the same needs.”

But they didn’t.

Early-stage startups are not smaller versions of mature companies. They are fundamentally different.

They move faster. They are less structured. They don’t need perfection - they need speed and clarity.

The “perfect” system became friction.

The missing bridge: want vs. need

Here’s the real challenge:

Your stakeholders rarely ask for what they truly need.

And data teams often build what they think is needed.

The gap looks like this:

• Stakeholders want → fast answers, simple tools, low friction, make more $$$
• They need → structured data, reliable pipelines, consistent definitions

If you only build for the “need,” you lose adoption.

If you only serve the “want,” you create chaos.

Your job is to build the bridge.

How to fix it: think like a product team

This is not a new problem. Product managers have dealt with it for years.

The shift is simple, but not easy:

Stop thinking like a builder. Start thinking like a product owner.

Here’s a practical framework you can apply.

1. Start with observation, not assumptions

Before building anything:

→ Sit with your stakeholders
→ Watch how they work
→ Understand their shortcuts and pain points

→ Understand whether data infrastructure is even needed or if their existing tools are sufficient

Don’t rely on what they say. Focus on what they do.

You’ll often find:

• Manual workarounds
• Spreadsheet hacks
• “Good enough” solutions

These are signals. Not problems to eliminate immediately but behaviors to understand.

2. Define the real problem

Avoid vague goals like:

• “Improve reporting”
• “Build a better data warehouse”

Instead, get specific:

→ What decision is currently slow or wrong?
→ What is the cost of that problem?
→ Who feels it the most?

A clear problem anchors everything.

3. Build for adoption, not perfection

A technically perfect solution that no one uses is a failure.

Instead:

→ Start small
→ Deliver something usable quickly
→ Iterate based on feedback

Ask:

• Can someone use this tomorrow?
• Does it save them time immediately?

Adoption is the first milestone, not completeness.

At Rocket Internet, we've been building for 3 months before the first user feedback. That's WAY too long!

4. Translate between worlds

You sit between two realities:

• Business users who want answers
• Data systems that require structure

Your role is translation.

That means:
→ Explaining complexity in simple terms
→ Packaging insights in usable formats
→ Gradually introducing better practices

Not forcing them all at once.

A simple test for your next project

Before you start building, ask yourself:

• Have I observed how this is done today?
• Can I describe the problem in one sentence?
• Will someone actually use this next week?

If you hesitate on any of these, pause.

Not to rethink everything, but to realign.

Bottom line

The baker didn’t fail because his bread was bad.

He failed because he ignored his customers.

The same happens in data teams every day.

You can’t “import” best practices and expect them to work everywhere.

You need to:

• Start with the problem
• Understand the people
• Build the bridge between want and need

That’s how you create data products that people actually use.

Cheers,

Sebastian