Building Your First SAP Data Product: A Practitioner's Guide

Why Data Products Matter Now

For most of the analytics industry's history, the unit of delivery has been the report, the dataset, or the system. You built a financial reporting solution in SAC. You created a sales dataset in Datasphere. You exported data to Salesforce. Each artifact was built for a specific consumer, solving a specific problem, and when new consumers wanted similar data, you rebuilt it.

Data products flip this paradigm. Instead of building for a single consumer or use case, you build for a platform of consumers. A revenue recognition data product isn't built just for the CFO. It's built for the finance team, the external auditors, the product management team measuring go-to-market performance, and eventually the board reviewing quarterly results. The interface is standardized. The data quality rules are transparent. The refresh schedule is predictable. Consumers can discover it, understand what it covers, and integrate it into their workflows without asking you to rebuild it for their specific need.

The shift from "building for each consumer" to "building products for platforms of consumers" is what makes data products powerful. And SAP's platform—Datasphere, Business Data Cloud, and BDC Connect—is finally mature enough to make this practical rather than theoretical. That's why 2026 matters: custom data products, BW data through the Data Product Generator, catalog governance with steward approval (since September 2026), and BDC Connect for Databricks, Snowflake, and BigQuery are all available, so you can implement this pattern in production with supported tooling without waiting for Data Product Studio.

What a Data Product Actually Is

Before diving into execution, let's be precise about what you're building. A data product is not a report, a dashboard, or a dataset. It's the combination of four specific elements working in concert. Understanding each element determines whether your first data product succeeds or becomes another expensive artifact that nobody uses.

The first element is the data interface. This is the defined set of tables, columns, and relationships that you're exposing to consumers. Not your entire data model—a carefully curated subset that represents a specific business capability. Revenue Recognition exposes Invoice, Transaction, and GL Account tables with specific columns, relationships, and join logic. It doesn't expose your entire financial database; it exposes what consumers need to understand and analyze revenue.

The second element is governance. This includes both data governance—who can see what data, what refresh schedules apply, what quality thresholds must be met—and semantic governance, which means defining what each column means, how to calculate derived metrics, and which tables should be used together. Without this, you're delivering a dataset that consumers will interpret inconsistently. Revenue could mean gross revenue, net revenue, or cash receipts depending on which table the analyst queries. Governance makes the definition authoritative and prevents interpretation drift.

The third element is the contract. This is the published specification of what consumers can expect. What's the data freshness? How accurate must it be? When will it be updated? What's the SLA for support questions? What happens when the underlying data changes? A contract transforms data from "here's some tables" into "here's what you can reliably count on." Without a contract, your first request for a change breaks the product. With a contract, changes follow a defined process that protects both producers and consumers.

The fourth element is the platform. The data product doesn't exist in isolation. It lives in a discoverable catalog where business users can find it. It integrates with external systems through defined interfaces (SAC, BDC Connect, third-party BI tools). It has versioning so consumers can upgrade or stay on prior versions. It has quality monitoring so you know when the product is degrading. It has usage tracking so you understand where the product is valuable and where it's not. The platform is what makes data products sustainable at scale.

Reports and datasets have one or two of these elements. Data products have all four. If you're building something that's missing one, you're building something else—and there's nothing wrong with that, but you should be intentional about it rather than surprised when it fails like a data product.

Prerequisites: What You Need Before You Start

Not every organization is ready to build data products. Before you start, verify that you have the foundational pieces in place. Missing any of these will slow you down or cause you to build the wrong thing.

The first prerequisite is Datasphere governance discipline. You can't govern a data product without a sound semantic foundation. This means you need Spaces defined (who owns what), roles assigned (who can consume vs. create), and a modeling discipline in place. If your Datasphere is currently a free-for-all where anyone creates tables and entities as needed, you need to establish governance before data products. This typically takes four to eight weeks. You'll define Space ownership (usually by business domain), create a modeling standard (how to name tables, how to structure relationships), and implement access controls. If this sounds like overhead, it is. But it's prerequisite overhead. Data products built on weak governance become governance nightmares.

