Role: Product Manager, Offline Downloads
Product: A global subscription streaming platform (company and product name withheld to respect confidentiality)
Scope: Global rollout across 70+ markets, 7M+ monthly users, 32M+ monthly downloads
The starting point
When I took over Offline Downloads, the feature was already live and working well in the US. It had been built the way most good teams build a first version, fast and focused, scoped tightly around the core experience so real user value could ship quickly. A few capabilities were intentionally left for later phases as the roadmap matured.
The core job of the feature, letting users download a show and watch it without a connection, worked cleanly, and users in the US liked it. What it had not been built for yet was scale. It was designed around one market and one set of assumptions, and my job was to take something that already worked well in one place and make it work everywhere.
Why 70 markets is not the same feature 70 times
The first assumption that broke was about mobile data. In the US, we shipped with the Download Over Cellular toggle set to 'ON' by default, because US users generally do not think twice about using mobile data. That default is wrong almost everywhere else. In APAC and LATAM, mobile data is expensive, and connections are slower, so the same default that felt convenient in the US would have quietly burned through people's data plans in other markets. We had to rethink default settings market by market instead of treating one configuration as global.
The second, bigger problem was licensing. Every studio partner had its own rules for offline playback: some allowed 4K downloads, others capped at 1080p. Expiration windows ranged from 30 days to 6 months to no expiry at all. Getting this to work was not just a legal negotiation; it also meant real backend work to support different rules for different content, and constant work to keep studios aligned so users did not end up facing five different sets of behaviour depending on what they were watching.
On top of that, we had to build region-specific subscription plans. Launching in APAC meant creating a new mobile-only plan with a 15 download limit, sized to that market's usage patterns and price sensitivity, not copied from the US plan.
A decision I had to own: the Singapore R21 requirement
Singapore has a legal requirement that certain rated content, R21, must be locked behind an age verification PIN. This gave me a real fork in the road.
One option, the one most competitors used, was to send users through a full profile selection screen when they opened offline mode, capturing consent upfront before they could see anything. The other option was to only ask for the PIN at the exact moment someone tried to play an R21 title.
I chose the second one. Two reasons. First, the legal requirement was specifically about verifying age before playback, not before browsing, so gating at playback satisfied the actual rule without adding friction everywhere else. Second, building a profile selection flow for offline mode from scratch would have needed significant new work and pushed our timeline out, while gating at playback let us reuse components we already had.
It was the right call for the deadline, and it held up legally, and it taught me that compliance requirements usually have a narrower literal ask than the safest-looking industry pattern suggests. You just have to read the requirement closely enough to see the gap.
Managing a tight timeline
A month before our first launch, our product lead and engineering lead reviewed the full feature list against the launch date and made a call to trim some planned functionality on Android to hit the deadline. It meant a few capabilities moved to a later phase, and Android trailed iOS slightly in feature parity right after launch.
We treated that gap as unfinished work rather than a fixed state, and closed a good part of it over the following months. Usage kept climbing steadily through this period, reaching 7M+ monthly users and 32M+ monthly downloads. Once we saw customers were getting strong, consistent value from the feature as it stood, we made a deliberate choice to keep the roadmap focused on what was already resonating with users rather than adding features nobody had asked for yet. The core experience was doing its job well, and that mattered more than a longer feature list.
What actually moved the needle
The biggest shift for me was learning to say no to features that looked good but were not load-bearing. During the R21 work, for example, I chose not to show profile names on the PIN entry screen, just icons. Small decision, but it saved real engineering effort and helped us hit the deadline without touching anything users actually cared about.
That became the operating principle for the whole rollout: ship what a user genuinely needs to trust and use the feature, and resist the pull toward polish that does not move usage. It is a large part of why a feature that started as a thin US-only MVP became one people actually relied on, at global scale.