Product Management for Data

Why Product Discipline Breaks When You Copy It From Software

The instinct is to lift Software Product Management wholesale. It fails in three specific ways, and understanding the failure modes tells you what to build instead.

First, your "users" are often machines and pipelines, not humans clicking a UI. A feature-store table feeding a fraud model has no user session, no funnelfunnelThe customer journey from awareness to purchase, typically Awareness, Interest, Consideration, Decision, Action, with prospects narrowing at each stage.View full definition →, no NPSNPSNet Promoter Score (NPS) measures customer loyalty by asking how likely customers are to recommend a brand, then subtracting detractors from promoters.View full definition → survey. Discovery can't rely on watching people use the thing. You have to instrument *consumption*—which downstream jobs read which columns, how freshness affects model performance, which fields are queried and which are dead weight. The product signal is in the query logs and lineage graph, not in user interviews alone.

Second, the cost of a breaking change is asymmetric and often invisible to you. In software, if you break an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, the client app crashes and someone files a ticket. In data, if you silently change a column's semantics—say, revenue shifts from gross to net—nothing crashes. Models drift, dashboards quietly lie, and a VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.View full definition → makes a bad call three weeks later. The blast radius of a data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → is larger and quieter than a software feature, which means the *contract* has to do more work.

Third, value is frequently indirect. A software feature can often be tied to a conversion or retention number. A canonical customer entity might create value by enabling nine downstream products, none of which credit it. This wrecks naive ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition →-based prioritization and forces DPMs to reason about *option value* and *dependency leverage*, not just direct usage.

So the DPM is not a software PM who switched domains. The role is a hybrid: enough data engineering fluency to read a lineage graph and interrogate a schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →, enough domain economics to know which decisions a dataset actually informs, and enough political capital to say no to a demanding VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.View full definition →. When you hire or promote for this role, weight *judgment about consumer need under ambiguity* over tool expertise. The tools change; the judgment compounds.

What the DPM actually owns

Draw the line clearly or you'll get a coordinator who books meetings. A real DPM owns four things:

• The problem definition—what decision or workflow this product improves, stated in the consumer's language.
• The prioritized roadmap—what gets built, what gets refused, in what order.
• The interface contract—schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →, semantics, SLAs, and the change policy.
• The lifecycle—from launch through iteration to deprecation.

They do *not* own the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →'s implementation (that's data engineering) or the storage architecture (covered in your fundamentals). The DPM owns the *outside* of the product—the promise—while engineering owns the *inside*.

Discovery: Finding the Product Inside the Request

Every CDO gets a stream of requests that sound like products: "We need a churn dataset." "Marketing wants a unified customer view." Treating these as specs is how you end up with the 15-versions-of-market-health problem. Discovery is the discipline of translating a request into a validated problem before committing engineering capacity.

