Xavier Gumara Rigol is the Head of Data at Manychat, where he leads the Data Platform and ML teams. With over 15 years in the data ecosystem, he has been managing data teams since 2016. His work focuses on data-product convergence, data platform engineering, data leadership, and organisational transformation. He is the author of Data as a Product Driver: Strategies for Aligning Data and Product Teams to Transform Organizations (Apress, 2026).
We’re thrilled to feature his insights on Modern Data 101.
We actively collaborate with data experts to bring the best resources to a 20,000+ strong community of data leaders and practitioners. If you have something to share, reach out!
🫴🏻 Share your ideas and work: community@moderndata101.com
*Note: Opinions expressed in contributions are not our own and are only curated by us for broader access and discussion. All submissions are vetted for quality & relevance. We keep it information-first and do not support any promotions, paid or otherwise!
If you work in data or product roles in modern organizations, you probably know that the relationship between data and product functions is very important for success.
A divide between these two functions costs organizations money, speed, and a competitive advantage.
Such a divide can be exemplified by data teams spending weeks building dashboards that nobody asks for or uses. You also see it in product managers who don’t feel ownership of any data-related topic; for example, when critical data goes missing for analysis because the features that got released didn’t have proper tagging.
Throughout my career, I’ve lived through all of this in the different companies I’ve worked at. I spent the first years of my career as the person whom product teams requested new fields to be added to the data warehouse. I also built the dashboards and answered the ad hoc questions.
Later, I led service provider data teams that created bottlenecks everywhere while the product teams remained very data illiterate. Also, I’ve watched companies struggle with AI initiatives because their data foundations were not ready.
So after almost 15 years at the intersection of data and product, I wrote a book called Data as a Product Driver 🚚 about the strategies to make data and product functions collaborate efficiently.
In summary, the core insight of the book is very simple: companies that successfully make data a driver of product development do so by implementing two fundamental changes:
Forming autonomous outcome-driven product teams and
treating data assets as products.
These changes are so critical that I call them the two pillars for data-driven product organizations. This article distills these two pillars.
If you are a CTO, CDO, CPO, or VP wondering how to actually get value from data in your organization, this two-pillar framework can help you. But before I explain it, you need to understand your organization’s data maturity so you know whether and when this guide will be useful.
Based on my experience at companies like Adevinta, Oda, and Manychat, I have learned that companies that create dedicated Data and Analytics orgs evolve through three phases of data maturity. They also do this while their data teams grow from 1-2 key hires into 10-20 people, with a mix of Data Engineering, Analyst, and Scientist roles.
The problem is that many companies get stuck in the second phase and never make it to the third and optimal one, where you minimize waste and are truly data-driven. The book and, to some extent, this article help you move from the second to the third phase. Let’s detail them next.
This phase is where most organizations start. They build the basic infrastructure, like data warehouses, ETL pipelines, and reporting tools. The focus is on collecting and storing data for reporting on what happened. While this is necessary work, it’s not strategic yet.
The second phase is where most companies live today. Data teams exist to serve business requests (Analytics Engineers build datasets and dashboards for them), and Data Scientists and Product Data Analysts help optimize the company’s product. They do so in a request-based system: the rest of the organization files tickets and looks for quarterly handshakes with data and analytics folks for specific projects.
The problem is that in such an operating model, data becomes a bottleneck. The requests queue grows, and product teams have to wait weeks for simple reports. Data professionals drown in ad hoc requests instead of strategic initiatives.
As said, I’ve been through this, and it’s exhausting for everyone. You’re always behind, always reacting, and data is hardly used to drive decisions. I’ve also experienced a better way, which I call “treating data as a product driver”.
In this phase, data stops being a support function and becomes a driver of product development. This is where the transformation of data and product functions happens. Data professionals are really part of cross-functional product teams and participate in product decisions from day one. Also, data is treated as a product.
Let’s explore these two characteristics in detail as they represent the two pillars for treating data as a product driver that I mentioned earlier.
The first pillar is about how you organize your product and data teams to work together, and it is one of the major step changes between treating data as a support function and treating data as a product driver.
When you treat data as a product driver, cross-functional teams focus on outcomes and operate autonomously with end-to-end ownership of a specific opportunity or user problem.
This might sound obvious, but it’s not how most companies work. Most data teams are organized by function: data engineering, data science, product analytics, etc. Each function has its own backlog, priorities, and leadership. When product teams need something from data, they file a request to the data team and wait.
The alternative is organizing around customer problems instead of technical discipline. The hardest part here is that you also have to do this together with product, engineering, and UX functions.
You need to form cross-functional teams that own specific problems end-to-end, with clear accountability, for example, user retention or activation. Because of the cross-functionality, you need hard buy-in from all leadership to work like this.
Advanced companies with leaders who have gone through this transformation in the past already start operating this way. For the rest, there are several strategies that you need to fulfill to achieve this; I detail them as follows.
Outcome-oriented measurement means that you stop measuring success by the features that you shipped, the dashboards that you built, or the queries that you answered (which are the outputs). Instead, you measure the business results that your data work has enabled (the outcomes).
You don’t celebrate launching a new Machine Learning model if it doesn’t move any product metric. The ML model is the output, and the outcome (the metric to move) probably was never defined.
This shift also changes how you plan the work because, instead of starting with “What should we build?”, you start with “What business result are we trying to achieve?” The answer determines what you need to build, and perhaps you sometimes need nothing at all (see “product discovery” as a strategy under Pillar 2 for more on that).
Outcomes need to be owned by cross-functional teams. A best practice is to create a company metric tree and assign each different team to own a specific metric they are tasked with moving (i.e., the activation team owns sign-up conversion).
One challenge with this strategy is that you need to hire the right people for this setting, because when you organize by function, you optimize a lot for technical experience (who can deliver the request the fastest).
But here, you need people who are comfortable owning and understanding more of a specific business problem like customer retention, pricing optimization, or onboarding. They also need to be comfortable with roadmaps being a list of problems to solve and ideas to validate, not a list of features to build.
Finally, you need to learn to distribute data knowledge across the organization. Product managers need to understand the basics of data and even the results of an A/B test.
Data professionals need to get much more depth in understanding the business domain they are working with. Also important, and often neglected, software engineers also need to care about how data is captured and how this data flows for analytics and for building products that are based on data.
It also means you should have a strong data platform team that provides infrastructure and different capabilities as-a-service, such as data quality, data privacy, cataloging, or the more recent natural-language-to-insight type of AI tools.
This pictures an organization where cross-functional teams should be able to create dashboards, reports, machine learning models, data quality test suites, etc., on their own, and the platform team exists to enable that.
To make this a bit more concrete, let’s look at an example. Imagine, for example, a company that is willing to improve the onboarding flow of their digital product. If the company operates by treating data as a support function, the product manager responsible for onboarding would file a request to the data team for a funnel analysis of the sign-up flow.
This would usually return as a dashboard or notebook with the research done by the data team. The product manager would review this and, if improvements were needed, file another request. Nobody is really owning the problem here, if there is any.
In contrast, in a company that treats data as a product driver, the product manager and the data analyst would be part of the same team.
Before building anything, they would look at what the problem actually is and what they are trying to improve (often a metric). For example, they would first set a goal to increase the sign-up flow from 35% to 40% within the next three months, and then everyone would be working against this same goal.
The data analyst is not just tasked with building the funnel, but with first understanding the problem and identifying where the drop-off happens. She needs to partner with UX and product managers, as well as software engineers, to check that the funnel is properly built at every step and, if not, fix it. The whole team proposes ideas to improve the sign-up flow, then validates them and chooses which ones to implement based on their expected impact.
Now, let’s move to the second pillar in the next section.
The second pillar is about how you manage your data. When data is treated as a support function, most companies see data as a by-product of the business.
However, when data is treated as a product driver, you need to have the tools and processes to ensure that data assets are treated as actual products themselves.
This means having clear consumers in mind, clear ownership, and the responsibility to maintain them through their life cycle, which means that if needed, somebody is accountable for actually retiring the data product if no longer needed or used.
Similar to what I have explained in pillar #1, here are the strategies that are important for treating data as a product and that I think are often neglected by senior leadership and upper management, but you should really know about.
Data product thinking means that a data product is not just a table in your analytical warehouse or a dashboard in your BI tool. It is that, yes, but it also must have clear documentation, be discoverable, and be of high quality.
These properties are often ensured thanks to a couple of strategies:
Clear ownership so that if something breaks or is no longer used, the person responsible for fixing it is clear.
A set of tools provided by the data platform team that make sure quality, documentation, and privacy management (to name a few requirements) are enforced programmatically according to the company standards.
For any product that uses data, you shouldn’t release it to your customers without first validating that it solves a real user problem. This is what idea validation means. You must use product discovery techniques like user research, A/B testing, fake door tests, etc. in order to build only what is going to have an impact.
In the past, I’ve seen teams spend months building recommendation systems or dashboards that nobody asked for. That’s why this validation step is important, because it prevents this waste. And you must use the outcome-oriented measurement from the previous pillar to show the impact a data-driven product has with the metrics that you have defined.
Finally, when you build a data product, you need to consider how it will be maintained, updated, and, if necessary, eventually retired. Datasets, dashboards, or recommendation systems that were created one or two years ago might become stale at some point.
Based on my experience, this life cycle question is one that most teams skip because they are used to working in the way that they build something, deploy it, and then move on to something else.
To fix this, on one hand, you need to make sure every data product is owned.
On the other hand, your data platform team needs to provide cross-functional teams with monitoring and alerting tools to check quality and usage and make the right decisions about when to update, duplicate, or retire data products.
Let’s look at an example of a company that wants to improve e-commerce conversion rates with personalized recommendations. When data is treated as a support function, the product manager just files a request to the data scientists and says to them to build a recommendation engine. Then the data team spends weeks developing an ML model, deploys it, and moves to the next project.
In contrast, when data assets are treated as products, the team starts with validations and product discovery before writing any code.
This means the PM, the data scientist, and perhaps a UX designer first research what user problems recommendations actually solve and which metrics they are trying to move.
Once they have a clear idea of where to start, they can test mockups, do user interviews, and maybe launch an A/B test before committing to the final ML model. Only if the ML model does not hurt any important metrics do they build the full recommendation engine.
I truly believe that if you have implemented these two pillars, you’re already better positioned than most organizations to take advantage of what generative AI makes possible today.
On one hand, being outcome-oriented and operating with a problem-centric model is still as relevant as it was before the advent of generative AI.
On the other hand, AI is and will change the composition of teams, making them smaller and functions converging. Even some functions can be taken fully by AI agents now (like writing SQL queries out of natural language). I’ve experienced teams owning more capabilities than they used to because they are able to do more with generative AI than they were doing before, for example.
Generative AI and agentic workflows have also made it very important to have good documentation on your data, aka treating data as a product. If you have been living by the data as a product thinking principles (documentation, written governance rules, glossary,…), you probably have already seen all these efforts pay off. Other organizations are still sorting out how to make AI Analytics Agents to answer data questions with high accuracy
To finish this article, let me share that I firmly believe data is becoming a skill more than a set of specific roles (Engineering, Analytics, Data Science). Generative AI is accelerating that even more.
If you have read so far, you probably have the responsibility in your organization to drive this change, so I encourage you to act on it. Otherwise, your data teams will become obsolete in the next few months.
It is true that shifting from data being a support function to data being a product driver might take months and sometimes years. It requires reorganizing teams, changing how you measure success, and treating data as a product, but the alternative is staying stuck in phase two, where data is a bottleneck, product teams are frustrated, and AI initiatives fail.
My suggestion is to not do it all at once, but start with one team, one problem, or one data product, then prove it works, and then expand. The two pillars give you a framework for where to focus depending on your bigger pains today, but the implementation should be incremental and step by step.
If this framework resonates, I go much deeper in my book, Data as a Product Driver: Strategies for Aligning Data and Product Teams to Transform Organizations (Apress, 2026). It covers the complete transformation with implementation guidelines, maturity models, and practical examples.
If you are navigating this transformation, I would love to connect. Find me on LinkedIn or drop a comment below.
If you have any queries about the piece, feel free to connect with the author(s). Or connect with the MD101 team directly at community@moderndata101.com 🧡
Got questions? Find Xavier on LinkedIn or drop a comment below. 💬
From the Modern Data 101 Team 🧡
A full traceability framework helps you track agentic decisions end-to-end. A single bad reasoning step can cascade through five more steps, each one logging a clean success.
And the stats back this up: 45% of executives say they can’t actually see how their AI agents are making decisions. That’s flying blind on autonomous systems making real calls in production. Start tracing AI decisions and outcomes with the AI Observability Framework: An End-to-End Enterprise Stack & Guide for 2026.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.