The Problem with "Data Governance"
Most people don't like the phrase "data governance."
Not because they don't care about quality, access, or security, but because the term itself is confusing, overloaded, and often misused. Ask ten people what data governance means and you'll get ten different answers. Compliance. Risk management. Metadata. Quality. Privacy. Access control. All of the above, or something else entirely.
- Compliance teams: Risk management and regulatory requirements
- IT teams: Access controls and security policies
- Data teams: Quality checks and metadata management
- Users: Documentation and data discovery
- Leadership: Overhead and bureaucratic processes
This ambiguity is part of the problem. When a term tries to mean everything, it becomes hard to reason about, hard to operationalize, and easy to ignore. Data governance has become a catch-all phrase that tries to describe everything and ends up resonating with almost nobody.
As a result, instead of leading with governance, I focus on Data as a Product. Not just as a metaphor, but as a way to reframe how I prioritize, manage, and communicate about data work. It gives me a clearer vocabulary and a more outcome-driven framework to operate from when talking with people about what they expect from the data, rather than talking about tools.
Why Traditional Governance Programs Fall Short
Most governance initiatives begin with mechanisms rather than outcomes. They emphasize assigning data owners, managing lifecycles, enforcing quality checks, building glossaries and catalogs, and setting access policies.
These practices are important, but mechanisms alone do not inspire change. They often feel like overhead. And because data governance is such a broad and slippery term, it tends to lack clarity and alignment. Stakeholders can't see how the proposed activities connect to their goals, so they view governance as a blocker rather than an enabler.
When governance fails, it's rarely because a mechanism was missing. It fails because the organization never aligned on what success actually looks like.
Instead of trying to force alignment around a term with too much baggage, I decided to restructure the discussion around expected outcomes. Outcomes that matter most in enabling trusted, usable, and scalable data.
The Four Outcomes of Data as a Product
I anchor data governance around four outcomes that I believe are non-negotiable for a healthy data ecosystem. Once these outcomes are clearly communicated and aligned on with organizational leaders, strategic and technical conversations become easier.
1. Durable Ownership
Definition: Every meaningful dataset has a clearly accountable owner whose responsibility persists across time, systems, and organizational change.
Without durable ownership, data quality degrades silently. Documentation goes stale. Pipelines break without clear escalation paths. During reorganizations, data becomes orphaned.
I don't mean putting someone's name in a spreadsheet. I mean instilling a product mindset of stewardship. Someone who is genuinely accountable for defining what the data represents, maintaining its quality, managing changes, and understanding its consumers.
- Data should be grouped around articulable domains, not just source systems
- Ownership should align to teams with long-term accountability for outcomes
- Data products should have explicit interfaces and contracts
2. Trust in the Data
Definition: Consumers can rely on the data to be accurate, timely, and complete without manual verification.
When data isn't trusted, people build workarounds. They revalidate, re-ingest, and second-guess. That slows everything down. When trust is low, velocity collapses. Teams revalidate numbers, rebuild pipelines, and create shadow datasets.
In this model, trust becomes an explicit feature of the data product. Not an assumption. Not a compliance goal. It's a deliverable. That means engineering for data quality, observability, and clarity, not just asking people to have faith that the data is correct.
- Data quality expectations must be explicit, measurable, and contextual
- Observability becomes a first-class concern, not an afterthought
- Lineage and freshness matter because they explain behavior and dependency relationships
- Breaking changes must be visible, intentional, planned, and communicated
3. Usability of the Data
Definition: Data is discoverable, understandable, and fit for its intended use cases.
Data that exists but cannot be understood, found, or applied might as well not exist. Poor usability leads to duplicated effort, constant support requests, and inconsistent interpretations. Data is only valuable if people can use it.
Usability is a non-negotiable product requirement, not an afterthought or an internal support burden. This includes logical modeling, good documentation, stable interfaces, and discoverability. It also means structuring and delivering the data in a way that aligns with how users actually need to consume it.
- Schemas should be designed for consumers, not just ingestion convenience
- Documentation should explain meaning and intent, not just structure
- Data products should be discoverable through consistent naming and organization
- Interfaces should be stable enough to support downstream development
4. Data Security
Definition: Data access is controlled, auditable, and aligned with business risk, without unnecessarily blocking legitimate use.
Security is obviously a critical component in data governance. Over-securing data, however, creates bottlenecks that drive workarounds and shadow systems. Security is not about locking everything down. It's about ensuring that the right people have access to the right data at the right time, with appropriate protections, auditability, and compliance safeguards.
Security is something that should be embedded into the design of the data product, not layered on afterward. Implementation of security controls while minimizing friction and the disruption of legitimate access is the goal.
- Data classification must be consistent and automated where possible
- Access controls should map to roles and domains, not individual datasets
- Auditability must be built into platforms, not bolted on later
- Secure access should be the default path, not an exception process
Treating Data Like a Real Product
If we're going to call something a "data product," I believe it should actually be managed like a product. Calling something a data product is meaningless unless it is managed like one. That means applying the same discipline that a successful product owner would use:
- Clear Product Specs: What is this data for? Who are the consumers? What is the schema and SLA?
- User Stories and Use Cases: Understanding how the data will be used and what the pain points are
- Outcome-Based Prioritization: Prioritizing based on user impact and business value, not governance checklists
- Feedback and Iteration: Treating data as something to be iterated on, not published once and forgotten
- Value-Focused Metrics: Success measured by whether data helps users do something faster, more confidently, or more accurately
This product discipline is what turns governance from policy into practice. It forces trade-offs. It makes ownership real. It ties quality and usability directly to business outcomes.
Governance Emerges From the System You Build
When you work backward from durable ownership, trust, usability, and security, governance stops being a separate initiative. It becomes an emergent property of how teams are structured, how data is modeled and exposed, how platforms enforce contracts and controls, and how feedback loops inform prioritization.
This approach helps avoid performative governance and instead enables practical, value-focused data management.
The Path Forward
- Data that works reliably and consistently
- The ability to move faster with confidence
- To build, decide, and learn without constant rework
- Clear accountability and escalation paths
- Security that enables rather than blocks legitimate work
Data governance is a term with too much baggage and too little clarity. For some, it signals risk. For others, it signals red tape and excessive processes. And for many, it simply doesn't mean anything specific enough to act on.
In the end, no one really wants "governance." They want data they can trust, use, and act on with confidence. Start with that as the North Star.