Unlike the other projects in this portfolio, this one isn't a single product with a single arc. It's an evolving body of work. I set and delivered product scope and product phases in dynamic times for the company. I'll describe each phase in turn.
Phase 1. Proving the acquisition could deliver
The first thing we needed to prove was that the acquisition could actually deliver on what it promised. JWX and InPlayer needed to work together end-to-end, and we needed to get one beta customer onboarded on the combined offering to demonstrate it.
At this point, JWX didn't have a native subscription and identity platform. Customers got an OTT landing page (streaming app), and for subscriptions, JWX used an external third-party platform called Cleeng. InPlayer had subscriptions, monetization and identity built in. The first integration was to make the products of the two companies to talk to each other end-to-end with a beta customer as proof.
The timeline was compressed during execution, so I reprioritised scope to protect the end-to-end proof for the beta customer and delivered on the new date.
The trade-off, and the reason this couldn't be the end, was that the beta customer ended up using two separate dashboards: JWX for streaming and hosting, InPlayer for subscriptions and identity. Workable for one customer who'd agreed to it as a trade-off. Not workable for the large broadcasters JWX wanted to win. Every cross-sold customer would hit the same friction. We knew while we were shipping that the next step had to be a single JWX Dashboard.
Phase 2. The technical foundation
To reach a single dashboard, JWX and InPlayer needed to share an account and authentication layer so API calls were authenticated and user resources properly authorised. That was the InPlayer Accounts and API Integration project, scoped for one quarter.
This was the most technical project I led during the integration. Technical delivery sat with the engineering lead from the InPlayer side. My role was the product layer: I wrote and maintained the planning doc, the requirements, aligned sales and count management, and ran the Gantt chart that tracked nine concurrent workstreams across DevOps, Integrations, Payments and Subscriptions, MAAM, Product Design, CX Dev and Security teams.
The business case was specific: one customer deal worth around $500k ACV had been blocked because the API integration wasn't in place. Other smaller deals were in the same position. This work was a prerequisite for everything else but it was also unlocking immediate revenue.
We delivered in the planned timeframe. The foundations were now in place to start moving InPlayer features into the JWX Dashboard.
Phase 3. Prioritising with data, not intuition
With the foundations in, the question became which features to integrate first. The obvious answer was subscriptions and PPV as that's where most of InPlayer's value lived for broadcasters. We started the Integrated SIMS (subscription and identity management) MVP project to do exactly that.
But I wasn't comfortable just moving down a feature list. InPlayer had a wide surface area of features, and not all of them were being used the same way. Some had many customers but low ACV attached. Others had few customers but those few were the biggest accounts. I wanted to make the prioritization decision with numbers.
So in parallel with the SIMS work, I ran a full analysis. I mapped every InPlayer feature against every customer's usage, and against the ACV that customer was bringing in across 100 customers and every feature on the platform.
A few things came out of it:
- Three features turned out to be effectively unused.
- SVOD (subscription) had significantly more ACV attached than TVOD (pay-per-view also called PPV), around $850k vs $470k, which shifted prioritization.
- Customers split into distinct segments based on how they used the platform: paywall only, API only, or a combination.
For the next step, I narrowed scope. We were doing this work to bring InPlayer customers into JWX's monetization stack so I discarded customers who weren't using JWX for streaming. That narrowed to 8 customers who were API-only and using JWX for video. The Accounts and API integration we'd just finished was exactly what made those customers integrable. I worked through their specific feature usage to define the MVP scope.
The product designer and I worked through configuration decisions together in detail, particularly around subscriptions and PPV. We resolved things like: how tiered subscriptions should nest, where PPV pricing should sit, how add-ons should work. We got to answers by walking through real customer examples end-to-end: a weekend pass for a volleyball tournament, a monthly subscription with a special-event add-on, tiered plans where the higher tier included everything in the lower one plus more. Walking real examples was the only way to surface where our assumptions about configuration would break.
In parallel, I ran internal discovery and validation sessions with the CPO, sales, account management and other PMs, to translate the analysis into a story stakeholders could align on, and to surface objections before the work was committed. The analysis gave me something concrete to anchor those conversations on, which made them faster and cleaner than they would have been otherwise.
The plan held, mostly. SVOD was where stakeholders had the most differing views on granularity, so I used the usage analysis to keep re-scoping grounded in the same evidence. The rest of the plan moved forward steadily.
Phase 4. The pivot to ACS
As JWX moved toward larger customers, two constraints became clear: the architecture would not scale, and these customers wanted to buy identity or subscriptions separately. That led to a decision to build ACS as a decoupled product.
First, scalability: InPlayer's existing architecture wasn't going to scale to the size of customers JWX wanted to pursue. Second, customer fit: the bigger customers JWX was now targeting weren't looking for an end-to-end paywall and subscription platform. They already had pieces of their business across different applications and wanted to pick and choose: some only needed identity, some only subscriptions. The platform needed to be decoupled so customers could buy what they needed and integrate it into their existing stack.
Combined, those two reasons made continuing the feature-by-feature integration the wrong path. That led to a decision to rewrite the underlying platform as a new product called Access Control Service (ACS).
This was a significant pivot. New scope, new architecture, in some ways a new product. An in-person workshop shaped what ACS should be, involving the CPO, two external product partners and two JW engineers. After the workshop, I continued the project from the product and delivery perspective with a new team of engineers.
The work I'd done in Acts 1 to 3 fed into ACS planning, not as scope to carry forward, but as customer signal and operational understanding to inform the new architecture. This was the last work I led on this body of work before moving to Content Protection at JWX. A successor product partner company continues the evolution of InPlayer today.
Data doesn't end disagreements. It improves them
The feature usage analysis served two purposes: it gave me a precise scope to deliver on, and it gave every stakeholder conversation a shared piece of evidence to work from. Data doesn't end disagreements, but it gets everyone working from the same picture so the conversation is about what the picture means, not whose intuition is right. That changed how I think about analytical work. It's not just a way to make decisions. It's a way to align stakeholders.
What holds across strategy changes is the customer signal, not the plan
Strategy changes for real reasons: markets shift, customers shift, leadership shifts. What can hold is the customer signal underneath. The customers we were serving needed less friction and more flexibility. That underlying need stayed the same across every strategy change. The technical answer changed multiple times, but the customer answer kept pointing in roughly the same direction. Keeping that signal alive in every iteration meant the work survived the pivots.
Engineers who think like product people change the texture of the work
On this project the engineering manager and team weren't just executing tickets. They understood InPlayer deeply, cared about it being used, and were proactive about surfacing product implications of technical decisions. That freed me to spend my time on the product and stakeholder layer. Looking back, a lot of why this work held together across the strategy changes was because the engineers were thinking like product people and that's one of the first things I'd look for when assembling a team for similar work.