What an MS in Law taught me about data governance that no PM course ever did

The initial design collected contact information and child due date first, then asked the user which newsletters they wanted to subscribe to and provided a disclosure on data usage. That’s a technically compliant flow on paper—consent language was in place, the disclosures were attached. It’s also a flow that would routinely collect privacy-protected data from users who weren’t going to sign up for the pregnancy-date-based newsletter at all. We’d be processing and holding sensitive data we had no product use for. And that’s assuming they don’t just abandon signup altogether because of this.

That distinction—compliant versus trustworthy—is one PM training doesn’t teach you to make. Understanding privacy law enables me to be more opinionated where it counts. The right move was structural: ask which newsletters the user wanted first, and only collect due date when the user’s selection actually required it. Same data schema; protected relationship with the user; and decreased business costs.

Our onsite marketing vendor had never served a multi-page modal flow before, so we partnered with them to build the design pattern. That same multi-page pattern later powered Follow This Topic and the inline and toaster marketing units that became the platform’s most flexible surfaces (more on this next week). The Parents compliance work funded infrastructure the rest of the network would inherit.

And that includes users and staff.

Logical argument that the flow needed reordering wasn’t enough (and rarely is in PM); I had to prove it was the right decision before the team would refactor a design they’d already approved. I leveraged pre-existing relationships with the privacy and legal teams to co-prioritize an unmoderated user research study on prototypes. I drove through delegation, and the platform designer I worked with built the prototypes and ran the study. We partnered on synthesis and had regular check-ins throughout the process with the Health team’s designers and the VP overseeing both the privacy and Health product teams. The study timed users through both flow orderings and captured friction qualitatively through participant video self-recording.

The newsletter-first ordering won decisively. We presented the read-out to the same group, and the Health team’s designers carried the findings to Editorial because they had the longer-standing relationship there—political mechanics matter as much as the research. Editorial signed off. Legal then co-authored the new help-text language inside the UI alongside the existing privacy policy disclosures, because regulatory copy that lives in a footer reads differently from the same disclosure inline at the moment of collection.

That’s the data-minimization argument in operational terms. Collecting less isn’t just a smaller exposure to a future enforcement action. It’s a more trustworthy experience for consumers, and a cheaper system to maintain across the inevitable changes in what users expect from us about their data.

We also interpreted the regulations to apply based on where the user was signing up from, not just whether they were a resident of that state. The design started to inflate around handling four cases (resident-and-in-state, resident-out-of-state, non-resident-in-state, non-resident-out-of-state). I pushed back on architecting data collection against this complexity: we had no product use for that signal beyond the moment-of-consent decision, so it belonged in the presentation layer (the help text and disclosure), not the data layer. All we needed to capture was which state we collected consent for, if any, and as of what date.

That call is the kind of thing that’s easy to over-engineer if you don’t have the legal vocabulary to know exactly what a regulation is prescribing. We mapped data with infrastructure that anticipated future states adding diverging language—the language could fan out cleanly while the schema stayed normalized.

We also re-shipped the newsletter program itself. Pregnancy is a uniquely sensitive experience—the program had to acknowledge potential loss and route accordingly, confirm birthdate post-due-date, and offer clean opt-outs at every life-stage transition. Those aren’t compliance features. They’re features that make the program a tool a user can trust to handle hard moments. This was an important user experience to deliver on from the beginning because the newsletter sought to expand into post-pregnancy content delivery.

I’m not a privacy lawyer—I’d rather have a real one in the room. What the MS in Law gave me is the ability to be useful in the same room with legal and other stakeholders, playing facilitator, translator, and negotiator all at the same time. To spot when a design that passed legal still has a trust problem in the user flow. To know when an architectural change can solve a compliance question more durably than a consent disclosure on its own. To recognize that data subjects need management tools for the data we hold about them—which, on this project, became another argument for the user-registration and onboarding roadmap I was stewarding underneath the network’s growth programs.

That, more than anything, is the case for PMs going through this kind of training. Not to replace specialist counsel. To minimize the risk to users whose trust the system depends on and the business which depends on its relationships with its users.