I’ve been a (marketing) data analyst since 2003, after working in IT for about five years. For the first few years of my data career, the focus was on marketing data, then it broadened, but I’ve been a data analyst for over 20 years.
These days, I introduce myself as “Managing Director of i-spark and a data analyst.” A significant number of my colleagues also have “data analyst” in their job descriptions.
The meaning of the job title and the role of data analyst have always been a point of contention, with different companies interpreting it differently. There was also a period when many data analysts suddenly became data scientists.
But in recent years, this job title has been completely changing, especially due to the rise of LLMs (AI) and what people expect from them.
“The role of data analyst is disappearing” is something you hear more and more often. While I don’t think we’re there yet, I definitely see the role evolving. Not surprisingly, the content of my own role and that of my colleagues has also evolved in recent years. Often towards analytics engineering, sometimes also towards analytics & BI consultancy.
So far, I haven’t had any problems with this; after all, it’s about the content, not the label you put on it. Personally, I don’t have much of a thing about job titles.
However, I’m now really noticing a discrepancy between what I understand by them and how I think the market perceives them.
That’s why we recently reviewed the roles we actually perform, our functions, and the different types of expertise we offer. To ensure they remain in line with reality, at least as we see it and as we believe a large part of the market sees it.
As I said, I don’t have much of a thing about titles. It took me years before I could say the word “director” without stuttering. But logically, during this process, I started thinking about what my role in the data field actually is, now that “data analyst” seems to have become so controversial.
And this is actually quite exciting, because I’ve discovered something entirely new.
With over 20 years of experience in the data field and as the director of a boutique data agency, I discovered that what I do is actually something I hadn’t really envisioned before, and which is a recognized role: Data Product Lead.
What I actually do
A large part of my work revolves around translating business questions into logical data models and data products that can be used for data insights (dashboards and analyses), AI agents, and operational processes. As a coherent, consistent whole that makes sense.
I design conceptual models. I provide structure. I determine the meaning of data. I ensure consistency across domains. I consider where in the data pipeline logic could be incorporated, the consequences of the various options, and ultimately, what, within the given context, is the best choice.
And then there’s the question of whether such a decision can be made within our own data team or whether it needs broader support and should therefore be discussed with the client. That’s always a challenge: too little consultation is not good, but too much is certainly not optimal either.
To make those choices, you need a clear view of where logic should live in the data stack. We (and many others) believe that logic and business rules should be incorporated as much as possible into your (composable) data hub, and that BI tools should primarily visualize. That is a solid principle, but in practice, things can get messy. Many roads lead to Rome, and often you can solve certain issues in multiple places.
Then you have to make choices or offer advice. That requires domain knowledge, experience, and a sense of long-term impact.
It turns out that this is exactly the area of expertise of a Data Product Lead.
The role in relation to other functions
Because the role is relatively unknown, confusion is definitely present about which role aligns with a particular issue. And of course, there are nuances; as with all data roles, there’s no single, hard-and-fast rule.
Yet, there are differences and similarities with other comparable roles.
Data Product Lead vs. Data Architect
Overlap: Both touch on data modeling and domain structure.
Difference: The Data Architect focuses primarily on technical aspects: which layers are needed (bronze/silver/gold), how to handle history, storage, and performance.
The Data Product Lead focuses on meaning and semantics and requires domain knowledge to determine what data should mean for analytics, AI, and processes.
Data Product Lead vs. Data Strategist
Overlap: Both understand the business needs and direction.
Difference: The Data Strategist formulates the path; the Data Product Lead makes that path concrete by designing data products, models, and semantics that are actually feasible.
Data Product Lead vs. Data Product Owner
Overlap: Both roles focus on data products and delivering value.
Difference: The Data Product Owner drives the process: backlog, priorities, and collaboration with teams.
The Data Product Lead manages the content: the logic, model, semantics, and consistency of the product.
Data Product Lead vs. Analytics Engineer
Overlap: Both work on data models and move through the same layers in the chain.
Difference: The Analytics Engineer technically builds the model; the Data Product Lead determines the content, meaning, and structure of that model.
My new role: Data Product Lead
I don’t need a new job title just for the sake of it. It’s about making it accurate and better reflecting the work I do now.
“Data Product Lead” best describes my current work: shaping data in a way that is logical, meaningful, future-proof, and usable.
This automatically brings me into contact with other roles, such as Data Architect, Product Owner, Analytics Engineer, and Analytics & BI Consultant. That’s not surprising. A Data Product Lead moves between these disciplines. You need to understand all these roles well enough to make good choices and design models that are consistent across the entire chain.
And that’s precisely why this title works for me. It doesn’t say anything grander than necessary, but it does say exactly what needs to be said. It suits the profession, our way of working, and how we view data. And with that, I can say goodbye to my position as a data analyst with peace of mind.
