DPDP for Product Managers: Writing Privacy Requirements Into Your PRD

Treating privacy as a compliance sign-off that happens after a feature is built almost guarantees expensive rework — a field that needs deletion logic, a notice that needs updating, a new vendor that needs a contract. Writing privacy requirements directly into the PRD, alongside functional and technical requirements, catches these decisions while they're still cheap to change.

A useful discipline: for any feature that touches personal data, add a short 'data and privacy' section to the PRD template itself, answering four questions before engineering starts — what personal data does this touch, what's the lawful ground, who else gets access to it, and how does it get deleted.

Be specific rather than generic. 'User data' is not an answer — name the actual fields: phone number, location history, device identifiers, uploaded documents. New data types that didn't exist in your inventory before (a new form field, a new sensor reading, a new third-party data pull) need to be added to the Personal Data Inventory as part of shipping the feature, not months later.

Pay particular attention to fields collected 'just in case' for future use — a phone number field added for a feature that hasn't shipped yet is still personal data sitting in production, and needs the same lawful basis and notice as data actively used today.

Decide explicitly whether the feature relies on consent (Section 6) or a legitimate use (Section 7), and design the UX accordingly. A feature that needs consent should have a real, unbundled consent moment — not a checkbox buried inside a broader terms-of-service acceptance.

If the feature changes what's collected or how it's used, the existing notice and privacy policy need updating before launch, not after a user complains that the app is doing something they weren't told about. Add 'update privacy notice' as a literal checklist item tied to the release, with an owner.

For any feature aimed at or reasonably likely to be used by minors, flag it early — verifiable parental consent mechanisms and a ban on behavioural ads/tracking for children under Section 9 usually require design changes, not just a policy update.

If the feature sends data to a new third-party API or SDK, that's a new Data Processor relationship, and Section 8(2) means a contract needs to exist before the integration goes live in production — not after a security review flags it post-launch.

Define the retention period and deletion mechanism for any new data store or table as part of the design, including what happens to it if the user deletes their account or withdraws consent. 'We'll figure out deletion later' is how most companies end up with data they can no longer explain.

Run new features through the Obligation Finder to confirm which sections actually apply, and log new data flows in the Data Flow Mapper as part of your release checklist rather than as a retroactive audit exercise.