The best DPMs run a compressed version of the "Jobs to Be Done" logic adapted for data. The question isn't "what data do you want?" It's "what decision are you making, how often, and what does being wrong cost you?" That reframing does three things: it exposes whether the request is a genuine recurring need or a one-off analysis (which shouldn't be a product at all), it reveals the required freshness and accuracy from the *decision's* economics rather than the requester's wish list, and it surfaces the real consumers.

Consider a request for "real-time inventory data." Discovery reveals the actual decision is a nightly replenishment order placed at 2 a.m. Real-time is expensive and irrelevant; a reliable 11 p.m. batch snapshot is the product. You just saved a quarter of streaming infrastructure by asking about the decision instead of the data.

A practical discovery artifact I insist on is a one-page data product brief the DPM writes *before* any build:

Notice the cost_of_error asymmetry—false negatives cost 60x more than false positives. That single line dictates the model's optimization target and the SLA. Notice NOT_in_scope. Half of discovery is deciding what the product *refuses* to be. Airbnb's Minerva succeeded partly because it declared it would only serve *certified* metrics, not every ad hoc calculation.

Prioritization: The Portfolio Problem Nobody Trained You For

Here's where CDOs bleed value. Because data products have indirect and networked value, standard prioritization frameworks (RICE, weighted scoring) systematically underweight the products that matter most—the foundational entities and metrics that everything else depends on.

Use a two-axis lens the DPM applies to every candidate: decision leverage (how many high-stakes decisions this product touches, weighted by their value) against cost-to-serve reliably (build plus the ongoing maintenance burden, including on-call). The trap is that foundational products—a canonical customer or product entity—score low on *direct* leverage because no single decision "belongs" to them, yet they unlock dozens of downstream products. The DPM must model dependency leverage explicitly: a product's score inherits a fraction of the value of everything built on top of it.

This is why you separate the portfolio into three tiers, funded differently:

• Platform products (canonical entities, the metrics layer, core feature tables): funded as infrastructure, evaluated on adoption and reuse, not direct ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.View full definition →. These are your Minerva-class assets.
• Decision products (a specific churn model, a pricing-elasticity dataset): funded on decision economics, evaluated on whether the decision improved.
• Exploratory products (a new experimental segmentationsegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition →): funded as options, time-boxed, killed fast if they don't validate.

The single most valuable prioritization move a DPM makes is refusing to build. Every data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → incurs a permanent maintenance tax—schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → drift, upstream changes, on-call, documentation decay. A rule I've seen work: no new product ships until the team has identified what capacity it will consume *forever*, not just to build. If a team is at maintenance saturation, the answer to a new request is "no" or "what do we deprecate first?"—not "yes, next quarter."

Making the maintenance tax visible

Give your DPM a simple ratio to report upward: build capacity vs. run capacity. When run exceeds roughly 60–70% of the team's total capacity, you are no longer a product organization—you're a maintenance organization, and innovation has stopped. This ratio is your early warning that the portfolio has too many products and not enough deprecation. It's also the number you take to your CFO to justify either headcount or a deprecation sprint. Most CDOs never measure it and are then baffled when velocity collapses.

Lifecycle: The Discipline of Contracts and Endings

Software teams learned decades ago that a product's life is mostly *after* launch. Data teams routinely act as if launch is the finish line. The DPM's most durable contribution is managing the full lifecycle—especially the two phases teams neglect: the interface contract and deprecation.

The contract is the product's real interface. Because breaking changes are silent and high-blast-radius (recall the gross-vs-net revenue example), the contract must be explicit and machine-enforceable. This is where the modern "data contract" practice earns its keep. The DPM owns the contract's *semantics and change policy*; engineering enforces it in the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →. A minimal contract declares the schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →, the semantic meaning of each field, the SLAs, and—critically—the change policy: what constitutes a breaking change, how much notice consumers get, and how versions coexist.

The change policy is a *product* decision, not a technical one, because it trades consumer stability against your velocity. A platform product serving 40 consumers might promise 90 days' deprecation notice and dual-running versions. An exploratory product might promise nothing. The DPM sets this deliberately per tier.

Versioning must be real, not aspirational. When semantics change, you publish v2 alongside v1, migrate consumers on a schedule, and only then retire v1. This is operationally expensive, which is exactly why prioritization and refusal matter—every product you ship is a versioning obligation you accept.

Deprecation is the phase that separates a product organization from a landfill. Most data estates are 60% abandoned tables that no one dares delete because no one knows who reads them. The DPM runs deprecation as a managed process: instrument consumption, identify products below a usage threshold, announce sunset with a migration path, and delete. This is unglamorous and it is the highest-leverage hygiene in your entire estate, because every retired product returns run capacity to the build column.

A concrete operating cadence for your DPM: a quarterly portfolio review that answers three questions for every product—*Is anyone still using it? Is it meeting its contract? Should it be promoted, invested in, or killed?* Products that fail the usage test get a sunset date on the spot. This review is the mechanism that keeps the build/run ratio healthy. Run it yourself for the first two quarters so the organization sees that killing products is celebrated, not punished. The cultural signal—that a DPM who deprecates ten dead products is as valued as one who ships a new one—is something only you as CDO can send.

Measuring a data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition →'s health

Direct usage is necessary but insufficient. Track four signals per product: adoption (distinct consumers and their trend), reliability (contract adherence—freshness and quality SLAs met), decision impact (did the target decision measurably improve—the hardest and most important), and cost-to-serve (compute plus human maintenance). A product high on adoption and reliability but with unknown decision impact is a candidate for a deeper investigation, not automatic renewal—it may be a beautifully maintained artifact that changes no decisions.

Key Takeaways

• Install the DPM role with a sharp mandate: they own the problem definition, roadmap, interface contract, and lifecycle—the *outside* of the product. Engineering owns the *inside*. Blur this and you get a meeting coordinator, not a product owner.

• Anchor discovery in the decision, not the data request. Force every product brief to state the consumer decision, its cadence, and the asymmetric cost of being wrong. That single discipline right-sizes freshness, accuracy, and scope—and kills products that should have been one-off analyses.

• Prioritize across three tiers with dependency leverage in view. Fund platform products as infrastructure on reuse, decision products on decision economics, and exploratory products as time-boxed options. Standard RICE scoring will starve your most foundational assets.

• Watch the build/run capacity ratio like a P&L line. When run exceeds ~60–70%, you've stopped innovating. This is your quantitative trigger for either headcount or a deprecation sprint, and the number you bring to the CFO.

• Treat deprecation as a first-class, celebrated activity. Run a quarterly portfolio review that puts a sunset date on unused products. Every product retired returns capacity to building—and only you can send the cultural signal that killing dead products is as valued as shipping new ones.