Most operators we talk to say some version of the same thing: “we have well data.” They usually do. It’s in the PPDM tables, or the vendor system, or a warehouse somewhere, and a query returns rows. What they almost never have is a well data product. Those are not the same thing, and the gap between them is where most of the daily friction lives.
A data product has a name and an owner. It has known consumers and it was built for them. It publishes what it promises about freshness, completeness, and consistency, and it can be found by someone who didn’t build it. Well data, on its own, has none of that. It’s just tables. Tables are inventory. A product is inventory that somebody stands behind.
ThoughtWorks moved “data product thinking” to Adopt on its Technology Radar in April 2025, meaning they think most organizations should already be doing this.[1] Upstream is behind on it. Here’s what the difference actually looks like when the data in question is your well master.
The well master has four different customers
Ask who consumes the well master and you get a list that seems like it’s describing one thing. It isn’t. Each of these people wants a different slice, at a different cadence, with a different tolerance for being wrong.
The landman needs legal well identity tied to the lease and the unit: which wells sit on which tract, who operates, what the working interest and net revenue interest are. They care intensely about ownership accuracy and almost not at all about yesterday’s production rate. If the well master says XYZ Energy operates a well that was sold eight months ago, that’s a real problem for them, and a stale attribute nobody flagged.
The reservoir engineer wants the wellbore, the completion, the current equipment, and a clean join to production and pressure history. They want spud dates, TD, perf intervals, and the API number resolved correctly so their decline curves aren’t averaging two wells together. Ownership is noise to them.
The comptroller wants the well master to agree with the accounting system, because revenue and JIB allocation run through well identity. When the well master and Bolo disagree about which cost center a well belongs to, that shows up in monthly close as a variance somebody has to chase down.
Regulatory needs whatever OCC, Railroad Commission, or the relevant agency asks for, in the format they ask for, by the date they ask for it. A missing spud date is an annoyance for engineering and a filing violation for regulatory.
Same underlying table. Four consumers who would each define “correct” and “current” differently. That’s the tell that you’re looking at raw data, not a product. A product picks its consumers on purpose and designs for them.
Designing backward from use cases
The default way a well master gets built is inside-out. Someone models the entities, loads every source system, resolves identity as best they can, and publishes the result. Then consumers show up and bend it to fit. This is how you end up with a PPDM implementation that’s technically complete and practically unusable, where every analyst maintains a private spreadsheet that “fixes” the well master before they trust it.
Designing backward starts from the consumer instead. Before you model anything, you ask the reservoir engineer what a usable well record looks like for decline analysis, and you ask the landman what ownership accuracy they need to sign off on a division order. You find out that engineering can tolerate a well identity that’s 24 hours stale but cannot tolerate two physical wells collapsed into one API. You find out that land cannot tolerate a wrong operator but doesn’t care that the last SCADA reading is a day old.
Those answers change what you build. They tell you which attributes need tight quality assertions and which can be best-effort. They tell you the freshness target isn’t one number, it’s a number per consumer, and the product either meets the tightest one or splits into more than one product. They tell you the entity resolution work on the API number is load-bearing for engineering and the operator-history tracking is load-bearing for land, so both get real effort instead of whatever’s left after modeling.
This is the practical difference PPDM guidance usually skips. The model tells you how to shape a well table. It does not tell you whose well table it is. We wrote about the limits of the model itself in what PPDM actually gives you; this is the layer that sits on top of a PPDM implementation and makes it something people will actually use.
The minimum viable data product contract
You don’t need a platform or a catalog vendor to have a data product. You need a short document that answers a few questions and an owner who keeps it true. Call it the well master data product contract. Four things go in it.
Schema: the fields the product exposes, their types, and which ones are guaranteed present versus best-effort. Not the whole PPDM well table. The subset consumers actually depend on, named explicitly, so a change to a field nobody uses doesn’t get treated like an outage and a change to operator_name does.
Owner: one person accountable for the product, with the authority to decide when the well master and another system disagree. Not a committee, not “the data team.” A name. This is the same named-owner pattern we argued for in data governance without a data team, pointed at a specific product instead of a whole domain.
Freshness SLA: how current the data is promised to be, per consumer if they differ. “Ownership attributes reflect changes within one business day of the land system update. Production-linked attributes refresh with the nightly load.” Now staleness is a broken promise you can alert on, not a surprise someone finds in a meeting.
Quality assertions: the checks that must pass before a new version publishes. Every active well has an operator. API numbers match the 14-digit format and resolve to exactly one wellbore. Working interests on a unit sum to 100 percent. These are testable statements, and they belong in the pipeline as gates, not in a QA doc nobody reads.
That’s the whole contract. A page, maybe two. The value isn’t the document. It’s that consumers now know what they’re getting and get told when it changes, and the owner has something concrete to defend.
Where this sits relative to data contracts and quality gates
This trio blurs together constantly, so it’s worth being precise. A data contract, in the sense we mean in data contracts for upstream pipelines, is the agreement at the source boundary: when the OCC changes a field or a vendor SCADA API renames a tag, the contract catches it before bad data lands. That’s producer-facing, at the edge of your system.
The data product is consumer-facing, at the other end. It’s the packaging on top of the resolved, cleaned data that says “here is the well master, here is who it’s for, here is what we promise about it.” The quality assertions inside the product contract get enforced by the same kind of in-pipeline testing the source contract uses, but the audience is different. One protects you from your sources. The other is a promise to your consumers.
You can have source contracts without data products, and plenty of operators do. It means your ingestion is defended but nobody downstream knows what the well master is for or whether they can trust it today. You can also declare a data product with no source contracts underneath, which means you’ve made promises you have no mechanism to keep. You want both, wired together.
This is governance, wearing different clothes
Named owner. Documented rules for what “correct” means. A way to know the rules are being followed. A defined process when the rules change. If that list sounds familiar, it’s because it’s the same thing governance is trying to accomplish, scoped to one product instead of one domain.
The data product is the unit governance can actually attach to. “Govern the well master” is vague enough that it never quite happens. “The well master data product has an owner, a published contract, and quality gates that block a bad publish” is specific enough to be true or false on any given day. It’s the same reason knowing exactly what’s in the barrel beats a general sense that your data is probably fine, which is the argument we made across the 42 Gallons series.
There’s a build-order implication too. If you centralize everything first and worry about consumers later, you get the busy-data-engineers-and-nothing-to-show-for-it outcome we described in why the data lake is not a strategy. Products invert that. You pick one, name its consumers, ship it, and it earns trust before you build the next.
Start with the well master and one consumer
You don’t need to productize your whole estate. Pick the well master, because it’s the one everything else joins to, and pick the single consumer whose pain is loudest right now. Sit down with them, find out what “usable” and “current” actually mean for their work, and write the one-page contract to that standard. Name an owner. Wire the quality assertions in as pipeline gates. Publish it and tell people it exists.
The operators who do this stop rebuilding the same trust in every spreadsheet. The well master becomes a thing you point at instead of a thing everyone quietly patches. That’s the difference between having well data and having a well data product, and it’s mostly a decision, not a purchase.
Thoughtworks, “Data product thinking,” Technology Radar Volume 32 (April 2025). https://www.thoughtworks.com/en-us/radar/techniques/data-product-thinking ↩︎