“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford

That quote gets thrown around a lot. But most data teams haven’t truly understood it.

Data teams love structure. So they build elaborate systems to collect stakeholder requests - JIRA tickets, intake forms, prioritization workflows.

The assumption is simple: if the request is clear and complete, the solution will be too.

But here’s the real problem:
​Many stakeholder needs aren’t ready for a JIRA ticket - yet.

They submit what they think they want - usually a dashboard, with KPIs, filters, layouts, and drill-downs. On the surface, it may look like a great brief. But underneath, it’s often just a guess.

The data team gets the request. They build it beautifully.
They ship it.

And then… nothing. One person opens it for one minute and never uses it again.

Next week? Same cycle. New request. Same pattern.

And the team wonders:
​“What’s going wrong? We delivered what they asked for.”

The Root of the Problem: Users Don’t Know What They Need

Here’s the uncomfortable truth:
​Users do not know what the solution to their problem ist. And it’s not their job to know. It’s yours.

I have spent many years working across several disciplines. As a trained marketer, I learned about behavioral science.

Then, I broke into data and served as a data leader for 17+ years.

I also spent a significant amount of time in product management, served as a Chief Product Officer for a venture capital firm and learned a ton about user research.

Working at the intersection of marketing, data, and product leadership has taught me one very important thing:

People are bad at knowing what they want.

A business user might say:

“I need a dashboard with X, Y, and Z.”

But what they actually mean is:

“I need to understand why campaign performance is dropping so I can fix it before the next one.”

That’s a completely different thing. And it might not even require a dashboard.

If you’ve studied user behavior, or product management, this won’t be news.

But most data leaders haven’t. So they build faster horses when they should be building cars.

Proof from Business History: When Listening to Users Goes Wrong

Don’t just take my word for it. Let’s look at some famous examples from business history.

All these companies failed not because they ignored their customers - but because they listened too literally. Their users were lying to them - unintentionally.

→ Kodak​
They dominated film photography. Customers said they wanted better film, not digital cameras.
Kodak even invented a digital camera in 1975 - and shelved it.
They feared it would cannibalize their own film business.
​Result: competitors went digital. Kodak filed for bankruptcy in 2012.

→ Blockbuster​
Their customers said they liked browsing movies in-store. So Blockbuster doubled down on physical rentals.
They ignored streaming and subscriptions - until it was too late.
​Result: Filed for bankruptcy in 2010.

→ BlackBerry​
Business customers loved secure email and physical keyboards.
So the company focused on improving those - instead of adapting to full-screen smartphones and app ecosystems.
​Result: Apple and Android redefined the market. BlackBerry exited the handset business.

→ Nokia​
Customers loved simple, reliable phones. Nokia stuck with what worked - even when internal R&D pushed for smartphones.
They delayed too long. Lost to Apple and Android.
​Result: Sold to Microsoft in 2014 and disappeared.

→ Sears​
Customer surveys said people liked traditional department stores and big catalogs.
Sears doubled down on that model - just as e-commerce and specialty retail took over.
​Result: Too slow to pivot. Bankruptcy in 2018.

What’s the pattern?​
These companies did research. They did listen.
But they interpreted customer input too narrowly.

Customers described features.
Companies built features.
The world moved on.

Data Teams Must Think Like Product Teams

You’re not here to deliver dashboards.
You’re here to solve problems.

That means shifting how you respond to requests.
Here’s how most teams handle it today:

1. Business user sends detailed dashboard request
2. Data team builds exactly what’s asked
3. Dashboard gets delivered
4. Dashboard never used

Now let’s fix that.

New Approach: Product Mindset for Data

Start with a different principle:

“They own the problem. You own the solution.”

That means:

• You listen to the why behind the request
• You diagnose the real user need
• You understand what's the business goal behind the request
• You understand how they are solving their problem today
• You understand why their current approach is failing them
• You understand how their world looks like if they don't solve the problem
• You determine what data solution (if any!) will help

It also means:

You aren't allowed to tell them what their problem is, and in return, they aren't allowed to tell you what to build.

That might sound radical, but it works.

Tools to Go Deeper

If you want to get better at uncovering real user needs, study how product teams do user interviews.

A great starting point is the book The Mom Test .
It teache s you how to ask better questions and avoid being misled by polite feedback or overly specific feature requests.

Also, if this topic resonates, I go deep into it in my Flagship Masterclass:​
​“From Dashboard Factory to Business Partner” - where we dive into user interviews and specific questions to ask.

The Bottom Line

If your team keeps getting requests for dashboards that never get used, the problem isn’t the dashboards.

And it’s not the users, either.

The problem is the dashboard factory model.

Your users own the business problem.​
​You own the data solution.

Treat requests as signals, not orders.
And build your team around understanding, not just executing.

Stop listening literally. Start listening critically.

See you next week!

Sebastian