Vizio's WatchFree+: Ad-based streaming

Vizio has been a top hardware producer of TVs for nearly 20 years. Vizio smart TVs feature a built-in “app” that runs on top of the firmware and system layers. For six years, Vizio’s smart TV digital platform existed mostly as a centralized library- referred to as “SmartCast”- that surfaced content provided through partner app feeds that could be organized into carousels and would launch the corresponding apps that the content was available on. A separate app provided the linear stream experience- WatchFree (WF)- created and maintained by a 3rd party- that was, for the most part opaque to Vizio. WF had an outdate design and was nearly impossible to update, plus all ad revenue was split with the 3rd party in addition to paying them for their service and engineers. 

Replace the inefficient, outdated and poorly managed external linear streaming app with an in-house solution that will provide Vizio complete control over ads, analytics data and content: WatchFree+.

• Product 
• Engineering 
• Business Development + Marketing
• Platform+ (aka Monetization Team + Ads Team)

• Backend Providers: 3rd party distributors -Amagi, Wurl, Xumo, Go See Play, etc- that host/stream the content for production studios
• Content Providers: Production studios and independent content partners not using backend providers for streaming their content. Eg; NFL
• Ads Servers: 3rd Party solutions such as SpringServe
• Nielsen DAR: Digital ads ratings company that provides analytics on user groups to allow for targeted ad serving ($$)
• Inscape: Sister company to Vizio; a data house

Whenever possible, meetings should be working sessions and canceled in advance whenever an email or Slack is more suitable. I only required devs to attend meetings where they would be getting important context/decisions or be absolutely critical, otherwise, I would handle all meetings personally. Devs need time to dev. Whenever possible, I encouraged Slack to be used instead of 1:1 convos so that info is available and everyone is aware of the status. 

Going into WF+, I knew the scope was less a project and more of a new department. I started by approaching the initial goal- proof of concept. I needed a quick way to get the channels to display in carousels, click-to-launch and play- without using our CMS. I devised a strategy that used a flat file- a csv file that I could define and drop in S3 and that a new API could pass to the client. This solved the big problem- how do we get the content into the system without requiring building a new CMS platform or a dedicated dev to constantly be updating and maintaining the channels and their configurations.

I met with the backend providers and established a cadence for onboarding channels. Through the first partner, Wurl, I was able to suss out all of our technical & system requirements and create a smooth process for onboarding that allows launching about 10 channels a week

For the actual WF+ platform and UI, I took the PRD from Product and UX to create a lightweight charter (functional spec) where I clearly broke out each major feature in a table that gave us a high level overview. I then divided features into milestones that made sense for technical implementation and met the primary goals from the stakeholders. I created a charter for each milestone where I sussed out all the feature details, dependencies (of which there were many), testing matrix, schedules and clearly defined the scope. Forming a small, dedicated dev team, the team and I spent a sprint planning out what steps- high level- were needed for implementing the app through Milestone 2. We broke out the work and I had the devs give high-level estimations. 

Once the work was clear, I called a meeting of the broader dev team and technical leadership to review and buy-off to catch what we missed. I then broke out all the work into tickets, added details, and slotted the work into sprints based on my knowledge of their capacity and what is realistic (plus padding and testing allotment). After everyone was in agreement, I took the charters & timelines back to Product and BD stakeholders and negotiated buy-off for the project so that everyone agreed what was realistically feasible. These charters served as the contract for the project and allowed us to stay in-scope and avoid radical change. It also gave non-technical teams a clearer idea of what was actually needed and why work took the time it would.

I enabled my devs to work closely and unbothered. Throughout the project we had frank discussions on what would impede them. Most were new to the system, so I did frequent brownbags on how Vizio gating stages worked, or how SmartCast functioned and lessons learned. I designed the flat file system to avoid being cumbersome on devs (daily requests), handling all channel onboarding personally.

1. Missing domain knowledge and uncharted territory. When the project began, no one in Vizio had experience with linear streaming. I had to become the subject matter expert, and wrote the initial design for technical implementation of linear streaming by working closely with backend partners and a fair degree of “fake it till you make it”!  
2. Internal technical requirements. Vizio is extremely complex with 25+ different chipsets/models, all with its own FW versions and all backward compatible to 2016. 
3. External requirements

                3.1.  Content Curation and CMS was not possible with the current system.

                3.2.  EPG needed a new ingestion route and validation, plus could not be counted on for accuracy, which led me to form a new QA team and testing protocol  Analytics;        

                3.3.  Nielsen DAR and Inscape were major revenue generating requirements and Nielsen had never done an integration in this way before, which led me to working closely with the partners and Nielsen tech teams to formulate the most scalable solution for sending data.