QCon London 2026: Your Multi-Cloud Strategy Is a Product Problem — Treat It Like One

At QCon London 2026, Luis Albinati and Surabhi Mahajan from JP Morgan Chase delivered a provocative message: most enterprises are solving the wrong problem with multi-cloud. The chaos isn't a technical challenge—it's an organizational one.

The Chaos Tree: How We Got Here

Albinati, a product director overseeing JP Morgan Chase's multi-cloud platform, opened with what he called the "chaos tree." Cloud migration was originally sold on promises of cost optimization and agility. Neither panned out cleanly. Companies found themselves spending more, running ungoverned workloads, and layering on remediation programs such as FinOps, governance, and SaaS compliance—each with its own tooling and headcount—until sixteen or more active projects were competing for the same engineering budget.

The core issue is that teams operate in silos. One team owns GCP, another AWS, another Azure, each with its own roadmap. When AI enters the picture, teams wanting access to Vertex AI, Bedrock, and Azure OpenAI simultaneously, those silos multiply. Nobody has the full picture.

The Product Management Fix

Their proposed solution borrows from product management. Rather than organizing around cloud providers, Albinati pushed for organizing around capabilities: observability, cost management, identity, networking, and delivery. Each capability cuts horizontally across every cloud and business line, shifting conversations from "what does our AWS roadmap look like?" to "are we delivering unified observability everywhere?"

He stressed structured demand governance, opening intake windows at a cadence, forcing teams to submit requirements, and closing the window to allow planning. This creates a predictable rhythm where engineering can actually deliver rather than constantly context-switching between competing priorities.

The Frankenstein Logging Case Study

Mahajan, a principal architect and technical product manager for JP Morgan Chase's logging platform, brought the argument down to earth with a concrete example. She described what she called "Frankenstein logging"—the reality of running a centralized logging platform that ingests data from GCP, AWS, and on-premise systems by funnelling everything into S3 buckets on AWS.

The result: massive egress costs, noisy data, and SREs stuck correlating timestamps across three browser windows during a 2 AM incident.

Their fix was to think about it as a product team would. They identified their users—SREs and cyber operations—and studied how those users actually queried data during real incidents over the previous year. Then they deployed OpenTelemetry collectors at the edge in each cloud, filtering out health checks and low-value events before anything crossed a network boundary.

Mahajan reported that this approach cut log volume by sixty to eighty percent, sending what she called "signals, not noise." They also standardized on distributed trace IDs as a "golden thread" that flows across all environments, which reduced the mean time to identify from hours or days to minutes.

The Console Test: A Practical Takeaway

Mahajan left the audience with a practical takeaway: a "console test," a set of scenarios that any platform team can run against their own logging infrastructure. If your platform passes, you've built something that treats the cloud providers as raw materials for a unified engineering experience. If it fails, you know what to fix next.

The Manifesto: Principles for Sustainable Multi-Cloud

Albinati closed with a set of principles framed as a manifesto:

• Capabilities over siloed solutions: Organize around what users need, not which cloud they're using
• Shared discovery over isolated priorities: Make demand visible across the organization
• Golden paths over bespoke one-offs: Standardize the happy path, allow exceptions deliberately
• Governance by design: Build compliance and cost controls into the platform, not as afterthoughts
• Resilience over mere portability: Sometimes the answer involves better contracts about differentiated SLAs, not just better Kubernetes deployments

He was blunt about that last point: portability solves some problems, but sometimes the answer involves better contracts about differentiated SLAs, not just better Kubernetes deployments.

Why This Matters

The multi-cloud problem isn't going away. Acquisitions, regulatory pressure, and AI workloads will continue driving organizations across multiple clouds. The question isn't whether you'll be multi-cloud—it's whether you'll be chaotic or intentional about it.

Treating multi-cloud as a product problem means accepting that the technical complexity is manageable, but the organizational complexity is the real challenge. It requires product thinking, user research, and the discipline to say no to good ideas that don't fit the unified vision.

For platform teams, this means shifting from being cloud experts to being capability experts. Instead of knowing every AWS service inside and out, you need to understand what your users are trying to accomplish and build the simplest possible path to get there—regardless of which cloud they're using.

As Mahajan put it: "If you're still correlating timestamps across three browser windows at 2 AM, you're doing it wrong." The solution isn't more tools or better cloud expertise—it's treating your multi-cloud strategy like the product it actually is.