Is traditional data governance holding back data product delivery?
Traditional data governance is not wrong. Organizations need policies, clear ownership, access controls, quality requirements, accountability, and evidence that important decisions follow agreed rules.
The problem is often how governance enters the work. Teams can identify business needs, design data products, agree technical solutions, and begin implementation before governance becomes a serious discussion. A separate review process then introduces requirements that should have influenced the original decisions.
Product teams spend time preparing documentation for approval. Governance teams review decisions they were not involved in making. Missing information leads to additional meetings, revisions, delays, and sometimes substantial rework. At the other extreme, a review becomes a formality that records a decision without improving it.
Neither outcome is an effective way to manage data products.
Minimum Lovable Governance (MLG) takes a different approach: the smallest useful set of governance requirements is part of the product workflow from the beginning. The objective is not less accountability. It is governance that people understand, follow, and benefit from while doing their actual work.
What traditional data governance gets right
Enterprise data governance exists for good reasons. A bank must protect customer information. A healthcare organization must manage sensitive patient data. A government agency must understand what information it may share and under which conditions.
These requirements do not disappear because an organization adopts data products, agile delivery, or AI agents. Security defines controls and enforcement mechanisms. Risk and compliance functions interpret obligations and assess exposure. Data governance teams establish common policies, classifications, and quality expectations.
The weakness appears when these capabilities operate through disconnected procedures. A product team may keep ownership in a spreadsheet, describe access in a document, track delivery in Jira, and submit separate forms for security and governance review. Each system contains part of the picture, but none necessarily shows the relationship between business purpose, product definition, applicable policies, delivery status, and decisions already made.
Governance then becomes an exercise in collecting evidence rather than using evidence to guide the work.
What Minimum Lovable Governance means
Minimum Lovable Governance is the smallest useful set of ownership, evidence, controls, policies, and review points that stays connected to a data product throughout its lifecycle.
Minimum does not mean avoiding necessary controls. It means avoiding unnecessary administration, duplicated information, and approvals that add no meaningful value. Lovable describes an operating experience that teams will use because it helps them make better decisions.
A product manager should see the requirements that apply before committing to delivery. A data steward should see which products need attention without reconstructing their context. A reviewer should understand what changed, why it matters, and the evidence supporting the proposed decision.
Requirements should also vary with the situation. A public, low-risk reference dataset does not necessarily need the same reviews as a product containing sensitive customer information. Enterprise policies determine the control level; MLG makes those requirements visible and actionable within the product lifecycle.
A banking example: from business idea to governed data product
Consider a bank planning a Customer Retention Indicators data product. Its business objective is to reduce customer churn through earlier engagement. The proposed product will combine customer profiles, transaction activity, and customer interactions.
Stage 1: The idea
With MLG, the initial candidate already has a business objective, intended use case, proposed owner, and basic classification. The team does not need a full governance assessment yet; it needs enough information to identify responsibilities and obvious risks. Because customer information is involved, privacy, access, and permitted-use requirements become visible before a development commitment is made.
Stage 2: Product definition
The team identifies consumers, data dependencies, quality expectations, access needs, and the parties responsible for product decisions. Ownership becomes explicit, applicable policies are associated with the product, sensitive-data requirements are visible, and known gaps are recorded rather than hidden in meeting notes.
Stage 3: Review and approval
Appropriate reviewers still determine whether the product meets requirements before it becomes available. MLG does not remove this decision point. It improves the information available for it: purpose, use, ownership, dependencies, access requirements, quality expectations, evidence, and unresolved questions. The outcome becomes part of the product's decision history.
Stage 4: Operation and change
Once operational, the bank may introduce a consumer, modify its customer model, revise access conditions, or change quality expectations. Each change can affect interfaces, contracts, use cases, owners, and policies. Connected context triggers the appropriate review without making teams repeat every prior assessment. Changes requiring formal authorization still follow the bank's established approval and enforcement processes.
Governance should follow the lifecycle
An early idea needs enough information to establish purpose, responsibility, and obvious constraints. An investment candidate needs stronger evidence of feasibility, demand, dependencies, and expected value. A product entering delivery needs technical responsibilities, contractual expectations, relevant controls, and review requirements.
An operational product needs continuing oversight of quality, access, commitments, changes, and lifecycle decisions. A retiring product needs to consider dependencies, consumers, contractual obligations, and retention requirements. Applying every requirement at the idea stage creates unnecessary work; waiting until production creates unnecessary risk.
The useful approach is to introduce the right requirements at the right point, based on enterprise policy and the product's circumstances.
Why connected context matters more than another approval form
Many governance problems are information problems. Organizations have policies, ownership registers, project records, metadata catalogs, risk assessments, and approval workflows, but the relationships between them can be difficult to maintain.
A small technical change to a product supporting three business use cases may affect a quality threshold, sensitive information subject to restrictions, or an AI agent in an automated workflow. A reviewer cannot assess that change responsibly from a technical specification alone. The decision requires business context, product relationships, relevant policies, operational state, and evidence of earlier commitments.
A connected knowledge graph makes business objectives, use cases, data products, owners, policies, dependencies, lifecycle states, and decisions related objects rather than independent documents. It does not establish compliance or guarantee every dependency is known. Its value is making the available relationships explicit, traceable, and usable in governance workflows.
What changes when AI agents participate in governance?
Agents can interpret requirements, propose product definitions, analyse dependencies, identify missing information, and prepare work for review. An agent reviewing a proposed customer-data product might identify that it has no assigned owner, that its intended use involves sensitive information, or that a similar product already exists. It can present those findings with supporting context and recommend further review.
Identifying a governance gap is different from deciding whether a product is compliant. An AI agent should not independently invent policies, establish business ownership, grant access, or approve a product for production merely because its generated assessment appears convincing.
A governed agent operates within defined permissions and workflows. Its inputs, source evidence, actions, and recommendations should be traceable. Applicable controls determine which operations need human review or approval. Maysano applies explainable and auditable agent workflows, externally configured recipes, and operational controls such as a kill switch to support this approach.
These mechanisms make agent activity easier to inspect and control. They do not make AI output infallible or remove the need for accountable human decisions. Machine-readable context, current lifecycle states, explicit permissions, and recorded decision evidence provide a stronger foundation than policies buried in PDFs or approvals hidden in email.
Where Maysano fits
Maysano connects business objectives, use cases, data products, ownership, lifecycle, governance requirements, dependencies, and delivery context through a shared knowledge graph. It brings relevant governance information into the workflows used to define, evaluate, deliver, and manage data products.
Product teams can identify missing ownership, required reviews, unresolved governance questions, and affected relationships as work progresses. AI agents can help prepare product definitions, identify gaps, examine dependencies, and produce recommendations for human review.
Maysano builds on open, machine-readable standards managed under the Linux Foundation's LF AI & Data umbrella. These standards support consistent product definitions, contracts, and operational information across tools and organizational boundaries.
What Maysano does not replace
Maysano does not replace enterprise risk management, cybersecurity, legal, privacy, or compliance functions. It is not the authoritative enforcement point for every access policy or security control. Existing governance platforms, identity systems, data catalogs, and security infrastructure continue performing their designated responsibilities.
Maysano provides the business and product context needed to connect those responsibilities with product decisions and delivery workflows. Where other systems hold authoritative policies, classifications, ownership records, or approvals, those responsibilities should remain there.
How much governance is enough?
There is no universal minimum. A public reference product, an internal financial-reporting product, and a customer-facing AI data product operate under different conditions. The appropriate requirements depend on purpose, sensitivity, consumers, dependencies, regulatory obligations, and potential impact.
The practical starting point is to identify the decisions that require accountability and the evidence required to make those decisions responsibly: who owns the product, which business purpose it serves, which policies apply, what quality commitments exist, who may consume it, what needs approval before a lifecycle change, and how decisions and changes are recorded.
Apply controls at the appropriate lifecycle stages, automate repeatable checks where suitable, and preserve human accountability for decisions that require it. When governance information is already in the product workflow, teams spend less effort collecting it for a separate review and gain more opportunity to address problems early.
From governance documents to governed operations
Traditional governance frameworks will continue to matter. Organizations still need common policies, clear authority, oversight, and formal controls. What needs to change is their relationship with everyday product work.
Minimum Lovable Governance embeds necessary requirements into the lifecycle of the products being managed. It makes ownership visible, connects policies to relevant work, records decision evidence, and brings review points into the process where decisions happen.
As AI agents participate in product definition, governance analysis, and operations, both machines and human teams need the same current, explicit, and traceable context. The next step is not removing governance from enterprise data operations. It is making governance integral to how those operations work.