The second prerequisite is semantic modeling maturity. I don't mean perfection—I mean that your Datasphere contains models that are actively used and understood. You've built revenue models, customer models, or cost models that business users rely on. This is important because data products are built on top of existing models. If you have no semantic foundation, you'll build your first data product and discover you need to fix the underlying model, which means rebuilding the product. Building on a working foundation is substantially easier. If you're starting from scratch in Datasphere, expect your first data product to also be a proof of concept on semantic modeling. That's fine, but budget for it.

The third prerequisite is the right commercial entitlement: SAP Business Data Cloud. Custom data products for BDC can only be created when your Datasphere tenant is part of a BDC formation, and since January 1, 2026 new Datasphere capacity is licensed through BDC anyway. BDC Connect, which shares products with Databricks, Snowflake, or BigQuery, is a separate BDC capacity service with its own provisioning, and Data Product Studio is announced as part of BDC. Confirm with your SAP account executive which capacity services your contract includes.

The fourth prerequisite is stakeholder agreement on what "platform" means. Data products only work if there's a shared understanding that you're building for multiple consumers with different needs. If your organization is used to custom solutions for each consumer, you need to have a conversation about why data products matter and what it means to accept slightly less customization in exchange for faster time-to-value. This conversation often takes longer than the technical work. Having the business stakeholders aligned before you start technical work prevents you from building a product that nobody wants.

Step 1: Identify the Right First Data Product

Choosing the right first data product is critical. Too ambitious, and you'll be managing a complex project. Too simple, and you won't see the value. The right first data product has three characteristics.

First, it has clear, defined consumers. Not potential consumers—actual people or teams who have asked for this data, complained that getting it is hard, or are currently getting similar data from multiple conflicting sources. Revenue recognition is ideal because the finance team needs it, the auditors need it, and product management needs it. They're already asking for this data. You're not creating a need; you're meeting an existing one. This matters because it means you have a ready audience for your product launch. They'll provide feedback, use cases, and iteration guidance. Start with a consumer-driven use case, not a data-driven one.

Second, it has a clear business capability boundary. Revenue Recognition is clean. You're exposing what revenue is, how it's calculated, and what dimensions it breaks down by. Avoid products that blur multiple capabilities. "Finance" is too broad. "Monthly Financial Reporting" is reasonable. "Anything anyone in finance might want" is too sprawling. Clear boundaries make the product easier to define, govern, and evolve. They also make it easier to explain to consumers. "This product gives you revenue metrics" is clearer than "this product has financial data."

Third, it has data that's already reasonably clean and well-governed. Your first data product shouldn't also be your first major data quality initiative. If the underlying data is messy, you'll spend months fixing data issues while trying to build a product. Choose a business capability where the source data is in reasonably good shape. If revenue recognition data is a mess, choose customer accounts instead. If customer accounts is also messy, choose procurement events. The goal is to ship your first product quickly so you can learn what good governance looks like before you tackle harder problems.

From a timeline perspective, I typically recommend starting with a product that covers one to three source systems. Revenue Recognition might pull from SAP's billing and accounting document tables (VBRK, BKPF/BSEG, or the Universal Journal ACDOCA in SAP S/4HANA). Customer Accounts might come from your CRM and SAP's customer master. Anything requiring more than three source systems is probably overcomplicating your first product. Save the complex orchestration for your second or third product, after you understand the patterns.

Step 2: Define the Semantic Model in Datasphere

The semantic model is the foundation of your data product. This is where you define what the data is, how it's structured, and what it means. In Datasphere terms, you're working with tables, views, associations, and analytic models—and, for a BDC data product, local tables in a file space that become your data product interface.

