Internal data platforms as products

# Internal data platforms as products

In 2019, Airbnb's data platform team discovered something uncomfortable: they had built a beautiful, technically elegant data infrastructure that almost nobody trusted. Analysts were quietly maintaining shadow pipelines. Product teams pulled metrics from three different sources and got three different answers. The platform team measured success in tables ingested and queries served, but the people who mattered, the internal consumers, were routing around them. Airbnb's response was to treat the platform not as plumbing but as a product with users, a value propositionvalue propositionA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.Voir la définition complète →, and a churn problem. That reframing, captured later in their "Data QualityData QualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.Voir la définition complète → at Airbnb" and Minerva metric-layer work, is the discipline this lesson is about.

The trap is seductive because it feels like progress. You ship a new lakehouselakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.Voir la définition complète →, a feature storefeature storeA centralised repository managing ML features, ensuring consistency between training and serving environments.Voir la définition complète →, a self-serve BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.Voir la définition complète → layer. The infrastructure is real. But shipping infrastructure is not the same as creating value, and a CDO who confuses the two will fund a platform that gets built, admired in architecture reviews, and abandoned by the analysts and product managers it was meant to serve.

From infrastructure owner to product owner

The core shift is who defines "done." When you own infrastructure, done means the system is up, the SLA is met, the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → ran. When you own a product, done means an internal customer accomplished a job faster or better than they could before, and would be annoyed if you took the tool away.

This is not a semantic dressing-up of the same job. It changes four concrete things about how you run the platform team.

It changes what you fund. Infrastructure roadmaps are organized by component: "migrate the warehouse," "upgrade orchestration," "add streaming." Product roadmaps are organized by user job: "let a marketing analyst build an attribution modelattribution modelA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results.Voir la définition complète → without filing a ticket," "let a data scientist promote a feature to production in a day, not a sprint." Every technical initiative must ladder up to a named job for a named user segment. If it doesn't, it's cost, not investment.

It changes who you hire. Product-run platforms have product managers, people whose job is to talk to internal users, prioritize ruthlessly, and say no. The absence of a data platform PM is the single most reliable predictor that a platform is being run as infrastructure. Engineers optimize for the elegant general case; PMs optimize for the specific job that unblocks the most valuable users.

It changes your relationship with consumers. Infrastructure owners field tickets. Product owners run discovery. The difference shows up in a question: when a team asks for a new dataset, do you fulfill the request, or do you ask what decision they're trying to make? The second question routinely reveals that the requested dataset is the wrong solution, and that a curated metric or a self-serve template would serve ten teams instead of one.

It changes how you measure yourself, which is the heart of this lesson.

Segment your internal customers

You would never build an external product for "everyone." Do not build your internal platform for "the business." Your users cluster into recognizable segmentssegmentsDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.Voir la définition complète → with sharply different needs:

• Data engineers and platform-adjacent builders who need primitives, APIs, and control.
• Analysts and analytics engineers who need curated, trustworthy tables and a semantic layer, not raw logs.
• Data scientists who need reproducible environments, feature access, and a fast path to production.
• Business power users (ops managers, marketers, finance) who need governed self-serve, dashboards and metrics they can slice without SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Voir la définition complète →.
• Executives who consume, and who mostly need one number they trust.

Each segment has a different definition of a good day. Serving the platform builders with more primitives while starving the business power users of governed self-serve is a common and expensive misallocation, it feels like deep technical work while the largest user population churns to spreadsheets.

Measuring adoption and satisfaction, not output

Here is the reframing made operational. Stop reporting infrastructure output metrics to your leadership peers, tables ingested, uptime, petabytes stored. Those are health metrics for your engineers, not value metrics for the business. Report a product scorecard.

The four metric families

1. Adoption. Who is actually using the platform, and are they coming back? Borrow the SaaS distinction between registered and active users. A team that provisioned access six months ago and hasn't run a query is not a user. Track:

• Weekly and monthly active users per segment.
• Breadth: percentage of eligible teams that have onboarded.
• Depth: are they using core capabilities or just one dashboard?

2. Retention and stickiness. The most honest platform metric is whether people keep coming back voluntarily. Cohort retention curves, do the analysts onboarded in Q1 still active in Q3?, expose whether you built something valuable or merely mandated. A platform that survives only because usage is compulsory has a satisfaction problem it's hiding.

3. Time-to-value. How long from "a team wants to answer a question" to "they have a trustworthy answer"? This is your platform's core throughput metric. Two sub-measures matter enormously:

• Time-to-first-insight for a new user (onboarding friction).
• Time-to-production for a new data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Voir la définition complète → or model (delivery friction).

If onboarding a new analyst takes three weeks of access requests and environment setup, your adoption ceiling is set by that friction, not by your capabilities.

4. Satisfaction and trust. Run an internal NPSNPSNet Promoter Score (NPS) measures customer loyalty by asking how likely customers are to recommend a brand, then subtracting detractors from promoters.Voir la définition complète → or CSATCSATCustomer Satisfaction Score, a direct measure of satisfaction captured right after a specific interaction or experience, usually on a short rating scale.Voir la définition complète → on the platform, segmented by user type. But the more revealing metric is trust: when a number appears on your platform, do consumers act on it, or do they re-verify it elsewhere? The presence of shadow pipelines and reconciliation spreadsheets is a direct, measurable trust signal. Count them.

A useful synthesis is a single quarterly Platform Product Scorecard you present alongside the infrastructure health dashboard:

| Metric | Segment | Target | Trend |

|---|---|---|---|

