An identity product spanning a 650,000-employee ecosystem is a different problem than a feature operating in one channel.
The success criteria are different. The stakeholders you need aligned, the release controls you need in place, and the operational infrastructure you need to support are all different. The gap between "it works" and "it works at scale" is larger than most teams think.
I learned this firsthand owning the Remote Identity Verification product at Amazon — spanning a 650,000-employee ecosystem across the IT portal, chatbot, and case-management channels. Here's what the experience taught me about operating an internal product at enterprise scale.
The Problem
Identity verification at that scale is a security-critical flow. Get it wrong and you've either locked out employees who need support or you've created a pathway for unauthorized access to internal systems handling sensitive data.
The product spanned three employee-support channels — an IT portal, a chatbot, and case management. That meant readiness criteria, release sequencing, and measurement had to remain coherent across separate systems and teams.
Reducing verification time across three channels within a 650,000-employee ecosystem was not a sprint-sized task. It required treating the experience as one product while managing each channel's technical and operational dependencies.
The Approach
I owned the full product lifecycle — discovery, roadmap, cross-functional delivery, and launch — which meant I was accountable for both the business outcome and the technical feasibility. That dual accountability shaped every decision.
The work started with clear readiness criteria and an operating view that treated portal, chatbot, and case management as one customer journey. The goal was to make release decisions against shared outcomes rather than optimize each channel in isolation.
The roadmap paired cross-channel release sequencing with operational scorecards. Separately, I identified a workflow gap affecting 1,500 IT engineers and designed automation and process frameworks that translated that field pain into scalable platform improvements supporting $1B in assets.
The cross-functional alignment was as important as the technical delivery. Engineering, operations, and support teams needed one view of readiness, one release sequence, and one measurement system. Without that shared operating model, a change that worked in one channel could simply move friction into another.
The Results
- 25% reduction in identity verification time
- Coordinated readiness and release sequencing across the IT portal, chatbot, and case management
- Automated workflows built for 1,500 IT engineers
- Platform improvements supporting $1B in hardware and software assets
The Real Lesson
The technical implementation was only part of the complexity. The rest was product management: defining the right problem, aligning teams, sequencing releases, managing operational risk, and building the measurement infrastructure to know whether the experience was improving.
This is the pattern I see consistently underestimated in enterprise platform work. Teams focus on implementation because it is concrete. The ambiguous, relationship-intensive work of getting a large organization aligned and moving in the same direction gets scoped as "change management" and treated as secondary.
At 650,000 employees, there is no secondary. Everything is the critical path. The PM who treats the organizational challenge as secondary to the technical challenge ships a technically excellent product that nobody uses. The PM who treats them as equally important ships something that actually changes how the organization operates.
That's the job.
