Shared components
A common set of frontend building blocks replaced repeated work on similar designs and interactions.
Internal platforms & experimentation
Reusable platforms for global delivery
Replacing repeated market-site builds with shared components, services, and integrated content and experimentation tools.
Launch cycles reduced from approximately 9 months
The brief
Make the next market launch an extension of a shared platform, instead of another site built from the ground up.
My role
I introduced the reusable component and service approach, led product development and global rollout of the internal platform, and worked with Product and Engineering VPs to drive adoption across five organizations and twelve teams.
A shared delivery effort
Product and Engineering teams developed the components, services, and automation. Stakeholders and partners across the company gained the ability to handle more work themselves through the shared capabilities.
01 / The starting point
Similar markets. Repeated builds.
When I joined American Express, launching a new market meant building its site from the ground up. The design and functionality were often similar to existing markets, with relatively small differences in market-specific logic. Yet teams kept repeating the development effort.
This made each launch a substantial delivery project. The opportunity was to separate what markets shared from what actually needed to vary, so teams could reuse the common foundation and focus development on the differences.
The product question
How could we give markets the flexibility they needed without asking teams to rebuild the same capabilities for every launch?
02 / The platform decision
Build the common foundation once.
I introduced Atomic Design for the frontend and extended the same modular thinking to the backend. The approach paired a reusable component library with microservices that handled common capabilities and market-specific logic.
We developed a new set of components and services, then introduced automation to accelerate delivery. Reuse had to cover both the visible experience and the services behind it: a shared interface alone would still leave teams rebuilding the underlying behavior.
Common services
Reusable backend capabilities supported the functionality that markets had in common.
Market-specific logic
The service approach accommodated local differences while keeping the shared foundation reusable.
This is a conceptual summary of the approach, rather than a reproduction of internal architecture.
03 / Content & experimentation
Connect the tools to the building blocks.
We also replaced the CMS and the external experimentation solution, Optimizely. The reason was greater control over the capabilities we needed and the ability to integrate them fully with our component libraries and module services.
I helped build and launch the in-house A/B and multivariate testing platform. Bringing content, experimentation, and reusable delivery capabilities together allowed teams to work across those solutions more directly and increase delivery speed.
The choice to build internally also meant taking ownership of the tools. The product direction was therefore broader than replacing a vendor: it was to make content and testing part of the same reusable delivery system.
04 / Adoption & organizational change
Faster delivery changed the work itself.
Adoption required convincing VPs of Product and Engineering. Engineering leaders were concerned about the impact on their teams and existing work. Product teams gained speed, but also gave up some direct control as stakeholders and partners could handle tasks themselves.
That shift reduced the need for much of the work teams had previously been doing. We worked on defining new development priorities that would make better use of Product and Engineering capacity and support modernization across the company.
COVID-era layoffs and a stronger need for operational optimization increased the urgency of adoption. The leadership work was to address the consequences for teams alongside the platform's delivery benefits.
05 / Reported outcomes
A more repeatable path to launch.
Approximate market-launch timelines reported in my résumé.
12 teams
Adoption of the shared internal platform.
Reported operational efficiency improvement.
Measured annual savings from staffing costs and software licenses replaced through the in-house platform work.
The platform capabilities supported products serving more than 50 million customers across consumer, small business, and corporate businesses. That describes customer reach, rather than the number of internal platform users.
The annual savings figure was measured using staffing costs and the costs of replaced licensed software. It reflects the wider platform effort. The launch-time comparison and operational efficiency figure are separate résumé-reported measures; one is not calculated from the other.