Start by documenting the consumer interface. Create a simple spreadsheet that lists exactly what columns you're exposing and why. For Revenue Recognition, this might be: Invoice ID, Invoice Date, Customer ID, Revenue Amount, GL Account, Business Unit, Region. For each column, document what it means, where it comes from, and any calculation logic. This documentation is lightweight, but it forces you to think through what you're actually exposing. It's your contract in draft form.

Next, map the source systems. Where does each column come from? If Invoice ID comes from SAP's VBRK table, document that. If Revenue Amount requires joining billing documents with accounting line items and applying GL account logic, document that. If Business Unit comes from a separate master data system, document that. The goal is understanding data lineage before you build the model. This prevents surprises later when you discover that Revenue Amount doesn't exist in SAP and requires custom calculation.

Then, build the model in Datasphere. For SAC consumption, that means fact views with associated dimensions and an analytic model on top (the older Analytical Dataset semantic usage has been deprecated since release 2023.13). For a custom data product in BDC there is one more constraint: its artifacts must be local tables in a file space—SAP HANA Data Lake Files, Datasphere's object store. In practice you land the source data there with replication flows, the BW Data Product Generator, or Spark-based transformation flows, apply the business logic in that layer, and keep your analytic model for SAC on top. Your semantic model is not a copy-paste of SAP tables. It's a thoughtful curation that applies business logic. "Revenue Amount" might require summing invoiced amounts, applying deductions, and excluding specific transaction types. This logic lives in the data product's transformation layer and semantic model, not in consumer reports. This is what makes data products powerful—the logic is defined once, in one place, and reused everywhere.

As you build, focus on getting the dimensions right. Dimensions (Customer, Region, GL Account, Business Unit) determine how consumers can slice and analyze the data. If you're missing a dimension that consumers need, they'll ask for it, and you'll have to rebuild. Spending time getting dimensions right prevents rework. Talk to your consumers—what dimensions do they actually analyze? Revenue by Customer, by Region, by GL Account, and by Month? Include those. Revenue by Salesperson? Only if that's actually a dimension they need. In early discussions, you'll surface dimensions you hadn't considered. That's valuable. The semantic model build is where you incorporate that feedback.

Step 3: Add Quality Rules and Governance

Once your semantic model is defined, you add the governance layer. This is often where data product projects stall because governance feels abstract. Make it concrete.

First, define data quality rules. Be clear about tooling: Datasphere's data validation checks key and hierarchy consistency in your models, but it has no general business-rule engine (SAP confirms this in KBA 3493549). Implement business checks as validation views or transformation steps that run in your task chains, or use a partner tool such as Collibra Data Quality & Observability, which supports Datasphere. For Revenue Recognition, quality rules might include: invoices must be dated within the current fiscal year, revenue amounts must be positive, GL accounts must exist in the chart of accounts master, and monthly invoice counts must not drop more than 20% from the prior month. Each rule serves a purpose. They catch data issues automatically, before consumers see them.

Don't go overboard with quality rules. I've seen organizations create fifty rules and then spend all their time investigating false positives. Start with three to five rules that catch the most common issues. As you iterate, you'll discover which rules matter and which ones are just noise. The goal is making sure that when a consumer uses your data, they're working with data that meets your stated standards.

Second, define access controls. Who can consume this data product? In most cases, you'll start with a broad set of consumers—anyone in finance, for example. But you might have sensitive data. If Revenue Recognition includes customer names and deal values, you might restrict access to the finance team and external auditors only. Datasphere's space permissions and row-level data access controls, together with the BDC catalog's terms of use and steward approval, let you define this granularly. Be explicit about it. Document who has access and why. This prevents "can I see this data?" arguments later.

Third, document assumptions and limitations. Create a simple document—a page or two—that explains what the data covers and what it doesn't. Revenue Recognition covers SAP invoices from the LATAM region for the past three fiscal years. It does not include manual journal entries, customer-initiated credit memos, or invoices still in draft status. These seem obvious to you, but they're not obvious to someone seeing the data for the first time. Being explicit prevents misinterpretation and supports your governance story.

