Data model
A data model describes the information a product stores and how it fits together: the entities (users, accounts, orders), their attributes, and the relationships between them, such as one account having many users. In a relational database it becomes tables linked by primary and foreign keys, often drawn as an entity-relationship diagram. Every feature, report and integration builds on this structure.
Why it matters for a PM
Many product limitations come from the data model: a user who cannot belong to two workspaces, a price that cannot vary by country, a history that was never kept. These choices are cheap to change on paper and expensive once data exists. A PM who can read the model spots missing cases while the feature is still being designed.
Example
A scheduling app stores one time zone per user. When the team adds shared calendars for distributed teams, events display at the wrong hour for half the participants. A PM reading the model earlier would have asked where the time zone of an event lives.
Key points
- Cardinality, how many records of one entity can link to another, encodes business rules.
- Each entity has a lifecycle: creation, changes, archiving, deletion.
- Relational databases suit strongly linked data; document databases favor flexible, self-contained records.
- Personal data in the model carries obligations: minimization, retention periods, deletion.
Common mistakes
- Designing the screens first and discovering the data constraints during development.
- Overwriting values that the business later needs as history.
- Letting an AI agent generate tables without reviewing keys, constraints and access rules.
Go further with Module
The courses and lessons that cover this concept: