The Hard Way to Build BI: What I'd Do Differently With Strategy Mosaic

Quick Answer

• Building BI without governed business logic means rebuilding from scratch every time. Without a semantic layer, teams spend months hand-classifying data and recreating metrics inside every individual report.

• A semantic layer separates business logic from the data pipeline, enabling faster delivery. Strategy Mosaic lets teams define metrics once and reuse them everywhere, reducing time-to-insight and accelerating adoption.

• Parallel development of semantic layer and ETL shortens the road to trusted analytics. Business logic can shape the pipeline, and the pipeline refines the logic — both evolve together rather than sequentially.

I started working at a Fortune 500 beverage company in 2016, in Finance. Less than a year in, I found myself in an elevator with the VP of Digital Transformation. I'd just heard him give a talk on the digital revolution. He told us that his own area would eventually get diluted. That digital work wouldn't stay centralized and would spread into every team, everywhere.

He was right. But getting there took a long road of adoption, one team, one habit, one dashboard at a time. Six months later, he asked me to join his team as a Data Science Manager.

The project was a D2C platform for convenience stores in more than 14 countries. And it was, in every sense, uncharted territory.

This was the first time the company had access to consumer-level data. No distributor in between. No wholesaler smoothing out the signal. Just raw, messy, individual purchase behavior, where my job was to build analytics and BI that people could trust and act on.

Calling it "data science" felt generous. The first job was really archaeology. We were digging through a database that had been designed for market speed, not business understanding.

• No brand clustering: Our own soda, a partner energy drink, another partner's snack brand, and two different partner personal-care brands, all living in the same undifferentiated chaos.

• No naming conventions: Literally 15 different ways to write our own flagship soda brand's name

• No analytics categories: No snacks, home care, beverages, alcoholic/non-alcoholic, or ready-to-drink labels to simplify data management.

Moreover, the "fact tables" I found weren't built for analysis. Geolocation had no city mapping, timestamps were in the wrong format for delivery, and data fields were either empty or unfiltered.

This meant I had no metrics at all:

• No way to identify which products were even ours.

• No way to understand brand incidence.

• No way to read GMV, orders, or ticket size by city.

What I really wanted, even if I didn't have the word for it yet, was a Semantic Layer.

One day, while I was painstakingly sifting through this chaos, my VP asked me for a favor: Could I put together an Excel file to understand how our flagship flavor line was performing on the platform?

I said, "Sure, give me 10 minutes." (By midnight, I had managed to build a Power BI report, after classifying 2,000 SKUs by hand, just to see how it stacked up against total GMV.)

I walked back to my desk the next morning and asked myself a question that's stuck with me ever since:

What if, instead of building individual dashboards, I could show how everything was purchased?

Alongside our snacks, a partner's product, and everything else in one basket.

And then I drilled deeper. That "basket analysis" would have let us:

• Build consistent product names, tags, clusters, and categories for clarity.

• Define product combinations that were both accurate and genuinely profitable.

• Compare flagship product performance against joint purchase behavior.

Here's what actually happened.

I built 18 reports for 14 country managers. All I had was access to CSVs and a handful of platforms like Apps Flyer to track in-app behavior. Eventually, I managed to get a team assigned to build something resembling a semantic layer on Azure Analysis Services, but not quite.

That took an entire year of work.

I had to bend every existing tool I had into replicating what I truly needed: consistent, governed business logic, built directly on top of the data stack.

Looking back, having Strategy Mosaic would have helped us separate two critical elements:

1. The semantic layer: Metrics, attributes, relationships, and governed business logic.

2. The data pipeline: The ETL work needed to connect backend databases with the tools the business used to surface insights.

That separation would have changed how the project was built. Instead of waiting for ETL work to finish before defining the business logic, we could have built the semantic layer in parallel.

That would have reduced development time and shortened time-to-insight. Adoption would likely have moved faster too, because business users would have seen trusted, usable metrics earlier. From day one, the CEO and Board would have had a clearer view of the project's value and momentum.

Mosaic would have helped turn that chaotic data into reusable business logic by standardizing product definitions, aligning categories, and creating governed metrics that everyone could trust. Instead of rebuilding that logic manually inside a Power BI report, we could have defined it once and reused it wherever insights were needed.

With Mosaic, designing the semantic layer helps define what ETL work is actually needed. Business logic shapes the pipeline, and the pipeline helps refine the business logic. Instead of moving in a straight line, both evolve together.

The result is two outcomes built together: a properly scoped data pipeline and a governed semantic layer that the business can trust.