Kenvue’s Best Practices for Building Data Products That Deliver Value

If you’re in the business of making data usable—and valuable—you know the struggle: how do you move fast, deliver impact, and maintain trust all at the same time?

That’s the paradox many organizations face in today’s AI-driven environment. Data teams are decentralized, innovation is fast, and the pressure is real. But if governance and trust don’t keep pace, the whole thing breaks down. Data products and creating an internal data products marketplace have emerged as key capabilities for this balancing act. So, how can data leaders get started on the path to building them?

To learn the answer, I hosted a recent webinar with Nathan Caplan, Lead Analyst for Data Catalog at Kenvue (formerly Johnson & Johnson’s consumer healthcare company). Kenvue manages household brands like Neutrogena, Tylenol, and Aveeno. And they’re doing some really impressive work transforming their data catalog into a powerful, business-friendly marketplace for data products.

Here’s a recap of our conversation—and a few things every data leader should think about when building data products for real business impact.

 See the full webinar, or read on to learn the key takeaways.

The evolution from technical metadata to business-ready data products

Kenvue manages an impressive portfolio of household brands that millions of consumers rely on daily. This diverse product portfolio creates unique data challenges and opportunities, making effective data management critical to business success. "We are a company that is also very data-centric,” Caplan says. “We have a lot of data products that we build based on data regarding these products, whether it be related to marketing or who sells our products."

For a company like Kenvue that depends on consumer insights, market trends, and supply chain efficiency across multiple brands, the ability to transform raw data into business-ready information is not just a technical challenge—it's a competitive necessity.

Kenvue’s data journey began where a lot of organizations start: technical metadata tools. Tools like AWS Glue Catalog and Informatica EDC helped Caplan and his team inventory their data assets—but didn’t bring the business along for the ride. It wasn’t until they implemented Alation that things really started to change.

"It wasn't until I transitioned over to Johnson and Johnson and using Alation that I found that we were able to finally document the why of data,” he shares. “Well beyond just documenting your columns and your tables and your schemas, we were finally able to really explain why the data product exists and what additional information you might be wanting to find out from it.”

That shift—from raw technical metadata to curated, context-rich data products—was a game changer. Especially for a company like Kenvue, where consumer insights, marketing performance, and supply chain data are central to business success.

Bridging the business-technical divide

At the heart of Kenvue's data product transformation was a fundamental realization: technical and business users speak different languages when it comes to data.

Caplan highlights this challenge: "Tech speak does not equal business speak. You are going to run into issues consistently if your tech community is driving documentation on their data catalog without input from business. The two have to go hand in hand together."

This disconnect became evident when even senior leaders struggled to locate data:

"Very early on in my career at J&J, I had a VP ask me where he could find a certain data product. And I didn't know what that data product was because no schema, no table, no columns were named what he was referring to... there was a disconnect."

This gap between technical language and business terminology represents a critical barrier to data democratization that many organizations face today. It quickly grew clear that to overcome this challenge, the Kenvue data team would need to create an intuitive data discovery experience for the wider data consumer community. 

Tackling metadata overload with a data product mindset

By 2024, Kenvue was facing a growing challenge: the sheer volume of metadata flowing into their catalog was becoming overwhelming. We're talking millions of columns, millions of tables, hundreds if not thousands of schemas… and it becomes quite overwhelming." 

Their solution? Build a data product marketplace—a curated experience where users can browse, discover, and request data products just like they would on Amazon.

"There needs to be a guided approach in your data catalog to assist end users to find what they're looking for,” Caplan explains. “Ideally, you should only have to do a set number of clicks, ideally three, maybe four, by the time you find what you're looking for.”

Creating a data product framework: Kenvue's approach

Kenvue developed a solution centered around what they call "solution pages" in their data catalog. These pages, which house data product documentation, serve as a bridge between technical and business documentation.

These data product pages include several critical components:

1. Foundation documentation: "What is a data product from the beginning? It really is a collection of key fields, critical data elements... That is where you define the what and the why of your data product, as well as the who."

2. Integration with existing documentation: "What we encourage here at Kenvue is to also link your relevant SharePoint, Confluence, Jira, and make them available on the data product page. So that way you don't have to have duplication of effort in documenting your data products."

3. Centralized documentation: "This is your centralization of all relevant documentation, whether it be the data sources, the actual technical metadata that you're linking, or the BI sources like Tableau or Power BI report metadata."

4. Governance policies: "Being able to document your policies relevant to your data products, whether it be row-level access controls, column maskings for whether there's PII in your data product... That is critical to being documented and made available within your data product."

The result is a one-stop shop for understanding and using a data product — built for both business and technical users.

Best practices for data product implementation

Caplan shares several best practices from Kenvue's data product journey, which I think other teams could learn from: 

1. Design for discovery

"We were encountering users getting very frustrated searching for their data product documentation, and we pushed forward more with a guided navigation approach,” Caplan reveals. “So with left-handed navigation and with a customizable UI... you're able to very easily put the data products in front of your end users."

