March 10, 2026/767 words/4 min read

Data Models as a Product Person

The shape of your data is the shape of your product.

I finished Kleppmann's Designing Data-Intensive Applications two weeks ago, and it has the irritating habit of changing how I see my actual job. Someone cleaned a window you didn't realize was dirty, and now you keep noticing things through it that were always there.

A conversation at work got me thinking about it again. We were speccing out a new feature, and the engineering lead started sketching entities, relationships and cardinality on a whiteboard. I was following along, asking questions, and at some point I suggested we flatten a relationship he'd drawn as a separate table. He looked at me like I'd spoken in a language he didn't expect me to know. Fair enough, PMs don't usually bother with schema design. But they really should.

I had a strong opinion on it, and it came from somewhere specific. I'd seen a nearly identical pattern at my previous job, where a normalized structure created a reporting nightmare six months down the line. Nobody flagged it during the spec because the model was academically "correct", with no duplication and everything done by the book. Then a team needed a dashboard that required joining five tables to answer one simple question, and "correct" stopped looking so correct.

I keep bumping into the same gap. Engineers think about data models in terms of integrity and consistency, which matters. PMs think about data in terms of what shows up on a screen and whether the numbers make sense to a human. They're looking at different layers of the same thing, and the problems show up in the space between them. When a PM doesn't understand why a query is slow, why a "simple" feature request needs a migration, or why two numbers that should match don't, the answer is almost always sitting in the data model. Nobody ever told them to look there.

I didn't learn any of this formally. I learned it the way I learn most things, by being confused and frustrated enough times that the pattern became impossible to ignore. I'd sit in meetings where an engineer would say "that's a many-to-many," everyone would nod, and I'd think, okay, I know what that means in theory, and the guy sounds smart enough, but what does it mean for the thing we're actually building? For the person who'll open a screen and expect their data organized in a way that makes sense to them?

Kleppmann's book gave me vocabulary for something I'd been feeling for a while. The chapter on data models lays out the trade-offs between relational, document, and graph models in a way that finally made me understand why some product decisions feel heavier than they should. When you pick a data model, you're constraining how the product can think about itself. A relational model says, "Everything connects through defined relationships." A document model says, "Each thing is self-contained." Those are product philosophies wearing technical clothes, and they shape what's easy to build later and what becomes a six-month project nobody wants to touch.

In practice, it mostly means paying attention. Since finishing the book, I've been asking engineers to walk me through the data model early, before we get deep into wireframes or user stories. I'd be bad at designing the schema myself, but understanding the shape of the data changes how I think about the feature. If "user preferences" live in a separate table with a one-to-many relationship to the user, I understand why personalisation features carry a cost that isn't obvious from the spec. If order history is denormalized for performance, I understand why certain edits are harder than they look. The model explains the friction, and once you can see the friction, you can make much better trade-offs about where to spend engineering time.

There's a more personal reason I care about this too. I've always liked understanding the structure underneath the surface. It's the same instinct that pulled me into design thinking a couple of years ago. Back then I realized I was looking at half the picture by ignoring the experience layer. Now I think I was missing a different half by ignoring the data layer. The product sits between the two, and when either one is out of step with the other, the whole thing feels off in ways that are hard to diagnose from the outside.

Two weeks after finishing the book, I'm still catching myself looking for the data model whenever a product decision feels oddly expensive or awkward. Some of this might look naive to me in six months. For now, I'm asking to see the model earlier.