I didn't set out to become a person who sits at the intersection of AI strategy, enterprise cloud, and product leadership. I set out to be a good infrastructure engineer. What happened between those two things — twelve years, six roles across five companies, a few hard pivots, and one very deliberate bet on where technology was heading — is what I want to write about.
Not because the story is unusual. It's not. But because when I look back at it now, I can see a thread that I couldn't see while I was living it. Each role gave me something specific that the next role required. The path looks intentional in hindsight. At the time, most of it felt like improvisation.
American Express: Learning the Language of the Business (2013–2018)
I spent nearly five years as a Senior Infrastructure Engineer at American Express, inside the Digital Workplace organization. I built things — the BYOD mobile device management platform, custom Salesforce applications, Tableau tooling deployed across the company. The BYOD platform alone delivered $2.5M in annual cost savings and became the foundation of how AmEx managed employee mobility for years after I moved on.
But the thing I actually learned at AmEx in those five years wasn't technical. It was this: the people who got things done weren't always the best engineers. They were the people who understood why the business cared about what they were building.
I watched colleagues ship technically excellent work that never got adopted because nobody had done the work of connecting it to a business outcome. I watched other initiatives — less technically elegant — get championed all the way to executive approval because whoever owned them could articulate a clear ROI and a clear ask. I started paying attention to that pattern. I started learning how to speak both languages simultaneously: infrastructure architecture and business case.
That skill — the ability to translate between a technical reality and a business outcome — is the single most durable thing I've built in my career. It started at AmEx, in those years of watching what moved and what didn't.
The Pivot: From Building Infrastructure to Owning Products (2018)
In 2018 I made a move that confused some people I respected: I stayed at American Express but changed disciplines entirely. I moved from Senior Infrastructure Engineer to Senior Product Manager, taking ownership of the digital payment features on the J.D. Power top-ranked mobile app.
Why? Because I kept running into a wall. As an infrastructure engineer, I could build the right system for a clearly defined problem. But I had no authority over the problem definition itself. Someone else decided what we were building and why. I wanted that seat.
The transition was harder than I expected. Technical depth, it turned out, was table stakes but not sufficient. Product management required a completely different form of discipline: holding ambiguity, working across functions where I had influence but not authority, making decisions before I had all the information I wanted, and being accountable to outcomes I didn't fully control. The engineering half of my brain kept wanting to reduce problems to their components and solve them cleanly. Product management doesn't work that way.
What the infrastructure years gave me that made the transition viable was systems thinking. I already understood how complex systems broke, where the real constraints lived versus the perceived constraints, and how architectural decisions made upstream created consequences downstream. That translated directly into product work — I could look at a roadmap and see the technical debt buried inside the feature requests. I could talk to engineers in their language, read the codebase when I needed to understand something, and never show up to a sprint review unable to speak to what we'd actually built.
The results came: 3x revenue growth and a 54% satisfaction improvement on those payment workflows within twelve months. The J.D. Power ranking held. And I learned what I needed to learn about product ownership at scale before moving on.
Fidelity and Wells Fargo: Where Analytics Became a Weapon (2021–2022)
I spent about six months at Fidelity Investments as Director of Product Management, leading an agile squad building HSA payment solutions. Brief tenure, but formative in a specific way: it was the first place I was fully responsible for building the measurement infrastructure alongside the product. At AmEx I inherited a data environment. At Fidelity I built it. SQL, Tableau, hypothesis-driven development — validating assumptions with data before committing to a build rather than after. That discipline paid off fast: 10% improvement in satisfaction, 5% faster time-to-market. Small numbers that pointed at a larger methodology shift.
At Wells Fargo, leading product for their mobile banking platform for millions of customers, that methodology was the entire game. The mobile app had been stagnant. Customer feedback was arriving through every channel and going nowhere useful. The first thing I did was build a feedback loop that actually changed prioritization decisions — not aspirationally, but mechanically. We scored incoming signals against business impact and engineering cost. We forced stack ranking. We stopped debating opinion and started debating data.
Ten-point NPS improvement in six months. The number matters, but what I actually carried forward was the operating model: you can't improve what you can't measure, and the measurement system is part of the product system, not a separate concern.
Amazon: Learning to Think at Scale (2022–2024)
Joining Amazon as a Senior Product Manager — Tech was the most disorienting professional experience of my career, and also the most developmental. The scale is genuinely different. Not bigger-but-similar. Actually different in kind.
I owned the Remote Identity Verification platform for 650,000+ corporate employees across Amazon's global operations. The surface area of the problem — one product, millions of people, dozens of internal systems depending on it, zero tolerance for failure in security-critical flows — required a level of precision in requirements, a level of rigor in testing, and a level of care in stakeholder communication that I hadn't operated at before.
Amazon is also where I learned what "working backwards" actually means in practice, not just as a framework to reference in interviews. The discipline of writing the press release before writing the spec — of forcing yourself to articulate the specific customer and the specific problem before you're allowed to discuss solutions — changed how I think about product development. It's uncomfortable. It forces clarity you can avoid if you allow yourself to skip it. I've applied it in every significant initiative since.
We delivered a 25% reduction in identity verification time and integrated AI/ML verification across every employee support touchpoint. What I took away was bigger than the outcome: I left Amazon knowing how to manage products at a scale where the organizational and communication challenges are as hard as the technical ones.
AWS: Where All the Threads Converged (2024–2026)
My most recent role — Senior Customer Solutions Manager at Amazon Web Services, managing a $91.7M renewal portfolio for a Fortune 20 financial services enterprise — is the one where everything I'd accumulated actually arrived at once.
The infrastructure background: I could sit in architecture reviews with the client's principal engineers and have substantive conversations about what was actually going on in their AWS environment. I'd built this stuff. I wasn't relying on a Solution Architect to translate for me.
The product background: I could look at an enterprise's AI roadmap and immediately identify which initiatives had data problems buried underneath the ambition, which organizational dependencies were going to create delivery risk, and where the definition of success was loose enough to be dangerous.
The analytics discipline: I could build the ROI model. Not commission one. Build it myself, present it to the CFO, and defend every assumption. That moved decisions that had been stalled in technical review for months.
The outcomes at AWS were the best of my career numerically: $23.5M ARR influenced, $1.4M in annualized FinOps savings delivered, a $1.7M payment modernization program delivered ahead of schedule. But the reason they happened was the full stack of accumulated capability — infrastructure literacy, product thinking, data discipline, stakeholder communication — working together in one role for the first time.
The Thread I Couldn't See Then
I didn't plan for infrastructure experience to make me a better product manager. I didn't plan for product management to make me a better customer-facing cloud advisor. I didn't plan for the analytics discipline I built at Fidelity to be the thing that unlocked a $23.5M commercial outcome at AWS years later.
But each of those things is true. The career I have now required all of the career that came before it.
If I had skipped the infrastructure years to get to product faster, I would have been a product manager who depended on engineers to translate technical reality for me. If I had skipped the financial services years to get to Amazon faster, I would have understood the platform without understanding the regulated, risk-averse, enormously complex enterprises that are its biggest customers.
What I'd tell someone earlier in their career: the things that feel like detours often aren't. The lateral move that looks like a step backward is frequently the one that gives you the capability the next level actually requires. The discipline you're building in a role that feels too narrow may be exactly what makes a much broader role possible later.
Don't optimize so hard for the destination that you skip the learning. The learning is the asset. The title is just what they call you while you're accumulating it.
