Amex VP of Product says AI must be integrated gradually into product organizations — a single skipped layer will cost you

Abishek (Abhi) Gandotra started his career as an engineer, but moved to product — bringing his technical know-how with him. He's currently VP of Product at American Express. And he's also the author of The Sovereign Agent.

He joined us to share what he's learning as AI blurs the lines between engineering and product even more. Here's what he told us.

From engineering to product

I'm Abhi Gandotra, and I lead the Banking Platform product org at American Express. I started as an engineer, spending the first decade of my career writing code. Consequently, I've never treated technology as a black box. When something doesn't ship, I want to know why — at the layer where it breaks.

I moved into product because I cared less about building things right and more about building the right things. At Green Dot, I spent over a decade building a Banking-as-a-Service platform — we took it from an idea to over $1B in B2B revenue across 80+ enterprise partners. That taught me what I still believe: Platforms win when they make other people's hard problems easy. Now, at Amex, I'm doing that for banking and payments infrastructure, at a different scale and with the accompanying regulatory bar.

The AI moment, for me, isn't just hype. I'm shipping with these tools right now — building agents, standing up an AI upskilling program across my org, running small pods that go from idea to working software in days. My engineering instincts came all the way back around. The gap between "I have an idea" and "it's running" has never been this short. That's the part I find exciting — not the hype, the velocity.

Leading product from within the infrastructure layer

As I said, I lead the Banking Platform product organization at American Express — the digital banking and payments platform that underpins our consumer and commercial banking experiences. It's the infrastructure layer: the rails, account and money-movement capabilities, and controls supporting all customer-facing elements.

Our "users" comprise two distinct audiences: end customers who experience the product as their banking and payments, and internal product and engineering teams who build on our platform. Platform work requires serving builders and end-users simultaneously — if you only optimize for one, the other suffers.

We operate at the scale and regulatory bar expected of a hundred-plus-year-old financial institution, meaning reliability and compliance are not features, but table stakes. Our delivery model mixes in-house product and engineering with key technology partners, so I largely orchestrate — aligning internal roadmaps with external capabilities and the controls required by our risk and compliance teams.

How AI shifts prototyping from engineering to product

The biggest change I made was that I stopped treating prototyping as an engineering request and made it a product capability.

A year ago, validating a new idea meant writing a brief, adding it to a backlog, and waiting weeks for engineering capacity to build something for users or partners to evaluate. Now, I run small pods that go from concept to working software in days — using AI coding tools to stand up a functional prototype against a real SDK, not a clickable mockup. On one recent initiative, a payroll integration, a tiny team built and tested a working integration in the time it previously took to align on requirements.

This changed how we make decisions. When you can put working software in front of a partner or a stakeholder in days, the conversation stops being abstract — you're debating something real, with real edges, instead of arguing over a deck. That's killed much of the analysis-paralysis that used to eat the front end of our roadmap. And with product managers on my team scoping and standing up prototypes themselves, engineering time goes to what truly needs it.

Now, the hard part isn't building. It's judging what's worth building. Taste and prioritization are the scarce resources. That's the shift I'm most focused on as a leader.

A real-world idea-to-prototype workflow

Here's our generalized workflow from idea to working prototype, compressed from weeks into days.

1. Frame the problem: It starts human — a partner need or a gap we've spotted. I use an AI assistant as a thinking partner to pressure-test the framing: who's it for, what's the actual job to be done, and what would make it not worth building? This sharpens the question before building starts.
2. Synthesize the inputs: We point AI at the relevant material — research, support themes, competitive landscape, prior internal context — and get a synthesized view in minutes instead of days. A human reviews it to identify what the model missed or overweighted; the synthesis is a starting point, not the verdict.
3. Build a working prototype: This is the biggest shift. Instead of writing a spec and waiting for engineering capacity, a small pod uses AI coding tools to stand up functional software with a real interface — not a clickable mockup, but something that runs. Days, not weeks.
4. Put it in front of people: We present the working prototype to stakeholders or a partner early. Because it's real, the feedback is genuine — we debate behavior and edge cases, not react to a deck.
5. Decide with judgment: AI steps back here. Whether we invest further, how it fits the roadmap, and what the controls and compliance implications are — these are human calls, with clear accountability by design.

Why PM purview must change

Because of this, I've been actively redefining the scope of PM ownership, the handoff points between product and engineering, and — critically — the quality bar for PM-built artifacts going to production.

The moment a PM can ship end-to-end, you have to answer new questions the old model never forced you to ask. What is a PM now accountable for that they weren't before? Where does engineering's judgment still have to gate the work, and where does it just slow things down? What does "production-ready" mean when the person who built it isn't an engineer?

I'm focused on coherence, not faster shipping for its own sake. Giving everyone the power to build risks everyone building their own version of everything, fragmenting the organization into capable silos that don't compound. So the redesign is as much about shared foundations and a common quality standard as it is about unleashing PMs. Done right, teams move dramatically faster and build on each other rather than around each other.

Why AI should generate options while humans apply judgment

AI excels at generating options; humans must still own judgment, especially in regulated banking.

I lean on AI for:

• Discovery and synthesis: pulling signal from research, support tickets, partner feedback, and the competitive landscape far faster than a human can read it all.
• Prototyping and experimentation: standing up working software to test an idea instead of debating it.
• The first draft of almost everything: requirements, analysis, and market scans.

AI gets us to a credible starting point — something that used to take up most of our time — in minutes.

I keep it explicitly human for:

• Prioritization and the roadmap call: AI can lay out tradeoffs, but deciding what we build — and what we deliberately don't — requires judgment about strategy, risk appetite, and our customers that I'm not willing to outsource.
• Anything touching regulatory or risk decisions: In our world, "the model suggested it" is not an answer you can give a regulator.
• The hard people and stakeholder calls: By that, I mean reading the room, navigating competing priorities across partners. These are irreducibly human.

How AI brings both speed and overconfidence

Abhi's Thoughts

The lesson was that AI shrinks the cost of the first 80% so dramatically that teams underestimate the remaining 20%, which is where all the difficulty in banking lives. We now explicitly separate “looks done” from “is done,” and I’ve made it a norm that a working demo is the start of the hard conversation, not the end of it.

The clearest win is speed at the front of the lifecycle:

• Prototyping cycles that used to take weeks now take days, which means we test more ideas and kill the bad ones earlier — before they consume real engineering capacity.
• My PMs now get through research, support feedback, and competitive scans in a fraction of the time, so they walk into prioritization conversations better prepared.
• PMs who couldn't ship anything without an engineer can now stand up a working prototype themselves. That changes the energy on the team. People feel more like makers again.

But we learned the hard way that AI output is confident even when it's wrong, and that's dangerous in a regulated environment. Early on, a prototype looked polished enough that it created false confidence about how close we were to something real. The demo worked, but the hard 20% — the edge cases, the controls, the compliance logic — was completely unaddressed.

The lesson was that AI shrinks the cost of the first 80% so dramatically that teams underestimate the remaining 20%, which is where all the difficulty in banking lives. We now explicitly separate "looks done" from "is done," and I've made it a norm that a working demo is the start of the hard conversation, not the end of it.

The gap between demo and product value

There is a big gap between demo magic and durable product value. AI excels at the impressive zero-to-one moment but consistently underwhelms at the unglamorous work that drives sustained impact.

A few specifics:

• The "last mile" in regulated workflows: AI delivers a working prototype fast, but in banking, value isn't in the happy path — it's in controls, audit trails, exception handling, and reconciliation logic. AI has not meaningfully accelerated that part. I expected it to compress the entire build; it only compressed the front half. The back half remains as hard as ever, and it's where most real product value lives.
• Integration with legacy reality: Much of a platform's value comes from how cleanly you integrate with existing systems—partner APIs, core processors, decades-old internal services. AI tools excel in greenfield environments but noticeably weaken the moment they encounter our actual constraints. The messy, context-heavy integration work that defines real-world platform engineering is exactly where they help least.
• Decision quality at the strategy layer: I hoped AI synthesis would sharpen our prioritization. It has made us faster and better-informed, but it hasn't made the hard calls easier—because hard calls were never about a lack of information; they were about conviction, tradeoffs, and risk appetite. AI gave us more analysis; it didn't give us more clarity. That was a useful expectation to correct.

Why AI integration should be a step-by-step progression

You can't skip the lower layers. The instinct with AI — especially with today's capable models — is to reach straight for the impressive end state: the autonomous system, the agent that acts on its own. I learned you must earn your way there. Trying to shortcut it costs you.

I now think of it as a maturity progression. AI capability in any serious operational context progresses through stages — productivity first (making existing work faster), then efficiency (automating routine steps), then intelligence (deeper insight and decision support), and only then autonomy (systems that act on their own). Each layer depends on the one beneath it. You can't deploy a reliable agent on a platform that can't yet observe itself, surface its own configuration, or show you why it made a decision. Autonomy without observability isn't sophistication — it's risk you can't see.

If I'd figured this out earlier, I would have avoided the temptation to over-promise the top of the stack before the bottom was solid. The most ambitious demo easily pulls you in because it excites everyone. But a flashy autonomous capability sitting on an immature foundation breaks in ways that are hard to diagnose and quickly erodes trust — and trust, once spent on a system that acted wrongly, is expensive to rebuild.

So, I would tell anyone launching their first AI-driven product: be honest about which layer you're on, ship real value at that layer, and let the higher-order capabilities earn their place. Sequencing is the whole game.

How CPOs can optimize for the right scarcity

Overall, my advice is to stop optimizing for the wrong scarcity.

For most of our careers, the bottleneck was production — getting things built. So we organized everything around throughput: backlogs, capacity planning, shipping faster. AI just collapsed that bottleneck. The cost of generating an option, a prototype, a draft, an analysis is approaching zero. And when one constraint disappears, a new one becomes the thing that matters.

The new scarce resource is judgment — knowing what's worth building, what to say no to, what "good" looks like, and what AI's confident output is quietly getting wrong. So my advice has three parts:

1. Spend your AI dividend on judgment, not just speed: The point of moving faster isn't to ship more — it's to buy more shots on goal so you can be more selective. If AI just makes you build more of the wrong things faster, you've made the problem worse, not better.
2. Stay close to the craft: The leaders who'll struggle are the ones who treat this as someone else's tooling decision. Go build something yourself. You can't lead a team through a shift you've only read about — your instincts will be calibrated to a world that no longer exists.
3. Get sharper about your domain, not vaguer: Everyone now has access to the same general-purpose AI. Your edge isn't the model — it's the specific, hard-won knowledge of your customers, your regulatory reality, your business. AI commoditizes the generic and makes the specific more valuable. Lean into what's yours.

This moment rewards taste and conviction over information and effort. That's uncomfortable, because you control effort, and you must develop taste. But the leaders who internalize that early are the ones who'll compound.

Follow along

You can follow Abhi Gandotra's work on LinkedIn and his website. Or check out his book, The Sovereign Agent.

More expert interviews to come on The CPO Club!