ITDigest’s Interview With Fredrik Gessler, Head of Product Management, API @ Vonage

The key to building a durable business comes down to one simple question, are we able to solve a customer need, at scale? An API that can be demonstrated to solve a customer need will gain attention.

• Fredrik, your career has moved across product management, business strategy, customer relationships, partnerships, and large-scale network leadership. What early experience still shapes how you distinguish between technology that is impressive and technology that creates lasting customer value?

Over the years, what continues to be a clear sign of technology that resonates and that has lasting power is simplicity in adoption. If a capability requires the customer to fundamentally change how they work to benefit, adoption is always an uphill struggle. If it slots into a workflow they already have and a need they have in their business, the path to value is much shorter. That discipline starting from the customer’s reality rather than the technology’s potential is something I try to bring into every product conversation I have today.

• You spent several years leading Network Systems and Verification at Ericsson, with responsibility for architecture, quality, performance, and more than 1,500 engineers. What did working at that scale teach you about removing unnecessary complexity without losing the technical depth that makes a network dependable?

Complexity for its own sake never works but oversimplification is not the answer either. What I have learned is that the two are not mutually exclusive if you are disciplined about where and how complexity makes sense. The complexity belongs inside the system, managed by the people who understand it best. What faces outward whether that is an interface, a process, or an API should be as clean and simple as possible. The engineering depth does not disappear; but is abstracted to the right level. That principle has directly shaped how I think about Network APIs today. The sophistication of a mobile network is extraordinary, and that sophistication is what makes the capability valuable. Our job is to make it accessible.

• Your time with Swisscom brought you close to both network strategy and customer experience, including the early rollout of 5G in Europe. What did that partnership teach you about the gap between what a network can technically deliver and what customers actually experience as valuable?

Switzerland is probably one of the most challenging countries in the world to build and run mobile networks considering its topology combined with strict regulation on radio emissions. At the same time, Swiss subscribers tend to be highly quality and performance sensitive. They expect coverage, high data speeds, excellent voice quality whether in downtown Zurich, hiking the Alps, or traversing the country’s valleys and tunnels by train. Our joint mission, in the virtual joint venture between Swisscom and Ericsson, was to deliver on customer expectations under those challenging conditions. Success was visibly measured in public benchmarks, where we were proud to emerge as clear winners across all types of benchmarks over a period of many years and the first European operator to launch 5G services. My learning from this remarkable achievement is that you need a combination of deep expertise, performant products and services, and a highly dedicated team that is performing at its best. This is what Swisscom and Ericsson were able to bring together, and this is what Vonage is committed to in the CPaaS industry.

• You now work on making capabilities that once lived deep inside the mobile network accessible through APIs. When you look at a new network capability, what tells you it is ready to become something developers and enterprises should be able to build into their products?

There are a few signals I look for. The first is standardization, whether the capability is expressed through a consistent, interoperable framework such as CAMARA, which means a developer does not have to learn a different integration for every operator. The second is whether the capability solves a real problem that developers and enterprises are already trying to solve, even imperfectly. SIM Swap detection is a good example: enterprises were already trying to address account takeover risk through other means, and network-level signals give them something significantly more reliable. The third, and perhaps most important, is whether we can abstract the operational complexity sufficiently. The carrier registration, the consent frameworks, the geographic variation, so that a developer can access the capability without needing to become a telecom specialist. When all three conditions are met, the capability is ready to move from the network into the product layer.

• Open Gateway now spans more than 300 mobile networks representing over 80% of global mobile connections. As that ecosystem scales, what becomes possible for developers and enterprises when network capabilities can be accessed through a common platform rather than through fragmented operator-by-operator integrations?

Fragmentation has historically been the single biggest obstacle to developer adoption of network capabilities. The underlying capabilities existed, but accessing them meant a different negotiation, a different integration, and a different contract with each operator. Most developers simply could not justify that investment, and most enterprises could not operationalize it at scale. What Open Gateway changes is the addressable reach. When a developer writes once to a standardized API and can reach the majority of global mobile connections through a single integration, the economics of building on network capabilities become fundamentally different. Applications that depend on real-time network intelligence – fraud prevention, identity verification, quality-of-service management – can now be designed with genuine global reach from the outset. That shift from fragmented to federated is what unlocks the market, and it is what we are focused on at Vonage: ensuring that our platform sits at that point of access, so that complexity stays on our side of the integration and developers can simply build.

