Personally identifiable information: names, phones, addresses, emails. Collecting it brings legal and ethical duties.
Why it exists
Some of the data a product holds is personal, names, phones, addresses, and mishandling it harms real people and breaks the law. Treating it like any other field invites leaks and legal trouble. PII exists as a category you handle with extra care, so sensitive personal data is stored, accessed, and shared under stricter rules than ordinary data.
How it actually works
The moment you store real people's details, law and ethics constrain you: what you may collect, how long you keep it, who can see it, and what happens when a user asks to be deleted.
Good practice is to collect the minimum needed, restrict access, encrypt it, and be able to delete it on request. Every extra field of personal data is extra risk if you are breached.
A senior PM walks you through it
A junior PM, stuck
Legal asked me for a list of every personal field TiffinBox stores and how each one is used, and I froze. I know we have a customers table but I have never looked at it column by column, and I cannot tell which columns even count as personal or who is allowed to read them. I need to produce a real inventory, not a hand-wave.
What legal is asking for is a data inventory, and the customers table is exactly where you build it: go column by column and answer three things for each, is it personal, who can read it, and what feature actually uses it. That third question is the one that finds the liability nobody meant to create. Below is the table's shape with those tags filled in, plus what each column is really used for, so you can hand legal the list and spot the field you should not be keeping.
The customers table as a data inventory
customers table columns, tagged by sensitivity and access
1 column | type | personal | who can read
2 id | id | no | all services
3 name | text | PII | support, admin
4 phone | text | PII | support, admin, delivery
5 address | text | PII | delivery, admin
6 tier | text | no | all services
7 date_of_birth | date | PII | (nothing reads it)
what each personal column is actually used for
8 name -> order confirmation, support lookup
9 phone -> delivery SMS, support lookup
10 address -> delivery routing
11 date_of_birth -> nothing
Click a step to see the lines it points at.
Mistakes I've seen
Treating every column the same. id and tier are ordinary; name, phone, and address carry legal duties. Handling personal fields with the same casualness as a category label is how leaks and violations start.
Collecting fields "just in case." date_of_birth is PII that no feature reads, so it is pure liability with no upside; every unused personal field is risk you are carrying for nothing.
Not knowing who can read each field. If you cannot say which roles see phone or address, you cannot answer legal and you cannot enforce least privilege; the who-can-read column is part of the inventory, not an afterthought.
Being unable to produce the inventory on request. Legal, partners, and regulators will ask for the list of personal fields and their uses; if it does not exist, you are already behind. Keep it current.
Forgetting deletion and export are features. "Delete my data" and "export my data" have to be buildable against this table; designing for them after launch is far harder than planning the fields with them in mind.
Send legal: "Personal fields on customers are name, phone, and address, each used by a specific feature and readable only by the roles that need it. date_of_birth is personal but unused, so I am proposing we stop collecting it and drop the column." You walked a table column by column into a real data inventory, which is the skill.
Where a PM meets this
"Do we actually need to collect this?" is a question PMs should ask constantly; unused personal data is pure liability.
Deletion and export requests ("right to be forgotten") are features you may have to build; designing for them early is far easier.
Hear it in a meeting
"Let's not collect date of birth, we don't use it and it's just more PII to protect."