There is a moment in every data platform project where the PM hands the requirements doc to engineering and says, "You figure out the schema." I have done it. I have watched other PMs do it. And I have seen the consequences play out the same way every time.
Six months later, the data is there. The dashboards are built. But nobody can answer the question the business actually needs answered, because the schema does not have the right relationships. And changing the schema now would require rebuilding half the pipeline.
The schema is the product. Not the dashboard. Not the API. The schema.
Why PMs Abdicate Schema Decisions
The honest answer is that schema design feels like an engineering problem. It involves tables and foreign keys and normalization rules. It is technical. It has syntax. PMs are trained to own the "what" and let engineering own the "how."
But schema design is not a "how" decision. It is a "what" decision. It is a decision about what entities matter in your domain, what relationships between those entities matter, and what attributes of those entities you need to capture. Those are business decisions. They require domain knowledge, not database expertise.
When you let engineering own the schema, you get a schema that is technically correct and domain-incomplete. It stores what the engineers understood about the business, which is usually less than what the business actually needs.
The PromoStandards Example
When we started designing the data lake at iPromoteu, the first instinct was to mirror the PromoStandards API structure. Eight standards, eight tables, done.
That would have been a disaster.
The PromoStandards standards are designed for point-to-point transaction exchange. They are optimized for "give me the price for this product from this supplier." They are not designed for "give me all the products from all suppliers that can be decorated with pad printing, delivered in under ten business days, at a price point under fifteen dollars, with a minimum order quantity under fifty units."
That second query: the one that a distributor actually needs to answer for a customer: requires a schema that models the relationships between products, decoration methods, lead times, pricing tiers, and minimums. The PromoStandards structure does not encode those relationships. It assumes you will figure them out at query time.
A data lake schema built on the PromoStandards structure would have been fast to build and useless to query.
What Good Schema Design Looks Like
Good schema design starts with use cases, not entities. Before you define a single table, you write down the ten most important questions the business needs to answer. Then you work backward to the schema that makes those questions answerable.
For the promotional products data lake, the questions looked like this: Which suppliers can fulfill a rush order for a specific product category? Which decoration methods are available for a given product, and what are the setup charges? Which suppliers have had quality issues in the last ninety days? Which products are trending in a specific industry vertical?
Each of those questions implies relationships. Rush orders imply a relationship between suppliers and lead time tiers. Decoration methods imply a relationship between products and capabilities. Quality issues imply a relationship between suppliers and order history. Trending products imply a relationship between products and industry verticals.
Once you have the questions, the schema writes itself. Not the syntax: that is engineering's job. But the entities, the relationships, and the attributes. That is the PM's job.
The Governance Implication
Here is the other thing about schemas: they are hard to change. Once data is flowing in and dashboards are built on top, modifying the schema is a major project. Which means the schema decisions you make early become constraints you live with for years.
This is why schema design needs PM ownership from day one. Not because PMs are better at database design than engineers. But because PMs are the ones who understand the business well enough to anticipate the questions the business will need to answer: not just today, but in two years.
The schema is the product. Treat it like one.
