Your data model is a product decision

There is a category of product decision that never appears in a product review: the shape of the data. It gets made early, by whoever writes the first migration, usually under deadline, and it outlives every roadmap that follows. Years later, “can we build this feature?” is answered not by ambition but by a table someone designed in an afternoon.

I build my platforms with a fleet of AI agents, and the experience sharpened this belief: code is cheap to change now; the data model still isn’t. Here are the schema decisions I treat as product strategy.

Status fields vs. history tables

The single most common trap: a status column that overwrites itself. It answers “where is this invoice now?” and silently destroys the answer to every better question — how long do documents sit in review, where do they get stuck, what did the workflow look like before the dispute?

If a state change matters to the business, it deserves an event row: what changed, when, and triggered by whom or what. That is not an engineering nicety. It is the difference between a product that can offer timelines, SLAs, audit exports, and process analytics — and one that can offer a badge. In fintech, where trust is the activation metric, the audit trail is the feature.

Identity decisions are forever

What is a customer — a person, a company, an email address? Can one person belong to two companies? Every product that guesses wrong on this spends years paying for it, because identity leaks into every table as a foreign key. Multi-tenancy is the same decision wearing armor: scoping data per-tenant from day one is boring; retrofitting it is a rewrite.

The uncomfortable part: these decisions arrive earliest, when you know the least. Which is exactly why they deserve an hour of product thinking instead of defaulting to whatever the framework scaffolds.

Idempotency is a user experience

Whether an operation can safely run twice sounds like a backend concern — until a user double-clicks “issue invoice”, a webhook retries, or an import runs on Monday and again on Tuesday. Systems designed for safe re-runs produce products that feel calm. Systems that aren’t produce duplicate invoices and support tickets that all start with “something weird happened”.

You cannot bolt this on with UI. It lives in unique constraints and carefully chosen natural keys — in the schema.

The PM habit: read the migrations

I don’t think product managers need to design databases. I think they need to read them. A schema is the most honest spec in the company: it cannot be aspirational, it cannot be vague, and it reflects what the product actually believes about the world. When the schema and the strategy disagree, the schema wins — silently, one impossible feature at a time.

So put the data model in the product review. Ask what questions the current shape can never answer, which state changes leave no trace, what happens when this runs twice. The engineers will have opinions; the good ones will be relieved someone asked.

The features you’ll want in two years are constrained by columns being written this sprint. That makes the schema too important to be nobody’s product decision.