• Much of your earlier career involved business cases, pricing, profitability, customer value, and P&L, while your current work spans communications and Network APIs. When you look at this market commercially, what separates an API that attracts attention from one that can become a durable business for developers, enterprises, and operators?

The key to building a durable business comes down to one simple question, are we able to solve a customer need, at scale? An API that can be demonstrated to solve a customer need will gain attention. However, for it to offer a real business value, for us and for our customers, it has to scale. This involves aspects such as ease of adoption, performance and reliability, and of course hitting the right cost points for the business case to fly.

• You recently wrote about using network-level signals such as SIM Swap and number verification to strengthen digital identity. As fraud prevention becomes an early Network API use case, where do you see the biggest opportunity to make digital trust stronger while making the user experience feel simpler rather than more restrictive?

The fundamental challenge in fraud prevention has always been that the measures designed to protect customers often create the most friction for them. SMS one-time passwords are a useful illustration: they were introduced as a security layer, but they are increasingly exploited through SIM swapping and social engineering, and they add a step the customer has to complete every time. Network-level signals work differently because they operate silently in the background. A bank can check whether a SIM swap has occurred on a device in the last 48 hours before authorizing a high-value transaction without imposing a manual interaction on the customer. If the signal is clean, the journey is frictionless. If the signal is anomalous, the additional step is justified. That is the model I find most compelling: using the network to make invisible the checks that should be invisible, and reserving friction for the moments where it corresponds to genuine risk. The opportunity is to make customers feel more trusted by their institutions, not less, precisely because the underlying verification is more robust.

• Vonage now brings communications APIs, Network APIs, fraud prevention, and developer tooling into a broader API platform. What becomes possible when these capabilities are designed as one connected developer experience, rather than asking developers to navigate the underlying complexity of telecom themselves?

The telecom stack is genuinely complex carrier relationships, network registration requirements, consent frameworks, geographic variation in operator coverage. When we absorb that complexity inside the platform and expose a unified developer experience on top, we fundamentally change what developers can build and how quickly they can build it. A developer building a financial services application today can use our messaging capabilities to communicate with their customers, our network APIs to verify identity and detect fraud signals, and our quality-of-service tools to manage connectivity for critical transactions – all through a single integration layer, with consistent authentication, consistent documentation, and consistent support. What that enables is not just convenience: it enables a class of application that could not previously be built without multiple specialist vendor relationships and significant integration engineering. The platform becomes the capability. I think that shift – from APIs as individual tools to APIs as a connected infrastructure – is where the most interesting enterprise value gets created over the next few years.

• AI is changing not only what applications can do, but also how they interact with infrastructure. As AI agents increasingly discover and use services on behalf of users, what changes for API design when the consumer of a network capability is no longer always a human developer?

This is one of the more consequential design questions facing the API industry right now. When a human developer integrates an API, they bring context, judgement, and a degree of interpretive flexibility. They can read documentation, make inferences, and course correct. When an AI agent is discovering and invoking capabilities dynamically, the requirements shift significantly. The API needs to be self-describing in a way that a machine can act on reliably. The authentication and consent models need to handle non-human actors. The rate limiting, error handling, and fallback behavior need to be deterministic rather than recoverable through human intervention. At Vonage, we are adapting our platform design for agentic consumption – not just exposing network capabilities but expressing them in ways that AI systems can discover, evaluate, and use safely and appropriately. APIs that are not designed with this in mind will become harder to use as AI-driven architectures become more prevalent, not easier.

• You’ve consistently emphasized long-term improvement, quality, and finding more efficient ways to build products. As programmable networks, AI, and the next generation of telecom architecture converge, what principle from your own career do you most want to carry forward into the products you help shape?

The most enduring products are the ones that make something difficult feel straightforward to the people who depend on them. Not by hiding the difficulty but simplifying it so that it can be managed most effectively and, sometimes, removing it entirely. Mobile networks are some of the most sophisticated engineering systems humanity has built, and the programmability we are building into them through Network APIs represents a real step change in what is possible. A developer building an application in 2027 should be able to access the intelligence of a 5G network the same way they access a database or a payment processor today: reliably, predictably, with clear documentation and sensible pricing, and without needing to understand the decades of infrastructure engineering underneath it. Getting this right – technically, commercially, and operationally – is the work I care most about, and it is the standard I want to hold our products to.

Thanks Fredrik !