How should product managers build for DPDP?
Product managers: DPDP constrains what data your product can collect and how.
Purpose minimisation in feature design
Each feature should ask: what personal data does it actually need? A recommendation engine might need usage history but not email. A customer-support ticket might need contact info but not purchase history. The temptation to 'just collect it, maybe we'll use it later' is not compliant. Collect only what the feature requires.
Consent and data-collection flows
Before a user's personal data enters your product, get clear consent. For a single-purpose feature (account creation = email + password), one consent is enough. For a multi-purpose product, segment — social sign-up, analytics, marketing — and let users opt in per purpose.
Lifecycle and deletion workflows
Every data field should have a planned deletion date or trigger. Deletion is not a legal afterthought — it is part of the feature. A user who deletes an account expects their data gone. Building deletion into the schema from day one is easier than retrofitting.
Frequently asked questions
Can I collect extra data 'just in case'?
Not under DPDP. Collection must be justified by a stated purpose. Using 'just in case' data later without consent is a violation.
How do I explain DPDP constraints to feature teams?
Frame it as a product requirement, like security or performance. 'Users must consent to data use' is now as important as 'the page must load in 2 seconds'.
What happens if my feature relies on prohibited practices (e.g., profiling minors)?
The Board can block the feature or order you to redesign it. Catching these in design review (before build) is much cheaper than post-launch remediation.
Design your product for DPDP
Run the DPDP for Product guide to audit data collection, consent flows and deletion workflows.
DPDP for Product Managers