This focus on user experience reflects a critical shift in data management philosophy—from technical storage and organization to human-centric design that prioritizes findability. By reducing friction in the discovery process, Kenvue has increased data product adoption.

2. Involve both business and technical teams

Put business documentation first, followed by technical details. This ensures the catalog meets the needs of users across the organization—not just data engineers.

"We want to make sure that those teams are both contributing to the documentation,” Caplan reveals. “We currently highlight business documentation upfront, and then we focus on the technical documentation lower down on the page."

3. Establish interconnected documentation

Link related documentation. Use templates. Mirror your org’s structure. Think of your catalog as a knowledge graph, not a filing cabinet. 

Caplan emphasizes the importance of "stitching together relevant documentation and really defining almost like your organization, your org structure as it relates to data products." This interconnection makes it "really easy to jump between data product documentation and other functions."

4. Identify reusable components

When you know which fields show up in multiple products, you can govern smarter — and create consistency across the board. The critical data elements that are most referenced are clearly the most critical. 

By mapping these relationships, Kenvue has prioritized governance efforts on the most impactful data elements, creating a virtuous cycle where improvements to foundational data components automatically enhance multiple downstream data products.

Together, these best practices form a framework that organizations can adapt to their own data product initiatives, regardless of industry or scale. The next logical step in this evolution is implementing the technical infrastructure to support these principles.

Technical implementation: From templates to ontologies

Kenvue started with term templates but has since evolved to using Document Hubs in Alation, which provide greater customization options and parent-child relationships.

"Document Hubs allows you to really move, and it enables greater structure and greater compartmentalization. So if you have a function and you have sub-function and within that sub-function you have multiple teams that are then building data products, imagine you could have a document serving as your data product that fits in those different sub-functions, sub-team folders,” Caplan illustrates.

A particularly powerful aspect of their implementation is the ontology, which defines relationships between different data elements:

"Being able to define those relationships between the who, what, and why in the data catalog is where you get the most business value,” Caplan emphasizes. “It's where you're able to define reusability. How are key data elements reusable amongst data products?” This deeper understanding enables data users to more easily identify the most critical data elements. 

Data product ownership: A critical success factor

One of the most challenging aspects of data product implementation is establishing clear ownership. At Kenvue, Caplan explains their approach to different ownership roles:

"CDE owners and data product owners are very typically in our organization, different people... I find that the data products owners, there's two, you're gonna have a BPO and a TPO, technical product owner, business product owner and the business product owner is the one giving the business requirements that is for what is being built, and then the technical product owner is translating that into tasks that is then being handed off to the implementation team to build."

When asked about how many data products were needed before stakeholders found value, Caplan shares an important insight about starting with key priorities:

"We started off with our big rocks, or OKRs if you will... and I would say we started off with about four of them to begin with. And immediately those big-rocks people from those same functions, but worked on different teams who were building different data products, went, ‘I need to build something similar.’ And it grew from there."

The result? After starting with just four, "we now have over 70 data products documented."

As organizations increasingly build AI applications, data products become even more critical. Caplan observes that even with AI applications, "the foundation is still based on a collection of data fields somewhere within your data repositories. And as a result, we still are of the opinion that the way we've been documenting data products, whether they're an AI product or not, is still applicable."

Key takeaways: The path to data product success

The three key takeaways from the discussion that struck me most were:

1. Bridge the gap between business and technical users: Document not just the data, but the meaning, who it's for, what it's used for, and why it matters.

2. Structure your catalog around products, not just raw data assets: This provides a better way to organize into curated business-ready packages for real business use cases.

3. Define clear ownership and relationships: Establish a clear ontology across business functions, data products, elements, and metrics, with ownership at each level.

These principles form the foundation of a successful data products strategy that can scale with your organization's needs. By implementing these practices, companies like Kenvue have transformed how business users interact with data, moving from frustration to empowerment. As organizations increasingly adopt AI and automated decision-making, having this solid foundation of well-documented, business-oriented data products becomes not just advantageous but essential for competitive operations.

Conclusion: The future is data products

If there’s one thing Kenvue’s story makes clear, it’s this: a catalog of metadata isn’t enough. To deliver real business impact, you need data products and a data product marketplace—something that brings clarity, context, and curation to your data ecosystem.

Kenvue's experience demonstrates that with the right approach, organizations can bridge the technical-business divide, make data more discoverable, and ultimately drive greater business impact through their data and AI investments.

By implementing a data products strategy that incorporates both business context and technical implementation details, organizations can ensure their data assets deliver value to all stakeholders - from technical teams to business users to AI applications.

To learn more:

• See the Alation Agentic Platform, Documentation Agent, and Alation Data Quality product pages

• Explore the Data Products Marketplace

• Read the press releases: Alation Agentic Platform, Data Products Marketplace, Data Quality

• Explore our professional services offering, the Data Products Playbook