Product strategy · Regulatory change · Cross-functional planning
The rule changed.
The product had to change with it.
A global payments platform had twelve months to respond to a new identity requirement that would change onboarding, support, operations, and the evidence the company had to produce.
I mapped what the requirement meant for the product and shaped the overall plan across the teams that had to make it real.
Company details intentionally anonymized.
The problem
A new rule was about to ripple through the whole product.
The change touched onboarding, engineering, support, exception handling, customer communication, and evidence. Each team held a different piece, and the deadline forced those pieces to become one plan.
How do you turn a regulatory requirement into a product plan the organization can actually execute?
The insight
The control was mandatory.
The friction wasn’t.
Once the requirement was clear, the remaining choices were product choices. Customer complexity varied, so the journey did not need to be identical for everyone.
Consistency belongs in the requirement, not necessarily in the experience.
Work from the agreed rule. Then design the response around the people and teams who have to live with it.
The plan
Four moves. One coordinated plan.
Interpret
Get clear on what the requirement actually changes.
Define who and what is in scope, what evidence must exist, and separate the fixed requirement from the product choices around it.
Separate requirements from assumptions.
Design
Turn the requirement into a product decision.
Map how the change touches onboarding, customer help, exceptions, and internal workflows. Keep the requirement consistent; let the amount of help change with customer complexity.
One requirement. Different paths.
Prove
Test the whole response, not just the flow.
Test early enough to find where the product, support model, or operating process breaks before the deadline does it for you.
The deadline is not the test date.
Assure
Make sure the organization can stand behind the change.
Check the product, customer experience, operation, and evidence together: can people complete it, can teams support it, and can the company show the requirement was met.
Three things still have to hold at launch.
- The requirementIn-scope population, complete evidence.
- The experienceCompletion, abandonment, time to activate.
- The operationReview load, exception handling, service levels.
Who had to move together
The change crossed more than one team.
Product and engineering changed the experience. Operations handled exceptions. Commercial teams managed affected customers. Risk, compliance, and audit had requirements and evidence to account for. The plan had to connect all of it without letting one team’s view become the whole answer.
Why twelve months mattered
The deadline was fixed, so discovery and testing had to happen early enough to fail safely, with the end of the program protected for remediation and assurance.
The four things the plan had to hold at once
- The requirementWhat has to become true
- The productWhere the experience has to change
- The teamsWho has to make it real
- The evidenceHow the company proves it worked
The decision logic, stripped of client-specific detail.
What the strategy was designed to achieve
- Meets the requirement.
- Fits the product.
- Can be operated and proved.
Reach the deadline with an approach that met the requirement, fit the product, could be supported by the teams around it, and produced evidence the company could stand behind.
What stays private
The decision logic is public. The client-specific details are not.
- The verification experience and customer segmentation criteria
- Exception and failure-handling logic
- Operational thresholds and enforcement decisions
- Success metrics, timeline, and governance mechanics
- Vendor and technical capability assessments