Jio Platforms Limited · 2024–2025
How might we ship a streaming and subscription experience at national scale without letting payment friction or launch risk reach the viewer?
Owning a streaming integration end to end at one of India's largest digital platforms: behaviour signals into requirements, prototypes before build commitment, dashboards for launch KPIs, and readiness work across APIs and event streams.
- Role
- Associate Product Manager — owner of the integration backlog
- Timeline
- Dec 2024 – Jun 2025
- Team
- Product, engineering, QA, DevOps, support and operations
- Product area
- Streaming, subscriptions and payments
- Platform
- Mobile and connected-device apps on a shared services backend
- Key skills
- PRDs & acceptance criteriaBehavioural analysis (SQL)Prototype validationRelease readinessKPI dashboardsRoot cause analysis
Case study in 30 seconds
Problem
A streaming integration had to reach a subscriber base at national scale across two rollouts, with subscription and payment paths that could not be repaired after launch.
My role
I owned the backlog: requirements, acceptance criteria, dependency tracking, launch-readiness reviews and the reporting layer around them.
Key product decision
Prototype and validate the payment and subscription experience with engineering before committing it to a build slot, instead of specifying it and discovering the gaps in QA.
Outcome
89% on-time delivery against committed milestones across two rollouts, and a 40% cut in manual reporting effort once launch KPIs had one definition.
Some implementation details have been omitted to respect confidentiality. This case study focuses on the product thinking, decisions, process, and lessons I can share publicly.
Context
Jio Platforms serves a subscriber base measured in hundreds of millions across telecom and consumer apps. A streaming integration inside that ecosystem is not a feature launch — it is a change to how a very large number of people reach content they have already paid for, in some form, somewhere else in the bundle.
The product surface was small. The surrounding system was not: entitlement, subscription state, payment, and playback each lived behind different services, communicating over REST APIs and Kafka event streams, with support and operations teams downstream of every edge case.
My starting material was behavioural: more than 10,000 user-behaviour signals describing how people moved through subscription and playback paths. That volume is useful and misleading in equal measure — it tells you what happened at scale, and nothing about why.
The problem
User problem
A viewer who believed they already had access hit a subscription or payment wall at the moment they wanted to watch. The failure was invisible until it was maximally frustrating, and the recovery path ran through support rather than through the product.
Business problem
Two rollouts had committed dates and cross-team dependencies. Slipping meant renegotiating with partners; shipping a broken entitlement or payment path meant support cost and churn on a subscriber base large enough that a small percentage is a large number.
Product challenge
The tension was between speed and irreversibility. Playback bugs can be patched. Payment and entitlement mistakes reach money and trust, and they arrive in support queues before they arrive in dashboards. The plan had to be fast on the reversible parts and slow on the irreversible ones.
Discovery & insights
The evidence came from three places that disagreed with each other often enough to be useful: behavioural data, the people who absorb failures, and the systems themselves.
- 10K+ user-behaviour signals queried in SQL across subscription and playback paths
- Support and operations input on what actually generates tickets
- Service logs, Kafka consumer behaviour and Kubernetes service data
- Engineering feasibility sessions on entitlement and payment sequencing
- Stakeholder requirements from business, partner and platform teams
We expected
We expected the drop-offs to cluster where the interface was most complex, and to be solvable with clearer copy and layout.
The evidence showed
The behaviour signals showed drop-off concentrated at state transitions — the handoffs between entitlement, subscription and payment — rather than on any single screen.
So we changed
The requirements shifted from screen-level polish to defining what the product does in every intermediate state, including the ones nobody had named.
We expected
We expected release risk to be mostly about feature completeness against the PRD.
The evidence showed
Repeat launch risk came from integration behaviour under load and from event-stream ordering, which no feature checklist covered.
So we changed
Launch readiness became its own tracked artefact — API and event-stream verification alongside functional sign-off — instead of an implicit part of QA.
We expected
We expected stakeholders to disagree about priorities.
The evidence showed
They mostly disagreed about definitions. 'Active user' and 'successful subscription' meant different things in three different reports.
So we changed
Before arguing about targets, we standardised metric definitions into one executive-facing source of truth. The argument got much shorter afterwards.
Product decisions
Each decision below is recorded the way I'd record it for a team: what we chose, the signal behind it, what we gave up, and what we were optimising for.
Decision 01
Prototype and validate the payment and subscription flows with engineering before committing them to a build slot.
Signal
Behavioural data placed the highest-cost failures at transitions between subscription and payment states — exactly the area where a rebuild after launch is most expensive.
Alternative considered
Write the requirement, hand it to engineering, and catch the gaps in QA. Faster to start, and it is what the calendar wanted.
Tradeoff we accepted
We spent time before the build that looked like delay on a schedule with committed dates, and it pushed lower-risk work later in the sequence.
Why it mattered
Payment and entitlement errors are not patchable in the way a layout bug is. Buying certainty before the build was cheaper than buying it back after.
Decision 02
Standardise launch and adoption metric definitions into a single executive-facing source of truth before building any new reporting.
Signal
The same KPI appeared with different numbers in product, engineering and business reporting, and reconciling them was consuming hours per rollout cycle.
Alternative considered
Keep the existing reports and add a reconciliation step, or build a nicer dashboard on top of definitions that still disagreed.
Tradeoff we accepted
Agreeing definitions across three functions took negotiation time, and some teams lost a metric they were attached to.
Why it mattered
It cut manual reporting effort by 40% and, more importantly, meant launch decisions were made against one number instead of three.
Decision 03
Treat launch readiness across REST APIs and Kafka event streams as a tracked gate, owned jointly with engineering, QA and DevOps.
Signal
Root-cause analysis on earlier issues traced repeatedly to integration behaviour and event ordering rather than to feature defects.
Alternative considered
Rely on functional QA sign-off and handle integration issues reactively during rollout.
Tradeoff we accepted
It added a gate that could block a date, and it required engineering time on verification rather than on features.
Why it mattered
It moved a class of failure from the live rollout into pre-launch, where fixing it is cheap and nobody's evening is interrupted.
Decision 04
Sequence scope for the subscription feature against support and operations load, not only engineering effort.
Signal
Support input identified which states generate disproportionate ticket volume; behaviour data confirmed those states were common, not edge cases.
Alternative considered
Prioritise purely by build cost and partner visibility, which would have shipped more surface area in the same window.
Tradeoff we accepted
Some visible improvements moved to a later rollout in favour of unglamorous state handling.
Why it mattered
The rollout was judged on whether it held up, and the things that make a rollout hold up are rarely the demo-friendly ones.
Execution
Decisions became artefacts: requirements someone could build against, a readiness gate someone could fail, and reporting someone could act on.
PRDs, user stories and acceptance criteria
Written from the behavioural signals rather than from feature requests, with each intermediate state named and given an expected product behaviour.
Validated flow prototypes
Payment and subscription paths walked through with engineers against real service constraints before the build slot was committed.
Launch-readiness reviews
A tracked gate covering REST API and Kafka event-stream behaviour, run with engineering, QA and DevOps, with dependencies tracked in Azure Boards.
Rollout reporting layer
SQL, Tableau and Power BI dashboards for rollout KPIs and user behaviour, built on the standardised metric definitions.
Root-cause protocol
A shared path through logs, SQL and Kubernetes service data so that an issue during rollout had a diagnosis route rather than a war room.
Step 01
Signals
SQL across 10K+ behaviour events
Step 02
Requirements
PRDs, stories, acceptance criteria
Step 03
Prototype gate
Payment & subscription flows validated
Step 04
Build
Dependencies tracked in Azure Boards
Step 05
Readiness gate
APIs + Kafka streams verified
Step 06
Rollout
KPI dashboards live from day one
How the work happened
Walked payment and subscription flows against service constraints before commitment, which changed the sequencing of the build rather than just its estimate.
Turned requirements into acceptance criteria and automated coverage, so 'done' had the same meaning on both sides of the handoff.
Co-owned the readiness gate across event streams and services; their operational view caught ordering risks a functional review would not.
Their ticket patterns reprioritised scope — the state-handling work in rollout two came directly from what they were absorbing in rollout one.
Negotiated one shared set of KPI definitions, then reported rollout status against them in a single executive view.
Outcome
89%
On-time delivery
Against committed milestones, two rollouts
40%
Less manual reporting
After standardising KPI definitions
10K+
Behaviour signals used
Turned into requirements, not slides
Award
Jio Spotlight Award
For proactive contribution to the team
The qualitative outcome matters as much as the numbers: by the second rollout, launch readiness was a gate the whole group ran rather than a conversation product had to start.
What I'd do differently
What worked
Validating the irreversible paths early. Every hour spent on payment and entitlement before the build returned more than an hour after it.
What didn't
I standardised metric definitions after the reporting pain had already accumulated. Doing it in the first two weeks would have saved the reconciliation work entirely.
What I learned
At this scale, most product risk is in the transitions between systems, not inside any one screen. Requirements that only describe screens will be incomplete by construction.
What I'd test next
I would instrument the intermediate states before the first rollout rather than after it, so that the second rollout's prioritisation came from measurement rather than from support anecdote plus query.
Like how I think?
I'm currently exploring full-time Product Management opportunities.
Next case study