Part One of this series made a claim and left the bill unpaid. It said a data product is an owned, documented, trustworthy asset… and then it admitted that this does not happen on its own.
Someone has to decide who owns what and what good looks like. That decision is the governance charter, and most organizations have one that is actively working against them.
The problem is not that they lack governance. It is that the governance they have was built for a different job.
Governance Has a Branding Problem It Earned
For most of its history, data governance meant control. It was the function that told you no. It existed to satisfy auditors, enforce policy, and keep the organization out of trouble. The output was documents. Standards nobody read, catalogs nobody searched, policies that lived in a binder and had no connection to the work anyone actually did.
That model was not wrong for its moment. When the risk was regulatory, and the users were a handful of analysts, a control function made sense. But it produced a reputation that governance has never shaken. Ask most people in a business what data governance does for them and the honest answer is that it slows them down.
The modern charter starts by rejecting that premise. Governance is not the function that says no. It is the function that makes the yes trustworthy. Its job is not to control data. Its job is to make data usable, at scale, by people and systems that did not create it. That is a delivery mandate, not a compliance one, and it changes everything about how the charter is written.
Who Is Actually on the Charter?
Before you can talk about what the charter decides, you have to name who it decides for. Governance runs on a small set of roles, and the fastest way to make a charter useless is to leave them vague. Everyone nods along to “we need clear ownership,” and then nobody can tell you who does what. So be specific.
The Data Owner is accountable, not operational. This is usually a business leader who owns a domain of data because they own the part of the business it describes. They do not curate metadata themselves. They are the one answerable for whether the data is fit for purpose, who can access it, and what it is allowed to be used for. When there is a decision to make about the data, the owner makes it. Accountability stops here.
The Data Steward owns meaning. This is the person who defines what the data means in business terms, maintains the definitions, curates the glossary, and makes sure a term used in one place means the same thing in another. If the owner is accountable for the data, the steward is accountable for its context. When someone asks what “active customer” actually means, the steward is the one with the answer, and the one who wrote it down. This role matters more than any other to everything the rest of this series is about, because the steward is the person who turns tribal knowledge into captured context.
The Data Custodian owns the machinery. This is the technical role, usually sitting in engineering or platform, responsible for the systems the data lives in. They implement the access the owner approves, run the pipelines, maintain the infrastructure, and enforce the controls. They do not decide policy. They make policy real in the platform. The custodian is where the source-owner handoff from post one actually happens, the hands that move the data from system export to something the business can reach.
Those three cover the data. But a data product needs one more role, and it is the one people get wrong.
The Data Product Owner Is Not a Product Owner
When you tell an organization that data products need owners, the Agile-literate half of the room hears “Product Owner” and pictures the role they already know. Backlog, sprints, stakeholder priorities, the person who decides what the team builds next. That instinct is close enough to be dangerous, because the two roles share a name and almost nothing else.
An Agile Product Owner is accountable for what gets built. They manage a backlog, sequence work, and represent the customer to a delivery team. Their horizon is the next increment. Their question is “what should we build next?”
A data product owner is accountable for what is trusted. They do not manage a sprint. They own an asset that already exists and has to stay correct, current, and fit for purpose for as long as the business depends on it. Their horizon is the life of the product, not the next release. Their question is “can the business rely on this,” and the answer has to stay yes long after any build team has moved on.
The difference is delivery versus stewardship. A Product Owner ships. A data product owner sustains. One is accountable for getting something built. The other is accountable for it remaining true. An organization that staffs data product ownership with a project-management mindset will build good products and then watch them rot, because nobody was accountable for the part that comes after the build. The data product owner is the person who packages the output and the context from post one into a single trustworthy asset, and then keeps it trustworthy. That is not a project role. It is a permanent one.
The Four Things the Charter Has to Settle
With the roles named, the charter’s job comes into focus. It is not a mission statement so much as the set of decisions that make a product built by one domain look and behave like a product built by another.
Those decisions map directly onto the four principles of a data product:
- Ownership. The charter is where roles get assigned, usually through a responsibility matrix that names the owner, steward, and custodian for every domain. The test is simple. Pick any domain and ask who owns it. If you get a name in one breath, the charter works. If you get a meeting, it does not.
- Standards. Every data product needs to meet the same written definition of done before it ships. That means a plain-language description, a quality contract, ownership metadata, and glossary links. Without a shared bar, each domain invents its own, and the products stop working together.
- Authority. This is where the modern charter breaks hardest from the old one. A central council sets the global rules, such as sensitivity classification, access principles, and the definition of done. The domains make the local decisions about what their data means and how their products are built. A central team can write standards for the whole organization, but it can never understand every domain’s data well enough to own it.
- Enforcement. A standard nobody checks is just a suggestion, so the modern charter builds enforcement into the platform. Classifications drive access automatically, quality contracts flag themselves when they break, and policies run as code. Every rule pushed into the platform enforces itself, which is what lets a consumer reach a product without filing a ticket.
Why This Cannot Wait
You could argue the old governance model was slow but survivable. For human-scale data use, it was. The cost of bad governance was friction, and organizations absorbed friction for years.
That math changes with AI. An AI system consumes data at a scale and speed no human ever could, and it consumes exactly what governance leaves behind. If your ownership is unclear, the AI does not know whose definition to trust. If your quality is unmonitored, the AI cannot tell good data from stale data. If your context lives in an analyst’s head, the AI never sees it. Every gap in your governance becomes a gap in what your AI can safely do.
This is why the charter is urgent rather than eventual. Governance used to be the function that protected you from risk. Now it is the function that determines whether you can use AI at all. An organization with a modern charter is one where data products carry the ownership, quality, and context that both people and machines depend on. An organization without one is trying to build AI on top of data nobody is accountable for, and it will find out the hard way that the machine believes whatever the data tells it.
The charter is not governance paperwork. It is the operating system for a business that wants its data to be trustworthy by default.
Where This Goes
A charter names the roles, assigns them to domains, sets the bar, shares authority, and holds the line. Get those right and data products stop being one-off efforts and start being the normal way the organization delivers data.
But the charter still leaves one question hanging. It gives the steward the job of owning meaning and capturing context, and it never says where that context is supposed to come from. Most organizations assume the answer is work, that context is something the steward sits down and manufactures, definition by definition, until the job is done.
That assumption is wrong, and it is the most freeing thing in this series. The context the steward is responsible for is already being created, at every layer of your architecture, as a byproduct of the work you are already doing. You are not missing it. You are just letting it evaporate. That is where this series ends.
Hakkoda and IBM Consulting help organizations design and implement modern data governance frameworks, from defining ownership and standards to building the platform-level controls that make self-serve data possible. Whether you are starting from scratch or modernizing a governance model that has outgrown its original purpose, we can help you build something the business actually uses. Contact us to talk about where your organization can start.