| MAU / eligible teams | Analysts | 80% | ↑ |

| 90-day retention | Data scientists | 70% | ↓ |

| Time-to-first-insight | Business users | < 3 days | flat |

| Trust NPSNPSNet Promoter Score (NPS) measures customer loyalty by asking how likely customers are to recommend a brand, then subtracting detractors from promoters.Voir la définition complète → | All | > 30 | ↑ |

| Shadow pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → count | All | decreasing | ↓ |

The declining retention among data scientists in that example is the kind of signal an output-only dashboard would never surface, and it's exactly where a CDO should point the next quarter's investment.

Instrument the platform to produce these metrics

You cannot report on adoption you don't measure. Treat the platform's own telemetry as a first-class product requirement, not an afterthought. Log usage events the way a SaaS company instruments its app, every query, dashboard load, model deployment, and dataset access, tied to a user and a team.

# Platform usage event schema — emitted on every meaningful interaction
event:
  user_id: analyst_4471
  team: growth-marketing
  segment: business_power_user
  action: dashboard_view      # query_run | model_deploy | dataset_access
  asset_id: attribution_v3
  latency_ms: 820
  success: true
  timestamp: 2024-11-04T14:22:00Z

This event stream is what powers your cohort retention, your time-to-value measurement, and your ability to spot a segment quietly churning. It also lets you find your power users and your abandoned assets, the datasets nobody has touched in ninety days that you're still paying to maintain.

Running the platform like a product team

Metrics without operating rhythm are just dashboards. The product reframing has to change how the team actually works week to week.

Treat internal teams as customers you can lose

The most powerful discipline is optionality. When internal teams *can* build their own pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → or buy a point solution, your platform has to earn its usage. Some CDOs resist this, they mandate the platform to guarantee adoption. But mandated adoption masks the very signal you need. The healthiest posture is: the platform should be so obviously better that teams choose it. Where you mandate (usually for governance or compliance reasons), acknowledge that you've suppressed the satisfaction signal and compensate by measuring it directly through interviews and trust metrics.

Prioritize with a value-versus-reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → lens

You will always have more requests than capacity. Prioritize by asking two questions of every candidate investment: how many users in how valuable a segment does this unlock (reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète →), and how much friction does it remove (value)? A self-serve semantic layer that unblocks 200 business users usually beats a bespoke streaming pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → for one high-status team, even though the streaming project is more technically interesting. The PM's job is to protect this discipline against the gravitational pull of the loudest internal stakeholder.

Publish SLAs and a contract, then honor them

External products make promises. So should yours. Publish data SLAs (freshness, availability, quality thresholds) per critical dataset, and treat a breach as an incident with a postmortem. This is what converts trust from a hope into a commodity. A finance team that knows the revenue table is guaranteed fresh by 6 a.m. with a 99.5% reliability record will stop building their reconciliation spreadsheet. That abandoned spreadsheet is your ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.Voir la définition complète →.

Dogfood and do discovery

Sit your platform PMs with the analysts for a day a month. Watch a new hire onboard and time it. The teams that run great internal platforms know their users' workflows in visceral detail, they've felt the twenty-minute wait for a query and the confusion of three conflicting metrics. Discovery is not a survey; it's watching real work get done and finding the friction.

Governing the platform without killing adoption

The subtle failure mode for a product-minded CDO is the opposite of the infrastructure trap: over-optimizing for adoption and satisfaction while eroding governance. A platform that everyone loves because it lets them do anything is a compliance incident waiting to happen.

The resolution is to make the governed path the easy path. Governance should be embedded in the product experience, not bolted on as a gate. Concretely:

• Make the compliant option the default option. If the fastest way to get a certified metric is through the semantic layer, people use the semantic layer, and inherit its lineage and access controls automatically. Friction directs behavior more reliably than policy.
• Certify assets visibly. A "gold-certified" badge on a dataset, with a named owner and a published SLA, does more for trust and governed adoption than a governance memo. It also lets you distinguish sanctioned assets from the experimental sprawl in your usage telemetry.
• Use the same telemetry for governance and product. The event stream that shows you adoption also shows you access patterns, who is touching sensitive data, which uncertified assets are gaining unauthorized traction. Product observability and governance observability are the same instrument.

The judgment call for the CDO is calibrating the trade-off per segment. Data scientists need a permissive sandbox; business power users need guardrails so tight they can't accidentally publish a wrong number to the CEO. One-size governance either strangles the builders or endangers the consumers. Segment your governance the way you segment your product.

Key Takeaways

1. Reorganize the roadmap by user job, not by component. Every technical initiative must ladder up to a named job for a named internal segment; if it doesn't, it's cost, not investment. Hire a platform PM, its absence is the surest sign you're running infrastructure, not a product.

2. Replace output metrics with a product scorecard. Report adoption, retention, time-to-value, and trust, segmented by user type, to your leadership peers. Keep uptime and throughput as internal engineering health metrics, not value metrics.

3. Instrument the platform's own usage as a first-class requirement. You cannot manage adoption you don't measure; a per-event telemetry stream powers cohort retention, time-to-value, and early churn detection, and doubles as your governance observability.

4. Count the shadow pipelines and reconciliation spreadsheets. They are the most honest measure of platform trust. Killing them, by publishing and honoring dataset SLAs, is a concrete, defensible ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.Voir la définition complète → story.

5. Make the governed path the easy path, and segment governance by user. Embed compliance in the default product experience, give builders a permissive sandbox and consumers tight guardrails, and use one telemetry stream for both product and governance decisions.