Finally, establish a change process. How will consumers request changes to the data product? What goes into version 2.0? Who decides? Document this. It might be as simple as "all change requests go to the finance data owner, who reviews them monthly." It might be more formal if you're managing multiple products. The point is having a defined process. This prevents feature creep and makes the product sustainable.

Step 4: Package the Data Product

Once your interface is defined and governed, you package it as a data product. Today that happens in Datasphere's Data Sharing Cockpit. Data Product Studio, SAP's planned visual workspace for the same job, had not been confirmed as generally available when this guide was reviewed in November 2026, so don't wait for it.

In the Data Sharing Cockpit, you first create a data provider profile with the Formations visibility, then create the data product: business and technical name, description and product details, and the local tables from your file space that form its artifacts. You're not exposing your entire Datasphere space; you're exposing exactly what consumers need.

You'll also define the product version yourself. Your first release is version 1.0. When you add a column, that might be version 1.1. When you significantly change the data model, that's version 2.0. Until tooling manages versions for you, keep the previous version available as a separate artifact while consumers migrate. This is critical for products with many consumers. You can't upgrade everyone simultaneously.

Once listed, the product appears in the Business Data Cloud catalog, where consumers discover it, read its description, and request access. Think of this as your data marketplace. Make the descriptions clear and compelling. Bad descriptions: "Revenue data." Good descriptions: "All SAP invoices from the LATAM region, including revenue amount, invoice date, customer ID, and GL account. Updated daily at 6am UTC. Questions: contact [email]." The better your catalog entry, the more likely the right consumers find and use your product.

You'll also decide how consumers access the product. Internal consumers can install it into a Datasphere space and build analytic models and SAC stories on top, or use it in SAP Databricks or SAP Snowflake. External platforms reach it through BDC Connect, which shares it with Databricks, Snowflake, or BigQuery without copying. This is what makes the product portable—the same data product can be consumed different ways depending on where the consumer's tools live.

Step 5: Publish and Share

Publishing is where your data product moves from internal project to actual product. This is also where you discover whether you've built something people want.

Start with internal publication. Once the product is listed, users with catalog access can discover Revenue Recognition and request access; since September 2026, a data steward can approve each request against the terms you attach. You'll get initial feedback, find data quality issues you didn't catch, and discover that analysts want a column you didn't include. This is good. You're learning from real usage, not guesses. Plan to do at least two iterations based on internal feedback before you consider the product "mature."

For internal use, the distribution mechanism is usually direct—consumers install the product into their Datasphere space and build analytic models and SAC stories on top. This is straightforward because everyone works in the same SAP environment. If you're managing multiple products, track who requested and received access in the catalog and use Datasphere's monitoring to see which products are driving value.

Once you're confident in the product's stability, you can extend distribution beyond the SAP environment using BDC Connect. If you have Databricks, Snowflake, or BigQuery, you can share your data product through these platforms. The consumer experience is different—they query your product from their data lake, not from Datasphere—but the product remains the same. This is powerful because it lets data engineers and data scientists in your organization work with authoritative data without rebuilding it in their preferred tools.

For genuinely external distribution—sharing data with business partners, customers, or external service providers—you'd use Datasphere's Data Marketplace (a data provider profile with private contexts for invited consumers), or you'd create a restricted view of the product with anonymized or aggregated data. This is less common for first data products, but it's worth knowing is possible for future products.

Step 6: Measure Consumption and Iterate

The work isn't done when you publish. In fact, it's just beginning. The product's value is determined by adoption and use. This is where you shift from "building the product" to "managing the product."

Set up consumption tracking immediately. Combine what your platforms already record—access requests and approvals in the BDC catalog, monitoring in Datasphere, and query history on BDC Connect partners such as Databricks, Snowflake, and BigQuery—to see which users access the product and whether consumption is growing or stagnant. After one month of publication, you should know: how many consumers are using it, which ones are heavy users vs. occasional, and what's the main use case driving adoption.

