AI has made data availability and quality more critical than ever. As organisations move from reporting toward AI use cases, the biggest challenge is making data reliably available and usable at scale, without slowing teams down. In practice, many organisations struggle with this. Centralised data teams and platforms often become bottlenecks, unable to respond fast enough to growing and increasingly diverse data needs. In addition, central teams may lack understanding of data content and business context, which is a prerequisite for utilising data and getting value from AI. As a result, business units start building their own solutions to move forward, leading to fragmented data work and shadow IT while central data teams struggle to provide both enablement and control. The push toward data products is more often a response to this reality. However, many companies are struggling to start with data products in their organisation and end up building data products that bring more chaos than structure. When things don’t work, data products are easily labelled as a non-working or too complex concept and dismissed as just another passing trend. But our experience shows that when data products are approached by clearly defining the problem, understanding real users, and grounding both the concept and technology frameworks in concrete use cases, they deliver the value they promise.
A data product is a valuable, business-owned data asset that is shared with others through standardised ports. Data products enable faster and business-driven data development by decentralising the data work and ownership to the business. Data products are often seen as a high-maturity way of working with data, and for that reason, it is seen as an obvious further step for the data and AI transformation journey.
A common approach to start implementing data products is to start by technically building data products. Organisations invest in new platforms, define architectures, and standardise pipelines, expecting structure and speed to follow. While these initiatives often improve technical capabilities, they rarely solve the core problem. Data products end up being shaped by platform constraints rather than business needs. Instead of enabling faster, parallel progress, technology-first approaches often recreate centralised bottlenecks just on a more modern stack.
Some advanced organisations recognise that moving toward data products requires more than individual initiatives or technical changes. They understand the need to define a shared way of working, a foundation that addresses data products holistically across strategy, business value, people and roles, technical capabilities, and governance. The intention is to create a model that guides the organisation on how data products are owned, built, governed, and evolved across the organisation. Too often, however, this conceptual work remains disconnected from everyday work and operations and fails to be grounded in practice. Without being tested and refined through real use cases, concrete responsibilities, and actual decision-making, the model stays abstract and theoretical, convincing on paper, but ineffective in guiding day-to-day work. This is why it is critical to start testing the data product concept early, iterating it through real use cases while iterating the concept in parallel based on the learnings. Only through this kind of early, practical experimentation can a data product evolve into something that works in practice.
Data product initiatives rarely fail because of one single mistake or wrong decision. Instead, the same patterns tend to repeat across organisations, regardless of industry or maturity level. Recognising these pitfalls early is critical, not to avoid data products altogether, but to approach their implementation more deliberately. Below, we outline the most common pitfalls we see in data product initiatives, together with practical guidance on how to address them.
Typical pitfalls of data products
1. Data products are owned by IT and are treated as technical deliverables, not living products, and lifecycle thinking is missing.
- How to overcome: Engage the business from the very beginning and shift ownership to the business. Treat data products as real products with a clear lifecycle, while IT and data teams provide the necessary technical and governance support.
2. Data product ownership and other data product related roles haven’t been defined or embedded in everyday work.
- How to overcome: Embed roles into existing ways of working, and tie roles into concrete tasks and decisions. Ensure the data product owner has the needed mandate. Define and shape roles together with the people the role is designed for through pilots or experiments.
3. Organisations try to design data products using traditional, technology-centric data development approaches, which makes it difficult to adopt the new, product- and value-driven way of thinking that data products require.
- How to overcome: Start data product design with a concrete use case and a need that someone actually owns and uses. This anchors thinking in value and breaks the habit of starting from tables, schemas, and pipelines.
4. Data products are built without a clear definition of what value they are expected to create, making success hard to assess and investments difficult to justify.
- How to overcome: Tie the data product concept to the business strategy and objectives, and each data product to a measurable business outcome.
5. Organisations try to scale the data product concept before validating a single data product for real use
- How to overcome: Prove the concept with a small number of data products with real use cases and teams. Learn from practice where friction emerges and use these learnings to understand what needs to be supported, fixed, or built before scaling. Scale only what actually works in practice, not what looks good on paper.
6. Data products are approached as a technology initiative, even though it’s a fundamental change in how people think, work, and collaborate around data. Existing processes, decision-making practices, and organisational assumptions are left untouched, and change management is overlooked.
- How to overcome: Treat data products as a change in operating model and ways of working. Actively manage the transition by addressing processes, roles, decision-making, and organisational readiness, and continuously support implementation with clear change management practices.
7. Data products are built without understanding their users and without taking into account the usability aspects. Also, cross-domain needs are overlooked, leading to difficulties in reusability across the organisation.
- How to overcome: Design data products from a user perspective, define and understand different user groups (eg, their needs, challenges, and maturity), involve them, ask for feedback, and track usage of the data products. Create cross-domain functions/forums to understand the needs of the rest of the organisation.
8. Federated data governance can be seen as challenging and risky when organisations move from a traditional, centralised governance model to a data product model that distributes ownership and development across the organisation. This shift can create a perception that control is lost, as monitoring, compliance, and policy enforcement no longer happen through centralised oversight in the same way.
- How to overcome: Design governance into the data product concept from the start, using governance by design principles. Implement policies, controls, and compliance requirements as code, embedding them directly into data product processes, platforms, and standards so that teams and users are guided toward compliant choices by default, without relying on manual enforcement or after-the-fact control.
9. Existing tools and processes are optimised for traditional project-based data delivery, making continuous product thinking, ownership, and lifecycle difficult.
- How to overcome: Treat the platform as a product too and assign product ownership to the data platform itself, with clear users, roadmap, and success metrics. Use data product contracts to decouple developers and users. Invest in self-service capabilities. Shift to product-oriented ownership, funding, and decision-making.
10. Required portfolio thinking is often fragmented or missing. Business units typically run their own development initiatives with separate budgets, priorities, and decision-making structures, making cross-domain data products difficult to coordinate, fund, and govern.
- How to overcome: Establish a unified data product portfolio model that includes shared prioritisation criteria, decision-making forums, and investment mechanisms. Create transparent ways to evaluate cross-domain value, align funding models to support shared data products.
There is no single blueprint for successful data products, but there is a clear pattern behind the organisations that make them work. They treat data products as a business capability, not a technical artefact. They invest in clear ownership, practical concepts, shared decision-making, and gradual learning through real use cases. Most importantly, they recognise that data products are a change in how the organisation thinks and works with data, not something that can be rolled out through technology alone. With the right foundations in place, data products become a powerful enabler for scalable analytics, AI readiness, and everyday business decisions.
