Author: Jason Miles

If you’re on an operations or business team and someone just asked you to “own the data product,” you might be thinking: I don’t code—how could I own it?
Good news: owning a data product is a leadership role, not a coding job.

Think of it like being a product owner in other fields:

• Software product manager: sets the roadmap and defines success while engineers write the code.
• Consumer hardware lead: chooses features and quality thresholds while factories assemble devices.
• Marketing campaign owner: decides audience and outcomes while creative and media teams execute.
• Publishing editor: shapes the issue and deadlines while writers and designers produce.
• Construction owner’s rep: defines scope, budget, and acceptance criteria while contractors build.

In every case, the owner doesn’t run the machinery. They own the outcomes: what gets built, why it matters, who it serves, how “good” it needs to be, and how it changes over time. Data product ownership is the same. You set direction, make trade‑offs, and keep everyone informed. Others handle the pipes, queries, and platforms.

What’s different with data is simply the medium: it behaves like a service. Your “product” is a reliable, permission‑aware way to answer recurring questions. Your promise is about freshness, accuracy, and clarity, not lines of code.

Data platforms usually fail in two predictable ways: they drown in shadow copies nobody owns, or they calcify around a single ingestion pattern that does not fit every source. Microsoft Fabric offers a broader palette. You can read data where it already lives, replicate operational systems into a governed lake, and run high‑throughput batch and low‑latency streams without wiring a dozen services together. The work isn’t picking a tool; it’s choosing deliberately so your estate stays fast, testable, and governable as it grows.

This guide treats Zero Unmanaged Copies (ZUC) as a strong—but not exclusive—operating model. ZUC constrains where bytes land and keeps lineage simple: if data persists, it is inside OneLake under policy and catalog; if it does not need to persist, you read it in place. Many teams will also continue to run a traditional lakehouse with raw/bronze landings, curated silver, and published gold. Fabric supports both because everything converges on OneLake (the boundary) and Delta (the table format). We evaluate each option with consistent criteria: performance (bulk throughput and end‑to‑end latency), operational surface (how much you must run and monitor), governance posture (where data persists and how it is secured), team ergonomics (SQL, Spark, or low‑code), and table health (file sizes, partitioning, Delta logs).

For clarity: zero‑copy means reading in place. Managed copy means materializing inside OneLake with lineage. Unmanaged copy is anything persisted outside governance—temporary blobs, stray CSV drops, buckets with unclear ownership. ZUC eliminates that last category; a traditional lakehouse allows governed staging and raw landings as part of the pipeline.

Every organization has white space: important work that lives between teams and across systems, is almost always evidence‑bearing, and—despite its value—rarely reaches the top of the backlog. In software engineering, that’s the unglamorous backbone of quality: keeping documentation and runbooks current, sustaining full test coverage (beyond unit tests), and validating against standards (security, accessibility, SBOM/licensing). In manufacturing, it shows up as traceability and shipment evidence (SPC, PPAP/FAI, calibration certificates) and keeping control plans/PFMEA in sync with engineering changes. In education, it appears as standards alignment of curricula, accessibility/privacy checks across LMS content, and intervention follow‑through after assessments. These jobs cross many systems, require judgment, must leave an audit trail, and are perpetually “important but not urgent”—perfect territory for delegating to digital workers: software teammates that live in the seams, move work to done, and attach the receipts as they go.

“To effectively delegate these tasks they need knowledge, access, and some intangibles.” (Nathan Lasnoski)

A digital worker earns real delegation only when three things are in place: knowledge (trusted sources, rubrics, examples), access (the right tools and permissions under guardrails), and the intangibles of a good teammate (when to act vs. ask, tone, and norms). With that foundation, a coaching worker can also serve as worker‑as‑judge—applying explicit rubrics, pulling evidence across systems, returning a pass/fail or “needs work” with a brief rationale, and providing an easy appeal to a human. The payoff is fast, fair, actionable feedback that feels like a senior reviewer on call 24/7—something frontline teams welcome.

If you’ve skimmed headlines, it’s easy to conclude that data mesh is a Silicon Valley thing—something streaming apps and fintechs use to wrangle petabytes. That mental model sells a lot of tools, but it misses the point. Data mesh is first an operating model—a way to organize people, responsibilities, and guardrails so data can be produced and used where the knowledge lives. That matters just as much (and often more) in organizations whose mission is not building software: manufacturers, hospitals, universities, public-sector agencies, retailers, utilities, and nonprofits.

Continuing our hypothetical study of how high school coaches (specifically football coaches) can implement data technologies and use them to help save time and focus on coaching and developing players and students.

