AWS IVS Integration

The problem

Customers using InPlayer need an OVP (Online Video Platform) to actually stream their content. A meaningful chunk of them already had AWS accounts but they couldn't use AWS for live streaming through us, because IVS wasn't one of our supported OVP integrations. Their options were limited:

• Sign up for one of our supported OVPs and pay an annual license even for a one-time event.
• Lease one of our OVP accounts, which worked but added a manual step and slowed setup down.
• Use a manual workaround that required extra setup on their side and didn't guarantee a clean experience.

When we looked at our customer data, around 46% of our customers were running one-time events. Those customers were leasing InPlayer's Brightcove account and 89% of content streamed through Brightcove in 2021 was live, with most viewers in Europe. The "one-time event customer on an annual license OVP" pattern was almost half our base.

Beyond the customer problem, the IVS integration had direct business benefits: simplifying OVP setup would reduce sales friction, and the integration would automatically renew our AWS partnership, avoiding a full review process.

We ran RICE prioritization across the Integrations team's OKRs, and the IVS integration landed high enough to pick up.

Discovery

The discovery work was relatively straightforward. We had clear quantitative data on customer behaviour, what percentage ran one-time events, how Brightcove was being used, where viewers were located. The product designer and I also spoke with internal stakeholders who'd been handling the OVP leasing process, to understand the friction from their side. The AWS IVS documentation was reviewed and solutionised together with the Engineering Manager.

One thing that shaped the eventual scope: IVS required a specific setup flow on the AWS side each time a customer was configuring a one-time event. Most of our customers weren't AWS experts. So making the integration genuinely friction-free meant providing a step-by-step guide covering both staging (for testing) and production environments, so customers could complete setup without needing to learn AWS along the way.

Validation and go-live

We ended up with a setup process that, once a customer had their AWS account configured, took a few minutes to wire up on our end. We added documentation, explanatory text, and contextual links throughout the dashboard to handle the most common questions.

The integration shipped on schedule. The AWS partnership renewed automatically. The integration was working in production at the time of InPlayer's acquisition by JWX.

What this work opened up

When we scoped IVS, we framed it as an OVP integration, a way to remove friction for one-time-event customers. That was the value at planning time, and it's what RICE scored.

What we didn't fully appreciate was that IVS ships with its own engagement capability through the Timed Metadata API, essentially a way to attach real-time data to a live video stream, which third parties can use to build interactive widgets like chat or polling that stay in sync with the video. By the time we'd shipped IVS, the integrations team was also working on LiveLike for engagement on paywalled content. The downstream effect: customers ended up with a choice: use LiveLike, or use IVS's native engagement features.

The reason this is worth mentioning isn't that we planned it that way. It's that we didn't, and it worked out. The pattern I started paying attention to after this, and that's stayed with me, is that integrations don't just solve the problem you scope them for. They expand the surface of what becomes possible later.