The simple another to all data problems: Build a data product - best served on your data mesh

Yeah, as if this all would be so simple.

Building internal data products is hard - period - but for me, it is the best way to make sure that your data team is:

• know for more than just dashboard

• helps directly to generate more growth

• saves 1000 hours throughout a year

• enables other teams to shine and don’t waste time by staring at numbers

That sounds quite promising. Doesn’t it?

Why do I write about internal data products?

Honestly, this substack was quite a journey. Many people I know have a data substack, and they write wonderful things. Some of them even every week. And I read a bunch of them. And I was a bit envious. About their thoughts and writing habits, but most of all, they found a topic to write about (beyond just data).

Because I had no idea what my topic would be. I have plenty of them, too many. One of my core topics is data collection, creation, or, as most people know it tracking design. But I have covered this already in my courses.

In the end (after ten months of random thoughts) it was not that hard.

I have two areas I am passionate about: product & data.

My professional career started in product at a time when we haven’t called it product yet (at least not in Europe). Product management was a marketing discipline and would be called product marketing today. I started officially as a project manager (the catch-all phrase when you don’t know how to name things).

The official term product manager or product owner came later when I started at Audible and had the opportunity to start my job with a one-week workshop by Marty Cagan in the Audible HQ in Newark. It would be a vast understatement to say you could start worse.

Marty implemented many things into my head that would shape my journey in the product (and data). Like “the biggest threat to a product manager is to fall in love with an idea,” you need to test it as early as possible. I fell in love plenty of times but knew about the testing. That saved so many hours.

Data has always played an essential part in my product work. First, because I love to work with numbers - they calm me down. And I hated “audience of one” opinions from day one. So I wanted to do something to measure against it.

At some point, I officially switched from product to data. But you can leave product, but product never leaves you.

When I could, I applied product thinking to all data projects - it was still a rare case. Most of my projects were clearly scoped and ended with a delivery of a pipeline, tracking, or dashboard. But when I had the opportunity to shape the delivery and what we build, we made a significantly better impact.

But to be true - most of our time was dedicated to solving technical issues. Getting data in the right shape to the right place in a scalable way was (and still is) pretty hard.

Today I see one significant advantage - data tooling has advanced significantly and therefore frees up energy and resources to approach data from a product perspective.

It’s basically day one.

Building internal data products is not something new. Plenty of teams have been doing this for years. But these are just few. In 98% of all setups, the data team delivers one data product: a dashboard. That’s it.

My motivation is to just change that. Get data teams beyond being simply a dashboard factory run by Jira tickets.