Establish a feedback mechanism. It doesn't need to be formal—an email address and a monthly check-in is often enough. Ask consumers: are you getting value? What's missing? What would make this product better? Be prepared for feature requests. "Can you add revenue by product line?" is common. Some of these requests become version 1.1. Some become version 2.0. Some are out of scope and should be a new product.

Plan to refresh and iterate continuously. Your first data product will have issues. Data quality issues you missed. Dimensions you should have included. Consumer workflows you didn't anticipate. Fix these as you discover them. After three months of production use, you'll have a solid understanding of what good looks like. That feedback becomes the blueprint for your second and third data products.

Track the business impact. Did using Revenue Recognition data product reduce the time to close? Did it eliminate conflicting revenue numbers across finance and sales? Did it improve forecast accuracy? Connect consumption metrics to business outcomes. This is what justifies further investment in data products. "We published a product and analysts used it" is nice. "We published a product and it reduced close time by three days" is what gets budget approved for your next product.

Common Mistakes to Avoid

I've watched organizations ship data products successfully, and I've watched them fail. The failures follow predictable patterns. Avoiding these mistakes saves months of rework.

The first mistake is building without clear consumers. If your product isn't solving an immediate problem for an identified person or team, you're building speculatively. Speculative products get built, launched, and abandoned. Start with a problem statement: "the finance team spends four hours monthly reconciling revenue numbers from three sources." That's a clear problem. "We should have a revenue product" is speculative. Start with the problem.

The second mistake is underestimating data quality work. You think the data is clean because it's been working fine for your current reports. But data products expose data at a more granular level. Suddenly, you're seeing invoice-level data instead of monthly summaries. You discover your deduction logic has gaps. You find invoices with invalid customer IDs. These quality issues take time to fix. Budget for a data quality week before you launch. If the data is messier than you thought, budget for two weeks. Bad data ruins a product faster than anything else.

The third mistake is launching with too many dimensions. You think: "while we're building Revenue Recognition, we should add all these other dimensions." Now your product covers revenue, costs, and headcount. You're managing three different data sources, three different quality rules, and consumers confused about what the product covers. Start narrow. Revenue and revenue dimensions only. Costs are a separate product. Headcount is separate. Narrow products are easier to govern and easier to explain.

The fourth mistake is launching without a contract. You think: "once we're in production, we can define the SLA." Now a consumer builds a critical process on your product, and you change the refresh time from daily to weekly. Their process breaks. They lose trust. You need a contract before launch. "This product refreshes daily at 6am UTC. We maintain 99.5% uptime SLA. Changes require 30 days notice." This contract protects both you and consumers.

The fifth mistake is treating the product as done after launch. "We published it, now we can move on to the next project." No. Products need ongoing maintenance. You need to monitor quality, respond to support requests, and plan versions 1.1 and 2.0. Allocate 20-30% of your data team's time to managing published products. This is what makes them sustainable.

The sixth mistake is launching without governance discipline. You think: "governance can come later when we scale." But bad governance habits are hard to break. If you allow ad-hoc changes in the first month, you'll still be allowing ad-hoc changes in month twelve. Enforce your change process from day one, even if it feels like overhead. This sets the right precedent and prevents chaos later.

What Good vs. Bad First Data Products Look Like

Let me paint two pictures. One is a first data product that succeeds. The other fails. The difference isn't luck.

The bad data product: A team spent three months building a "Finance Data Product" covering revenue, costs, headcount, and accruals. It pulls from five source systems. During development, they found multiple data quality issues and implemented extensive transformation logic. Nobody asked for the product; the team thought finance needed it. They launched it in the catalog with a one-sentence description: "Finance data." A few people from the finance team accessed it, got confused about what columns meant and where they came from, and asked IT for their own query access to build reports from scratch instead. The product attracted minimal adoption, nobody was assigned to maintain it, and within six months, it became stale and was de-published.

