Data Models as a Product Person

March 10, 2026 · 819 words · 4 min read

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

I'm about halfway through Kleppmann's Designing Data-Intensive Applications and it's doing that really annoying thing where a book changes how you see your actual job. Someone cleaned a window you didn't realize was dirty, and now you keep noticing things through it that were always there.

The thing that got me thinking was a conversation at work a few weeks ago. We were speccing out a new feature and the engineering lead started sketching the data model on a whiteboard. Entities, relationships, cardinality. I was following along, asking questions, and at some point I suggested we flatten a relationship that 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. PMs don't usually have opinions about schema design, apparently.

But I did have an opinion, 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 later. Nobody thought about it during the spec because the model was "correct" in the academic sense. It was clean, it avoided duplication, it followed the rules. And then the business needed a dashboard that required joining five tables to answer a simple question, and suddenly "correct" felt like a different word entirely.

That's the gap I keep bumping into. Engineers think about data models in terms of integrity, normalization, consistency. All valid, all important! PMs think about data in terms of what shows up on a screen and whether the numbers make sense to a human. Neither perspective is wrong, but 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, or why a "simple" feature request requires 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, dazed, and frustrated enough times that the pattern became impossible to ignore. Sitting in meetings where an engineer would say "that's a many-to-many" and everyone would nod and I'd think, okay, I know what that means in theory and it sounds smart enough, but what does it mean for the thing we're building? What does it mean for the person who'll eventually open a screen and expect to see their data organized in a way that makes sense to them?

Kleppmann's book helped me put vocabulary around 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.

The practical version of this is not as philosophical, it feels more about paying attention. I've started asking engineers to walk me through the data model early, before we get deep into UI wireframes or user stories. I'd obviously be bad at designing the schema myself (genuinely, that's not false modesty), but understanding the shape of the data changes how I think about the feature. If I know that "user preferences" live in a separate table with a one-to-many relationship to the user, I understand why personalisation features have a cost that isn't obvious from the product spec. If I know that 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 better trade-offs about where to spend engineering time.

There's also a less practical and more personal reason I care about this. I've always liked understanding the structure underneath the surface, it's the same instinct that pulled me toward digging 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 both, and if either one is misaligned with the other, the whole thing feels off in ways that are hard to diagnose from the outside.

I'm still early in the book and I'm sure my thinking on this will keep shifting. It already has, honestly, just in the few weeks since I started reading it. Some of these ideas might look naive to me in six months. Writing them down now is how I'll notice!