Listen now on YouTube | Spotify | Apple Podcasts | Amazon Music
Somewhere in almost every data organization, an eager executive has asked questions about the usability of the organization’s data. You’ve ingested the data, put it neatly all in one place, and built the lake. So, can we use it now? Amin Venjara, Chief Data and Product Officer at ADP, hears that question constantly, and he says data sitting in a data swamp was never the point. The value shows up later, in the work you do after capture.
I caught Amin’s session at the CDOIQ Symposium in Cambridge, Massachusetts, and then pulled him in front of a Data Faces Podcast mic. His talk was called “Value Equals Data and Capabilities: a field guide to product-led data platforms,” and the equation in that title is the whole argument. Data is one term. Capabilities are the other. Executives fund the first and forget the second, then wonder why the picture never comes together.
“Data plus capabilities equals the value.”
— Amin Venjara, Chief Data and Product Officer, ADP
About Amin Venjara
Amin Venjara is the Chief Data and Product Officer at ADP, where he oversees the product portfolio and the data that differentiates it, from the smallest nail salon and tire center up to Fortune 500 multinationals. Amin told me the company operates in 140 countries, pays close to 20% of the U.S. working population, more than 40 million people a month, serves over a million clients, and moves roughly $3 trillion a year once you count taxes and government filings.1 He fell into data through an unlikely door. He grew up a New York Mets fan who dreamed of being a sports broadcaster, played trumpet, and loved math, and he found the thread that ties it all together: data work is technology, people, and storytelling at once.
In this episode, Amin and I discuss:
Why “it’s all in one place” is not the same as value
What a data capability is, from the semantic layer to entity resolution
The contractor who talks about wood while the customer wants a backyard
How ADP runs its data platform like a product nobody is forced to use
The one metric that shows whether the data team is earning its keep
Watch the full conversation here:
What counts as a data capability
What’s a data capability? A data capability is the engineering work that turns co-located data into something a business can use, and Amin is precise about what that means. He points to a semantic layer, so that revenue means one thing everywhere and a headcount number resolves the same way in every report. He points to an entity resolution graph, so that the same customer lines up across sales, service, finance, and support. He points to the stitching that takes four systems full of data about a client and produces one coherent picture of that client. None of that comes free when the data lands in the same place.
“Just because it’s in the same place, can you extract the value? No. There’s a lot of work that has to happen, these capabilities.”
— Amin Venjara, Chief Data and Product Officer, ADP
That distinction is where Amin says his own organization turned a corner. Once his team could separate the data from the capabilities, they could finally have a direct conversation with the business about what it takes to create value, because the business could see that the work wasn’t finished the moment the ingestion pipeline ran. Owning the ingredients is not the same as cooking the meal. You can have sales data, service data, customer data, and finance data in the same warehouse and still not know how to get the right answer for revenue or customer count, because the semantic definition that produces that answer is itself a capability you have to build. Data plus capabilities is not a slogan; it forces you to budget for the half of the work that otherwise goes unfunded.
Why the capability half never gets funded
If capabilities are half the value, why do so few organizations pay for them? Amin answers that data teams describe the wrong thing. They walk into a business conversation and talk about sources, ingestion, ETL pipelines, data quality, and lineage, all the machinery under the floor, and the executive on the other side of the table glazes over. To help me understand, he shared an analogy about contractors.
A contractor shows up and says he has the best wood, the strongest concrete, and the finest nails, and he can tell you exactly how many pounds the concrete will hold. The homeowner just wants to entertain people in the backyard. Should we build a deck? A patio-scape? That is the conversation the homeowner wants to have, and the contractor keeps selling lumber.
“This guy’s like, I got the best wood. It’s amazing concrete. And the guy’s like, I just want people to have a good time.”
— Amin Venjara, Chief Data and Product Officer, ADP
The materials matter, but the value has to come first, and Amin’s team took the translation on as their own job rather than waiting for the business to learn to speak data. Business and data speak different languages, and someone needs to translate. When his organization decided that translating value was part of the data team’s mandate, the capabilities stopped being line items the business kept cutting and became things it asked for by name. An unfunded capability is almost always a capability nobody managed to explain.
What a capability buys you in the AI era
The capabilities argument gets sharper the moment you point it at AI, because the AI era is where the cost of skipping capabilities compounds. Every company is racing to put a chat experience or an agent in front of its customers. Amin walks through what that requires. A customer engages inside a SaaS application. That application knows something about the customer, but so does the CRM, the financial system, the sales system, the service system, the ticketing system, and the call transcripts. Each of them holds a fragment. If the chat application has to reach into all of them and resolve the customer, reconcile the definitions, and handle the latency every single time, you have handed an enormous amount of repetitive work to every application you build.
Now consider the alternative. One data product has already normalized the data across those systems. It has resolved the customer IDs, it understands latency, it keeps the definitions right, and maintains the lineage and refresh cadence underneath. Your chat application calls that one data product and gets the full customer context. So does your agent, so does the next application, and the one after that.
“Imagine that when that customer engages, that application could call a data product that had already normalized data across these different systems so that it could call the appropriate context for that customer.”
— Amin Venjara, Chief Data and Product Officer, ADP
The capability layer, not the model, decides what your AI can do. An agent pointed at raw systems reinvents the stitching on every call, and it inherits every inconsistency those systems carry. A data product built once as a real capability gives every agent and every application the same clean context to stand on. When I said back to Amin that he had just articulated why you build data products at all – to stop reinventing the wheel – he agreed without hesitation. Everyone can see the model. Far fewer people fund the client-360 data product underneath it, and that data product is what determines whether the model has anything trustworthy to say.
Run it like a product, and prove it
None of this works if people are forced to use it, which is the most counterintuitive thing Amin has built into ADP’s data organization. His team treats the data platform like a product, and they mean it. You do not have to use us, they tell the rest of the company. We are going to make you want to use us. Just as you choose a favorite provider or a hyperscaler, internal teams get to choose the platform, and the platform has to earn that choice.
“You don’t have to use us. We are going to make you want to use us. You’re going to choose to use us.”
— Amin Venjara, Chief Data and Product Officer, ADP
The philosophy sounds soft until you see how they measure it. A mandate produces compliance and quiet resentment, while chosen adoption produces the kind of pull Amin can point to, like the company’s annual Data and AI Day, which in its second year drew about 2,100 people in person and online. That number is a demand signal, and his team tracks demand the way any product organization would. They watch three things: the outcome of each use case, since value is specific and one use case might be revenue while another is a count of active users; the raw usage, meaning how many users and active users the platform has; and efficiency, which is where Amin offered the most useful number I heard all day. ADP runs a hub-and-spoke model, where a central hub builds the shared capabilities, and the spoke teams take them the last mile to a business outcome. To measure whether the hub is pulling its weight, they divide what the spokes spend on compute and storage by the total platform spend. A higher spoke share of that cost means the hub is more efficient, because the central team enables more value at the edges than it consumes in the middle. Most data leaders cannot tell you a number like that about their own organization.
Build the capability, then the AI has somewhere to stand
Bring it back to the equation Amin started with. When the business cannot use the data, more data rarely fixes it, because the thing standing in the way is a capability nobody named, funded, or built: a semantic layer, an entity resolution graph, or a client-360 data product an agent can call. The organizations getting value from AI right now are the ones that did the unglamorous capability work first, so the model has something solid to stand on.
If you lead a data organization, the Monday-morning version of Amin’s argument is a short audit. Walk your list of value claims and mark which ones are data with a real capability behind them, and which ones are data sitting in a lake with the capability still unbuilt. Then run the second group like a product, and measure whether your hub gets more efficient as the spokes grow. That is a harder conversation than buying another tool, and it is the one that actually moves the needle.
Listen to the full conversation with Amin Venjara on the Data Faces Podcast.
Based on insights from Amin Venjara, Chief Data and Product Officer at ADP, featured on the Data Faces Podcast.
Podcast highlights
[0:24] What Amin wanted to be growing up: a Mets fan’s dream of sports broadcasting, trumpet, and a love of math
[2:19] What a Chief Data and Product Officer at ADP does, and the scale of the company
[3:43] The CDOIQ session, and the premise that value equals data and capabilities
[4:25] The contractor and the backyard, and why data teams lose the room
[5:21] The half executives miss: capabilities, not just data
[6:07] Semantic layer, entity resolution, and the stitching behind a client 360
[7:11] Treating the data platform like a product nobody has to use
[11:40] Two languages, and why translation is the data team’s job
[12:34] The annual Data and AI Day, and 2,100 people showing up
[13:16] The three things ADP measures: outcomes, users, and efficiency
[16:27] A data product that gives every chat app and agent full customer context
[17:25] Stop reinventing the wheel
Frequently asked questions
What does “value equals data plus capabilities” mean?
Amin Venjara’s formula holds that data alone does not create value; capabilities do. A capability is the engineering work that turns co-located data into something a business can use, such as a semantic layer that makes revenue mean one thing everywhere, or an entity resolution graph that lines the same customer up across systems. Executives tend to fund the data and forget the capabilities, then wonder why the business still cannot use what was ingested. The value comes from both terms together, not from the data alone.
What is a data capability?
A data capability is the specific engineering work that converts raw, co-located data into usable value. Amin Venjara points to a semantic layer that gives revenue, headcount, and customer count a single consistent definition, and an entity resolution graph that identifies the same customer across sales, service, finance, and support systems. The stitching that turns several systems into one coherent client 360 is a capability. Putting data in a lake does not produce these; a team must build them intentionally.
How is a data product different from a data lake?
A data lake is a place where raw data from many systems is collected. A data product is a curated, reusable asset built on top of that data, with customer IDs resolved, definitions standardized, and lineage and refresh cadence maintained. In Amin Venjara’s client-360 example, one data product normalizes customer data across systems so a chat application or agent can call it for full context, instead of every application reinventing that work. The lake stores the data; the data product serves it.
What is a product-led data platform?
A product-led data platform is run like a commercial product, with internal teams as customers who choose to use it rather than being forced to. At ADP, Amin Venjara’s team tells the company, “You don’t have to use us; we’re going to make you want to use us.” Adoption is earned through usefulness, and the platform team tracks outcomes, active users, and efficiency the way any product organization tracks demand. The approach replaces mandated compliance with genuine pull from the business.
How do you measure a data platform’s efficiency?
Amin Venjara’s team uses a hub-and-spoke metric: divide what the spoke teams spend on compute and storage by the total platform spend. A higher spoke share means the central hub is enabling more value at the edges than it consumes in the middle, which signals an efficient hub. ADP tracks this alongside use-case outcomes and active users. The metric gives data leaders a concrete way to show whether their central platform is compounding value rather than absorbing it.
About David Sweenor
David Sweenor is the founder and host of the Data Faces podcast, where he talks with the people who are making data, analytics, AI, and marketing work in the real world. He is also the founder of TinyTechGuides and a recognized top 25 analytics thought leader and international speaker who specializes in practical business applications of artificial intelligence and advanced analytics.
With over 25 years of hands-on experience implementing AI and analytics solutions, David has supported organizations including Alation, Alteryx, TIBCO, SAS, IBM, Dell, and Quest. His work spans marketing leadership, analytics implementation, and specialized expertise in AI, machine learning, data science, IoT, and business intelligence. David holds several patents and consistently delivers insights that bridge technical capabilities with business value.
Books
Artificial Intelligence: An Executive Guide to Make AI Work for Your Business
Generative AI Business Applications: An Executive Guide with Real-Life Examples and Case Studies
The Generative AI Practitioner’s Guide: How to Apply LLM Patterns for Enterprise Applications
The CIO’s Guide to Adopting Generative AI: Five Keys to Success
Modern B2B Marketing: A Practitioner’s Guide to Marketing Excellence
The PMM’s Prompt Playbook: Mastering Generative AI for B2B Marketing Success
Follow David on Twitter @DavidSweenor and connect with him on LinkedIn.
Footnotes
ADP. “ADP Corporate Overview.” Accessed August 2026. https://www.adp.com/-/media/corporate-overview/adp-corporate-overview.pdf. ADP publicly reports serving more than 1.1 million clients across 140+ countries and providing payroll to over 42 million workers, roughly one in six U.S. workers. The “$3 trillion a year” and “20% of the U.S. working population” figures are Amin Venjara’s characterizations on the podcast. ↩