You’ve got the Saturday grading workflow dialed in (position tabs, per‑player per‑play grades, simple notes, and a Monday “Team Sheet”). Now let’s zoom out: how do you turn that weekly rhythm into cumulative insight—tracking every kid’s growth across the season (and across seasons), spotting unit‑level trends, and making November decisions with March‑level clarity? The short answer: pair your staff’s grading discipline with a data engineer who stands up a light, durable analytics stack in Microsoft Fabric and Power BI. Fabric gives you one place to land, shape, secure, and publish your data—end‑to‑end—without stitching together a dozen services.

Below is a coach‑first, high‑level guide to “what we’ll do” and “who does what,” building directly on the grading app/process described in the post you just read.

The Coach–Data Engineer Playbook

Coaches (what you already do):

• Grade each snap with the simple rubric (+ / 0 / – / ME) and one‑phrase notes where they matter.
• Tag a handful of teaching reps.
• Keep the grading standards consistent so the data stays trustworthy.

Data Engineer (what they add):

• Wire up a single, durable data lake and semantic model so Saturday’s grades automatically become Monday’s dashboards—and season trends.
• Ensure privacy (players only see their data), reliability (no “did it refresh?” panic), and speed (reports open instantly).
• Set and enforce definitions so “Grade %,” “ME rate,” and “Explosive” mean the same thing in October as they did in Week 1.

The season‑long architecture (in plain language)

Think of this as three layers—Operate → Store/Shape → Show—with governance wrapped around everything.

1) Operate (your grading apps)

• You’re already capturing Players, Games, Plays, On‑Field, Grades in Power Platform (Dataverse). That’s your operational system.

Data engineer’s move: Turn on Link to Microsoft Fabric from Dataverse so your tables are automatically and efficiently mirrored into OneLake (Fabric’s single, organization‑wide data lake) as Delta tables—made for analytics. No export jobs to babysit.

Why this matters: OneLake gives you “one copy” of your data that every analytics engine in Fabric and Power BI can use—faster, cheaper, and simpler than duplicating data all over the place.

2) Store & Shape (the lakehouse)

Inside Fabric, the engineer sets up a Lakehouse with a simple “medallion” flow:

• Bronze: the raw mirrored tables from Dataverse (unchanged).
• Silver: cleaned, typed, coach‑friendly columns (e.g., standardized grade codes, consistent position groups).
• Gold: a star schema built for analysis:
  • Dimensions: DimPlayer, DimGame, DimOpponent, DimPositionGroup, DimUnit.
  • Facts: FactPlayerPlayGrade (one row per player‑play), FactPlayerGame (rollups), and optional FactEvent(penalties, explosives, pressures).

Need to bring in other data (attendance, GPS, a scoreboard CSV, or cloud video marks)? Use OneLake Shortcuts to reference those files in‑place—no brittle copy jobs; still one lake, one security model.

Prefer low‑code data prep? Dataflows Gen2 (Power Query Online) can visually clean and land tables straight into the Lakehouse, which is often perfect for staff‑maintained lookups (e.g., rubric weights, drill catalogs).

3) Show (Power BI with near‑instant reports)

From the Gold tables, the engineer builds a Power BI semantic model using Direct Lake so reports feel “import‑fast” without nightly data copies. Direct Lake reads Delta tables in OneLake straight into memory—so coaches can slice film‑grade data interactively without waiting.

Security: Players get a personal view; coaches see their room; coordinators and the HC see the whole team. That’s row‑level security (RLS) in Power BI: filters that restrict rows per role. (Note: RLS limits apply to Viewer‑level users; workspace Admin/Member roles bypass RLS by design—your engineer will use the right roles.)

Optional live signals: If you want live stats from the sideline tablet or wearables, Fabric’s Real‑Time Intelligence can ingest streams, transform them, and light up a simple “game day board” alongside your scouting notes—then archive those events for later analysis.

Governance everywhere: Fabric’s Purview hub and Domains organize data (e.g., an Athletics domain), apply sensitivity labels, and give leadership a clear view of what’s protected and endorsed. That keeps you aligned with district expectations for student data.

What coaches get (every week and across the season)

• Team Sheet (Monday): The single pager you already use—now backed by a model you can trust for trends and drill‑down.
• Player Cards (private): Grade %, ME rate, touches/targets/havoc plays, consistency streaks, and a short list of “next reps.”
• Room Dashboards:
  • OL: pressure/sack accountability, technique flags (“late hands,” “fit late”), situational splits (3rd & medium, low red).
  • Skill: route depth consistency, decision quality, yards after contact trends.
  • Defense/ST: leverage/fit outcomes, impact plays, coverage/tackle reliability.
• Season Trends: Week‑over‑week ME rate, “win” rate by concept, opponent‑adjusted grades, class‑year cohorts, and offseason baselines that inform summer focus.

