Somesh
Sharma

Context

Amazon was building Vega OS, a completely new Linux-based operating system built on React Native to replace the Android-based Fire OS that had powered Fire TV devices since 2014. Every streaming app had to be rebuilt from scratch. Pluto TV, as one of the largest free ad-supported streaming services, needed to be ready for launch day. Internally at Paramount, we called this Project Kepler.

The Problem

This wasn't a feature update or a platform migration. It was a 0-to-1 build for an operating system that didn't exist yet. Amazon had their own technical spec, their own review process, and a hard external timeline. Internally, there was pressure to pursue a beta on an older codebase, which would have split engineering focus. There was also a proposal to delegate EPG delivery to a third-party vendor, which would have introduced alignment and bandwidth risks I wasn't comfortable absorbing. The integration touched content ingestion, EPG delivery, playback, Trickplay, and deep linking, all for an entirely new platform architecture.

My Role

I owned Project Kepler from zero. That meant requirements gathering against Amazon's new Vega OS spec, defining the product strategy and roadmap, building and leading the team, managing the direct partnership with Amazon, and coordinating cross-functional delivery across engineering, design, and QA. I prioritized the launch submission over the beta on the old repo, because splitting focus would have guaranteed we shipped neither well. I declined the third-party EPG delegation, because handing a core surface to a vendor we didn't control would have introduced a dependency we couldn't de-risk in time. I owned the Trickplay feature directly and presented the beta to Vibol Hau, EVP and CTO of Paramount Streaming.

Approach

I mapped every deliverable Amazon required for Vega OS certification, scoring each by effort and risk, and drew a clear line between "must ship" and "fast follow." I ran weekly syncs with our Amazon partner rep to stay ahead of spec changes. Internally, I structured the backlog around the certification checklist rather than our usual sprint themes, which meant the team always knew exactly where we stood relative to the deadline. When scope questions came up, I defaulted to protecting the core integration and deferring everything else.

What Made This Hard

Building for a platform that doesn't exist yet means your spec is a moving target. Amazon's timeline didn't flex, the technical architecture was brand new (React Native on Linux, not Android), and every scope decision had to balance internal engineering capacity against a partner's evolving expectations. The hardest part was saying no to things that were reasonable in isolation but would have fragmented a team that needed to stay focused on shipping a 0-to-1 product for launch day.

Context

Pluto TV acquires a massive volume of new users, but acquisition only matters if those users actually activate. Activation means a new user finds content they care about, watches long enough to understand the value, and comes back. The onboarding experience is the single highest-leverage moment in that journey, and it was underperforming.

The Problem

We were seeing significant drop-off in the first session. Users were getting overwhelmed by the content grid and leaving before they experienced what Pluto TV offered. The funnel data was clear: the gap between "landed" and "watched for 5+ minutes" was too wide, and it was costing us retained users at scale. This was a growth bottleneck with real revenue implications.

My Role

I owned the onboarding redesign from diagnosis through launch: pulling funnel data, identifying drop-off points, forming hypotheses, designing the experiment plan, working with design and engineering on variants, and interpreting results. This was a PM problem, not a design problem, because the core question wasn't "what should the screen look like" but "what does a new user need to understand in the first 60 seconds to stay?"

Approach

I isolated the three biggest drop-off points and built a hypothesis for each. We ran multi-variant A/B experiments, sequencing them so each test built on the last. The winning combination reduced first-screen choices, surfaced content categories aligned with popular entry points, and got users into playback faster. We didn't redesign the whole UI. We rearranged what mattered most and removed what didn't.

What Made This Hard

Onboarding experiments are deceptively complex because you're optimizing for a behavior (activation) that doesn't happen in the same session where you make the change. I had to define an activation metric that was meaningful for the business, instrument it properly, and resist the urge to declare a winner before the cohort data was actually conclusive.

Context

Future Today operates in the FAST streaming space, running a portfolio of streaming channels and apps across Android mobile and CTV platforms. When I joined, the company had early traction but needed to scale aggressively: more apps on more platforms, stronger content discovery, better ad monetization, and flagship products that could compete for top rankings.

The Problem

The challenge was operating at two speeds. On one track, deploy and maintain 150+ apps across Android mobile and Amazon FireTV, each with its own testing requirements and release processes. On the other, build Fawesome and HappyKids into products good enough to earn #1 rankings. Scale required systems. Flagship quality required taste, product-market fit, and deep attention to content, ads, and UX.

My Role

I wore every hat. Product lead, developer, and tester. I owned content strategy, ad monetization, product-market fit, marketing input, app deployment, testing, and technical initiatives. For the 150+ app portfolio, I managed deployment across all Android and FireTV CTV platforms. For Fawesome and HappyKids, I shaped the product direction that took them to #1.

Approach

On the technical side, I led DRM implementation to protect premium content, ad prefetching to reduce latency and improve fill rates, and ad deduplication to prevent repeat ads that were degrading user experience. On the product side, I focused Fawesome and HappyKids on curated content categories, low-friction playback, and a family-safe experience for HappyKids that parents trusted.

What Made This Hard

Being the product lead, developer, and tester forces constant context-switching between strategic and tactical work. You're defining the roadmap in the morning and debugging a DRM issue in the afternoon. Most PMs work on one product with a dedicated team. I was managing 150+ apps while building two flagship products that needed to be best-in-class. The upside is that I understand the full stack of what it takes to ship, not just the strategy layer.