The good data product: A team started with clear consumer feedback. The finance team was spending time reconciling customer accounts across SAP and their CRM. They built a "Customer Accounts" product covering account ID, account name, payment terms, and billing address. It pulled from two systems (SAP's KNA1 and Salesforce's Account object). The data was reasonably clean; they spent one week fixing a few data quality issues. They launched with clear documentation: what the product covers, refresh schedule (daily), and how to get support. They invited the finance team to test it, incorporated feedback, and published version 1.0. Within two weeks, three finance analysts were using it daily to replace their manual reconciliation process. After one month, they'd saved 40 hours of manual work. That success drove demand for a second data product. The team allocated someone to maintain the Customer Accounts product and started planning the next one.

The difference isn't complexity. It's clarity. The good product knows who it's for, what it solves, and how to measure success. The bad product tries to be everything to everyone and solves nothing specifically.

Timeline: What's Realistic for Your First Data Product

Organizations often ask: how long should this take? The answer is: 4-8 weeks from start to production publication, depending on data quality and complexity.

Week 1-2: Discovery and Planning. You identify the data product opportunity, talk to consumers, and document the interface. What columns are you exposing? What dimensions? Where does the data come from? What quality issues exist? This is lightweight work—interviews, documentation, and planning. Don't overplan; plan enough to know what you're building.

Week 3-4: Semantic Model Build. You build the Datasphere model that supports your consumer interface. If the source data is clean, this is straightforward. If data quality issues emerge, this takes longer. You're also establishing governance: access controls, quality rules, and change processes. This is the most variable stage. Clean data and simple logic: one week. Messy data or complex transformations: three weeks. Budget accordingly.

Week 5: Packaging. You create the data product in Datasphere's Data Sharing Cockpit (or Data Product Studio once it is generally available) on the persisted tables, write the catalog description, set your version convention, and list it in the catalog. This is usually a week of work, often running in parallel with the final semantic model iterations.

Week 6: Testing and Hardening. You test the product with a small group of consumers. You verify that quality rules work, that access controls function correctly, and that the data matches expectations. This usually surfaces one or two things you need to fix. Fix them. This is one week of work.

Week 7-8: Launch and Initial Support. You publish the product, invite consumers, and provide active support. Most questions are basic: "how do I access this?" "what does this column mean?" You're learning how people use the product and discovering edge cases. Some organizations launch in week 6 and spend weeks 7-8 iterating. Others want a full validation week before launch. Both are reasonable approaches.

A few scenarios push this timeline. If your data quality is poor, you'll spend weeks 3-4 and most of week 5 fixing data issues. If you need to change source system configurations or update master data, that adds time. If your consumers are hard to reach or slow to give feedback, everything slows down. But assuming reasonably clean data and engaged consumers, 4-8 weeks is realistic.

Don't try to compress this. I've seen organizations push "ship in two weeks" targets and regret it. You end up launching with data quality issues, incomplete governance, and an angry set of consumers. Spend the time getting it right. The first data product is your foundation. Do it well.

The Path Forward

Your first data product is not the end of your data strategy. It's the beginning. Once you've shipped one, you'll understand what good governance looks like. You'll have patterns for building semantic models. You'll have processes for packaging and distributing products. Your second and third products will be easier, faster, and better quality than your first.

More importantly, you'll have proof that data products work. That executives should fund your data platform strategy. That business users prefer products to custom solutions. That one good data product prevents ten bad ad-hoc reports. Use that proof to drive your next investments.

The shift from building reports to building products is the shift from supporting analytics to driving a data strategy. With custom data products, catalog governance, and BDC Connect already available—and Data Product Studio still to come—that shift is possible in the SAP ecosystem today. Start with one product, executed well. Everything that follows gets easier.