Prompt and scope
Your B2B SaaS stores customer content, audit logs, usage events, attachments, and backups. Enterprise buyers ask for a setting that controls how long each class of data remains available. Decide whether to offer configurable retention windows, then define the promise, limits, deletion behavior, legal holds, pricing, and validation.
This is a product decision, not a single delete query. The European Data Protection Board frames storage limitation around purpose and a deletion procedure, while SaaS practice must account for replicas, exports, backups, support access, and restore behavior. The useful answer connects customer control to a deletion guarantee the company can actually prove.
What the interviewer is testing
- Whether you identify the customer job before proposing a privacy setting.
- Whether you separate data classes, purpose, retention period, and end-of-life action.
- Whether you distinguish a UI preference from a cross-system deletion contract.
- Whether you protect legal holds, investigations, backups, and recovery requirements.
- Whether you price the operational burden without selling a misleading compliance claim.
- Whether you define measurable launch gates and a rollback path.
Public PM interview guidance treats prioritization as a trade-off between reach, impact, confidence, effort, and risk. Retention adds a hard boundary: a shorter window is useful only when deletion is complete, auditable, and compatible with obligations.
Clarifying questions
- Which customer problem matters: compliance evidence, breach reduction, storage cost, or data minimization? The priority changes the feature and metric.
- Which data classes are configurable? Customer content, audit logs, backups, and billing records cannot share one rule.
- Is the promise deletion, anonymization, archival, or removal from the primary UI? Each needs different proof.
- What exceptions exist for legal holds, abuse investigations, chargebacks, and disaster recovery?
- Who can change the setting, when does it take effect, and what happens to data already past the new deadline?
Thirty-second answer
I would offer configurable windows only for data classes whose lifecycle we can inventory, enforce, and verify. I would start with a small set of tiers, purpose-based defaults, a minimum safe floor, a preview of affected data, and explicit legal-hold behavior. The contract would state which replicas, exports, backups, and support tools are included. I would pilot with a few enterprise tenants, measure deletion completion and support load, and delay broad packaging until audit evidence is reproducible.
Step-by-step solution
Step 1: Tie the request to a customer job
Interview security, compliance, and administrators separately. A compliance team may need evidence of deletion; a security team may want to reduce breach blast radius; an administrator may want to control storage cost. If the job is only cost, archival may beat deletion. If the job is regulatory minimization, a longer archive may fail the requirement.
Step 2: Build a data-class matrix
List purpose, owner, storage locations, retention floor, end-of-life action, and evidence for each class. Keep customer content, raw events, attachments, audit logs, backups, and billing records separate. A setting that says “delete after 30 days” is incomplete until it states what happens to search indexes, replicas, exports, and snapshots.
Step 3: Choose a safe product shape
Start with a small menu rather than arbitrary dates. Offer a default, a few approved windows, and a warning when a choice conflicts with a documented obligation. Show a dry-run count and the first deletion date. Do not let a tenant shorten audit-log retention below the security baseline or silently change a contract already in force.
Step 4: Define deletion and exceptions
Specify whether deletion is hard delete, cryptographic erasure, anonymization, or archival. Define queueing, retries, idempotency, and a completion record. Legal holds must freeze eligible records and expose who applied the hold. Backups need a documented expiry path; “deleted from the database” is not proof that every copy is gone.
Step 5: Price the operating burden
Estimate control-plane work, storage-class transitions, deletion jobs, audit evidence, support, restore tests, and per-tenant policy evaluation. Charge for high-cost classes only when the customer value is clear. Avoid pricing that turns a legal obligation into an optional upsell; separate the baseline protection from premium flexibility.
Step 6: Make the promise observable
Track policy version, records eligible, records deleted, records blocked by hold, retry age, and residual copies discovered by audits. Give administrators a status view with next action and evidence download. Product metrics should include adoption, deletion completion, policy violations, support contacts, and failed restores—not just settings saved.
Step 7: Pilot with stop conditions
Shadow the policy first, then run a small cohort with reversible windows. Stop if deletion cannot be reproduced, a restore resurrects expired data, a legal hold is bypassed, or support cannot explain the result. Also stop if customers select shorter windows but continue exporting unmanaged copies, because the product promise would be misleading.
Step 8: Govern changes after launch
Version the policy schema and customer-facing terms. Require product, security, legal, and engineering approval for new data classes or shorter floors. Re-test after storage, vendor, backup, or analytics changes. If evidence is incomplete, narrow the scope instead of claiming universal deletion.
Model answer
I would support configurable retention only where the lifecycle is mapped end to end. I would separate content, logs, events, attachments, backups, and billing records; provide approved windows and a safe floor; preview the impact; and make legal holds explicit. The promise would name the systems covered, the deletion or anonymization action, backup expiry, and the evidence customers receive. I would pilot with enterprise administrators, measure completion and residual-copy audits, and keep the feature out of broad packaging until restores, holds, and support explanations pass. If the customer need is storage cost rather than minimization, I would offer archival instead of pretending archival is deletion.
Common mistakes
- Treating one retention number as a complete policy → copies and data classes differ → publish a scoped matrix.
- Adding arbitrary date inputs → operations and evidence become unbounded → offer approved windows.
- Calling primary-database deletion “complete” → backups and exports remain → define the full deletion boundary.
- Ignoring legal holds → investigations lose records → freeze eligible data and audit the hold.
- Measuring settings saved → no proof of customer outcome → measure completion, residual copies, and support load.
- Selling flexibility as compliance → customers infer a legal guarantee → separate product behavior from legal advice.
Follow-up questions
A customer wants a one-day window for all data. What do you do?
Separate classes and obligations first. Offer the shortest approved window for eligible content, keep security and billing floors, and explain which data cannot follow that choice.
How do you prove deletion from backups?
Document backup retention and expiry, tag policy versions, run sampled restore tests, and verify that expired records are absent or cryptographically unreadable after the stated boundary.
What if a legal hold arrives after deletion starts?
Use a hold check before each destructive step, make the job idempotent, and record the race. Data already irreversibly deleted cannot be reconstructed; the product must expose that boundary to legal and support teams.
Should shorter retention cost less?
Only when it lowers a real operating cost. Baseline protection remains part of the service; premium pricing can cover policy flexibility, evidence, or high-cost data classes without implying that compliance is paywalled.
How do you handle customer exports?
State that exports are customer-controlled copies, show export events where possible, and avoid claiming that deleting the SaaS copy deletes files downloaded by the customer.
What launch metric would make you stop?
Stop on any unreconciled residual copy, bypassed hold, failed restore test, or support explanation that conflicts with the contract. High adoption cannot compensate for an unverifiable promise.
When would you choose archival instead?
Choose archival when the customer needs cheaper access or historical analysis rather than erasure. Label its access, security, and eventual deletion behavior separately from active retention.