All of this stays coach‑friendly because the data engineer bakes the definitions into the semantic model once—and everyone uses the same truth thereafter.

How the partnership runs (no drama)

Your job stays the same: grade the film with the simple rubric and leave one‑phrase notes where they change practice. The apps you’re already using remain the front door.

The engineer’s steady cadence:

1. Keep the Dataverse → OneLake link healthy (automatic mirroring).
2. Maintain Silver/Gold transforms (Dataflows Gen2 or notebooks) and the star schema.
3. Evolve the Power BI model (measures you care about, like “Drive‑ending MEs”).
4. Govern access (RLS for players, workspace roles for staff, sensitivity labels in Purview).
5. Publish a Power BI app to staff and players so nobody is hunting for links.

A note on licensing (so you can plan)

• Authors/publishers (the engineer and any coach who edits reports) need Power BI Pro.
• Report consumers (read‑only viewers) typically also need Pro, unless your district licenses a Fabric capacity at F64 or higher—in which case Free viewers can access content in workspaces on that capacity. Your engineer can help align the workspace to whatever you have.

Starter scope (what we actually build first)

1. Link Dataverse to Fabric (players, games, plays, on‑field, grades mirror into OneLake).
2. Gold model with just the essentials: FactPlayerPlayGrade, DimPlayer, DimGame, DimOpponent, DimPositionGroup.
3. Power BI semantic model in Direct Lake + three reports:
   • Team Sheet (game rollups).
   • Room View (filters + technique flags).
   • Private Player Card (RLS).
4. OneLake Shortcut to any external CSV (e.g., practice attendance) to enrich Player Cards without copying data.
5. Purview basics: sensitivity labels + endorsement so admins know what’s trusted.

From there, add opponent scouting cuts, practice‑plan exports, or real‑time sideline boards as you see value.

Guardrails for student data (plain talk)

• Least privilege: players = Viewer + RLS; position coaches see only their room; coordinators/HC get team‑wide. (Admins and Members in a workspace bypass RLS—so keep those roles tight.)
• Governance: put your items in an Athletics domain; apply sensitivity labels; monitor with Purview hub. Your district data lead will appreciate the visibility.

Why Fabric + Power BI works for high school programs

• One system of record from your grading apps to your dashboards—no wobbly exports.
• Fast, coach‑friendly reports via Direct Lake (open, filter, decide).
• Zero‑copy expansion with OneLake Shortcuts when you want to fold in other files/sources.
• Built‑in governance your district already understands (Purview + domains, RLS).

If you want this as an “Athletics Analytics” blueprint, the ingredients above are all you need. Your staff keeps doing what works on Saturday; the data engineer quietly turns that into compounding advantage by Monday—and keeps the season’s trail of evidence organized for next year’s goals.

I often hear that DirectLake “removes the ability to define tables” and “doesn’t work like traditional Power BI or Tableau.” At a glance, the workflow is different—deliberately so—because Fabric is a data platform, not a visualization tool. In the old days we’d push transformations past gold and into the semantic layer because that was the only practical place left. That was necessary; it was never ideal. By definition, gold is supposed to be ready to consume.

DirectLake mode in MS Fabric’s Power BI gives you (almost) everything Power BI gave you in Desktop. The one big thing you don’t do anymore is DAX calculated columns/tables—and that’s a feature, not a bug. Nuance for accuracy: In DirectLake, calculated columns and calculated tables that reference DirectLake tables aren’t supported; however, some calculated tables that don’t reference DirectLake tables (e.g., documentation helpers) and calculation groups/what‑if parameters are allowed. DirectLake reads Delta in OneLake, the model still uses VertiPaq, and data prep moves into the platform (Dataflows Gen2, Lakehouse/Warehouse SQL, notebooks).

Turning small, theory‑driven tests into compounding results

Improvement science is simple and powerful: start with a clear theory of change, run a safe test, study the data, then adopt, adapt, or abandon. The challenge isn’t running one test—it’s running hundreds of small tests, keeping their intent and results visible, and scaling what works without losing the thread.

Microsoft Fabric is a strong fit because it lets you keep the learning system (ideas, theories, PDSA cycles, decisions) right next to the evidence system (measures and run charts). Below is a high‑level pattern that puts improvement science at the center, with examples from manufacturing and oil & gas.

I’ll be following FabConEurope closely (Sept 15–18, Austria Center Vienna) to see how the newest Microsoft Fabric capabilities land in real‑world talks and demos. Here’s the short list I’m watching—centered on near‑zero copy patterns, Materialized Lake Views, Shortcut Transformations, and Real‑Time Intelligence.