Building a privacy platform instead of another privacy feature

One of the biggest lessons from my recent product work is that a new requirement doesn't always need a new solution.

Privacy Preferences is a good example.

The bank already had a Privacy Preferences experience, but it was based on a standalone legacy form accessed through the Privacy page. The experience was different from the modern digital patterns being used elsewhere, and the customer journey wasn't as clear as it could be.

At the same time, Email Marketing Preferences existed separately under Profile & Settings and continued to evolve independently. We weren't trying to merge the two products.

The opportunity was to modernize the Privacy Preferences experience and move it onto the enterprise Micro Frontend architecture already established across Online Banking, Mobile Web, and Native Mobile.

That changed how I thought about the work.

The requirement wasn't simply:

"Build an FCRA preference screen."

It became:

"How do we make this capability fit into a platform that can support FCRA today and future privacy requirements without rebuilding the experience each time?"

That meant thinking beyond the UI.

We had to consider the MFE architecture, APIs, downstream integrations, data storage, authentication, business rules, QA, release dependencies, and the teams that would own those components after launch.

The same thinking applies to Email Marketing Preferences. Brands are continuously onboarded or deprecated, themes change, and opt-in and opt-out journeys evolve. Treating each brand request as a one-off implementation would create unnecessary duplication.

A platform approach gives us reusable patterns for these changes.

There are three questions I now ask when deciding whether something should be treated as a feature or a platform capability:

• Will we need this again?
• What changes when the next regulatory or business requirement arrives?
• Can we create a reusable capability instead of solving the same problem again?

That doesn't mean every problem needs to become a platform.

Platform thinking has a cost too. Additional abstraction can slow delivery if there isn't a real reuse case.

The product decision is therefore not "platform versus feature."

It is deciding when investing in the platform will make the next five changes easier than making the current change as a one-off.