“`html
Privacy-First Product Development in 2025: A Minnesota PM’s Post-Cookie Playbook
Two years ago, I could write about the “coming” end of third-party cookies as though it were some distant future we needed to prepare for. Today, standing in early 2025, I’m writing from a very different vantage point: the post-cookie world is here, it’s messy, and it’s fundamentally reshaping how we think about product development.
At Veeam, we build data management and backup solutions for enterprise customers who handle some of the world’s most sensitive information. This puts us at the absolute center of the privacy conversation—not as a marketing angle, but as an operational reality. Our customers don’t just care about privacy compliance; their business continuity and regulatory survival depends on it.
Minnesota’s pragmatic approach to technology—we tend to focus on what works rather than what sounds good—has shaped how I think about privacy in product development. This isn’t philosophy. It’s engineering discipline applied to the most critical business function of 2025: responsible data handling in an AI-driven product landscape.
Let me walk you through what’s actually changed, why it matters for product managers building data products, and the specific framework I use to bake privacy into our solutions from day one.
The Cookie Apocalypse Was Just Act One
When I started working in tech, third-party cookies felt like invisible infrastructure—present everywhere, questioned by almost nobody outside of privacy circles. The narrative was always: “We need this data to understand user behavior, optimize experiences, and frankly, make money on advertising.”
That era is definitively over.
Google’s final phase-out of third-party cookies in Chrome happened at the start of 2024. Safari and Firefox had already abandoned them. The advertising industry spent $50+ million trying to build cookie replacements. Most of those efforts are either dead or living in zombie states, stripped of real utility.
But here’s the thing: if you work in enterprise software—especially data products—you’re realizing the cookie death is almost irrelevant to your business. What matters far more is that the cookie deprecation was a visible symptom of a much larger tectonic shift: the world has decided that collecting data about human beings without explicit consent and genuine purpose is not acceptable.
For consumer products, this created chaos. For enterprise products, it’s clarified everything.
Our Veeam customers—IT directors, CISOs, enterprise architects—never cared about third-party cookies. They care about what data their solutions collect about their organizations, how that data is secured, how long it’s kept, and what it’s used for. These aren’t paranoid questions. They’re baseline requirements written into procurement standards, security policies, and regulatory frameworks.
The real revolution isn’t the death of cookies. It’s the death of data exhaust as a business model. And that changes everything about how we build products.
Enter the AI Complication: Why Privacy Just Got Harder and More Important
If the post-cookie world seemed manageable—just collect less data, be transparent about what you do collect—AI fundamentally complicated the privacy equation.
Here’s the uncomfortable truth: large language models and modern AI systems are essentially data laundering operations. You feed them massive amounts of training data, they extract statistical patterns, and then those patterns are encoded into model weights. The original data is (theoretically) no longer there. But the information has been transformed and distributed in ways that are extremely difficult to track, audit, or control.
This creates a novel problem for product managers: you can’t simply say “we respect user privacy” if your product is powered by AI trained on aggregated customer data, unless you’ve made very specific architectural choices about how that training happens.
At Veeam, this hits particularly hard. Our customers trust us with their backup data—the complete snapshot of their digital infrastructure. That data is obviously sensitive. But it’s also incredibly valuable for training better backup prediction models, anomaly detection systems, and recovery optimization algorithms.
The question becomes: how do we build AI-powered features that genuinely improve our products while maintaining the trust our customers have placed in us?
The answer isn’t “don’t use AI.” That would be ignoring the real improvements these technologies can deliver. The answer is: be ruthlessly specific about what data you use, why you’re using it, who has access to it, and what guarantees you provide about its confidentiality and eventual deletion.
Minnesota’s pragmatic culture approaches this with skepticism toward anything that sounds like it “just is the way things work now.” We ask: what problem are we actually solving? What’s the minimum data required to solve it? Who needs to know about it? What could go wrong?
These are engineer questions, not compliance questions. That’s the distinction I want to emphasize.
What Enterprise Customers Actually Demand in 2025
Let me cut through the noise about what “privacy means” in enterprise software by describing what our customers actually ask for, in order of frequency:
1. Transparent data classification and handling
Our customers want to know: what data does your product collect? Where does it go? How is it processed? They want this documented clearly, and they want the ability to audit it. This isn’t about hiding anything—it’s about giving them the information they need to meet their own compliance obligations.
We provide detailed data flow diagrams, metadata inventories, and audit logs. Not because it’s mandated by GDPR or HIPAA (though those exist), but because our customers need this to answer their own leadership teams and auditors.
2. Data residency and sovereignty guarantees
A customer in Germany needs data to stay in Germany. A healthcare organization needs data to remain within HIPAA-compliant infrastructure. A government contractor can’t have their data processed by servers in certain jurisdictions.
This isn’t abstract. This is “your product will be rejected in procurement if it doesn’t solve this.” We’ve had to architect our cloud infrastructure to support customer data remaining in specific regions, encrypted in ways we cannot decrypt, processed only by systems the customer controls.
3. Minimal data collection by default
Our products are enterprise software running inside customer infrastructure. They could collect enormous amounts of telemetry about customer systems. Instead, we collect only what we genuinely need to provide the service. Customers can enable extended monitoring for performance troubleshooting, but it’s opt-in and logged.
This is the opposite of the consumer software model where data collection is maximized and privacy is optional. Here, privacy is default and justification is required for any additional collection.
4. Clear AI/ML boundaries
This is new and critical: customers want to know exactly which features use machine learning, what data those models are trained on, and how that training happens. Are they trained on aggregated data across customers? Only on the customer’s own data? Never transmitted to external systems?
The answer varies by feature. Some of our backup prediction models benefit from being trained on patterns across thousands of customer deployments (anonymized, aggregated, with explicit consent). Other features—like anomaly detection on security events—should only learn from individual customer data.
Our customers want us to be specific about this. Not for compliance theater, but because it directly affects how they can use our products.
5. Deletion and portability guarantees
If a customer wants to delete their data, or migrate to a competitor, we need to make that actually possible. Not in theory. Not “we’ll get back to you in 90 days.” We need systems that are engineered from the start to support data deletion and export as genuine features, not regulatory nightmares.
This is surprisingly uncommon in enterprise software, which often treats customer data like it owns it. We engineer to the opposite assumption: the data is the customer’s. We’re stewards of it while they’re paying us. The moment they want out, we need to be able to return it or destroy it cleanly.
The Privacy-First Design Framework: How We Build This In
Knowing what customers demand is one thing. Building products that actually deliver it requires a different approach to product development than what I was taught ten years ago.
Here’s the framework we use at Veeam. This isn’t theoretical—it’s what we actually do in PRDs, architecture reviews, and development sprints:
Phase 1: Privacy Impact Assessment Before Any Code
Before we scope a feature, we fill out a Privacy Impact Assessment (PIA). This isn’t a compliance checkbox. It’s a design document where we force ourselves to think through what we’re building.
The template includes:
- What data will this feature collect or process? Be specific. Don’t say “system performance data.” Say “CPU utilization %, memory free %, disk I/O latency p95.”
- Why is each data point necessary? This is where you find out you don’t actually need that field. We’ve killed ideas at this stage because the data collection wasn’t justified by the benefit.
- How long will data be retained? Establish retention policies before building storage infrastructure. It’s much easier to delete data that was never created.
- Who can access this data? Define this clearly. Is it visible to Veeam support? Veeam engineers? The customer’s admin? Only logged events, no raw data?
- How will customers control this? What granularity of control do they have? Can they disable collection? Can they delete retroactively? Can they export it?
- If we use this for AI/ML, what are the parameters? What data goes into models? Is it aggregated or per-customer? Is training local or on Veeam infrastructure? Can customers opt out of contributing to shared models?
This document gets reviewed by product, engineering, legal, and security. It usually takes 2-3 rounds to get right. But doing this up front prevents building something that violates our own principles and then having to rearchitect it later.
Phase 2: Privacy by Design in Architecture
Once we’ve defined what data we need, we design the systems that handle it with privacy as a first-class concern, not an afterthought.
This means:
Data minimization at the architecture level: If we need to analyze backup success rates, we don’t need to store full job logs. We need aggregated statistics: count of successful backups, count of failures, timestamp ranges. We design the schema to only capture what’s necessary. This isn’t about database efficiency; it’s about engineering a system that can’t leak detailed logs because they don’t exist.
Encryption as default: Data in transit and at rest are encrypted by default. Not as an option. Not for “sensitive” data. Everything. This eliminates entire categories of vulnerabilities and demonstrates to customers that we take security seriously at a structural level.
Separation of concerns: The system that processes customer data is architecturally separate from the system that might use aggregated data for product improvements. This creates natural boundaries. You can’t accidentally leak customer data to shared models if those systems don’t have access to it.
Audit logging as a feature: Everything that happens to customer data is logged—who accessed it, what was read, what was modified, what was deleted. These logs are immutable and retained far longer than the underlying data. This gives customers transparency and gives us forensic capability if something goes wrong.
Phase 3: Customer Control as a Feature
Privacy isn’t something we do for customers. It’s something we build for them to control.
This means the product itself exposes privacy controls:
- Granular data collection toggles. Want backup performance data collected? Yes. Want detailed event logs? Only on-demand. Want automatic telemetry sent to Veeam? Off by default.
- Data retention policies customers can configure. We have sensible defaults, but customers with compliance requirements can set their own retention periods.
- Export and deletion tools built into the product. Not “contact support,” but actual buttons that let customers export their data or delete historical records.
- Clear opt-in for any data usage beyond the core product function. If we want to use anonymized backup patterns to improve our algorithms, we ask. If they say no, that feature doesn’t participate in collective learning.
Building these controls into the product itself—not as add-on modules—tells customers that privacy is integral, not optional.
Phase 4: Testing Privacy Like You Test Performance
Privacy isn’t a quality attribute that you verify once and forget about. It’s tested continuously.
Our QA includes:
- Data leakage tests: Can we extract customer data from logs, error messages, or debug information? We specifically test for this.
- Audit log completeness: Does every data access create an audit entry? We verify this with synthetic workloads.
- Encryption verification: Is data actually encrypted when it should be? We periodically verify encryption keys are being used correctly.
- Retention enforcement: When a customer sets a deletion policy, does data actually get deleted? We test this with synthetic data and verify deletion happens on schedule.
- Access control verification: Can customers who shouldn’t see data not see it? We test cross-customer isolation and role-based access controls continuously.
This isn’t separate from quality assurance. It’s part of the definition of done.
The Minnesota Approach: Pragmatism Over Performative Privacy
Minnesota’s tech culture—visible in companies like Target, Best Buy, and now Veeam—has a particular flavor: we’re skeptical of marketing stories and focused on building things that actually work and that we can defend to our customers and the public.
This shapes how I think about privacy:
Privacy is not a selling point. It’s a requirement. We don’t market on privacy. We deliver on it as baseline. Our customers assume we respect privacy; the question is whether we’ve done the engineering work to prove it.
Compliance is a floor, not a ceiling. GDPR, HIPAA, SOC2—these set minimum standards. But our customers often exceed these requirements. We build to what our most demanding customers need, which means we exceed compliance across the board.
Trust is earned through transparency, not assurance language. Saying “we take security seriously” is worthless. Showing customers exactly what data you collect, how you collect it, how you protect it, and how they control it—that builds trust. We publish detailed documentation on all of this, not because compliance requires it, but because customers need it to make procurement decisions.
The default state should be “as little as possible.” If we’re uncertain whether we need data, we don’t collect it. We can always add collection later if there’s genuine need. We can’t un-collect data that was never necessary.
The AI-Specific Challenges: Where Privacy Gets Genuinely Hard
I want to spend some time here on the thing that keeps me up at night: how to build AI products responsibly when the entire field is built on the idea of maximizing data ingestion.
The tension is real: machine learning improves dramatically with more data. Backup prediction is better when trained on patterns from thousands of deployments. Anomaly detection works better with more context. All of this is true. But it has to be balanced against customer privacy expectations and regulatory realities.
Here’s how we’re approaching it:
Federated learning where possible: Instead of sending customer data to Veeam infrastructure for training, we’re experimenting with models that learn from customer-side data and then share only the learned patterns (model updates) back to a central system. This is technically harder. It’s also much more respectful of customer data sovereignty.
Differential privacy in aggregation: When we do aggregate data across customers for collective learning, we apply differential privacy techniques—mathematical approaches to adding noise to data in ways that make it impossible to reverse-engineer individual customer information, even if someone hacked the aggregated dataset.
Explicit consent for model training: If we’re going to use customer data to train shared models, we ask. Not in a terms-of-service way. Actual feature toggles where customers opt into contributing anonymized, aggregated data to specific models.
