How do you convince 36 newsrooms and one giant corporation to build the same app?

01·GETTING IN THE DOOR

I joined NBCTelemundo after 4 years at my first "big boy" job out of college. At AFS, I joked that I was the Chief Executive Millennial (when that still meant being young). I was a part of the marketing team and somehow had complained enough about how horrible our website was that I got the greenlight to redesign the CMS from the ground up. That was 50+ websites in 20ish languages. That story is perhaps a bit too old and a bit too rose tinted for it to justify a whole write-up, but I genuinely think that what I learned there made the rest of this possible.

Daniel Alvarez, who was teaching the product management class I was taking at General Assembly, was transitioning from HuffPo to take over product at NBCTelemundo Local, brought me on board to take over weather products. By both of our admittance, I knew nothing about weather products. What I did have was the ability to hyperfixate on the topic and become a competent PM in a subject where the hiring pool is fairly shallow. He had also heard me talk at length about how I managed stakeholders in a couple dozen countries and thought it prepared me for the organizational behemoth of Comcast NBCUniversal.

I don't think either of us thought I was going to be leading the redesign of every stations' app within the year.

02·THE EXPERIMENT

Fast forward a couple of months, and I'm annoying the hell out of Mike, the senior PM I worked closely with, to make bigger and bolder changes to the apps. Mike was an incredibly disciplined PM that knew every key metric by heart on any given day. I on the other hand was in my mid twenties and had a lot more motivation than experience. In time I would learn that my big ideas were only possible with Mike's numbers.

It was the first time I was a part of a team that size and would spend a lot of time bouncing ideas off of other PMs and designers. To be honest, I don't know or think that the idea of a reverse chronological newsfeed was originally mine, but I know that I latched onto it.

I remember discussing the idea with the national editorial team and there being a lot of discussion around the loss of editorial intent. On the other hand, Twitter was still relevant and Facebook had just rug-pulled every media outlet by deprioritizing video, and we needed ENGAGEMENT.

The experiment I designed was simple. I worked with Steve, our superstar backend engineer, to create an API that would serve the news from newest to oldest. We repurposed an existing UI component to stand up the experience in-app, and we ran an A/B test on 10% of our incoming traffic split proportionally among stations.

After two or three months, the results were in and the reverse-chron feed had succeeded. It became the second module with most interaction on our homepage after the Top News section.

03·THE BIG YES

Skip ahead once again and Mike left, which meant I was now responsible for all 36 apps, not just the weather. That also meant 36 local editorial teams to respond to. They knew I did stuff outside of weather thanks to the experiment, but I was about to test their trust a lot more: I wanted to redesign the apps from the ground up.

There were multiple reasons to this, some better than others. On one hand, I thought the app was plain-old-ugly. I was embarrassed to tell my cool-mid-2010s-hipster-creative-friends that this was the app I was working on. We were on the cusp of millennial optimism, Ubers were still cheap, fast-casual restaurants were the big thing (RIP OG Dig Inn at Madison Sq Park), and I wanted to have a cool app to my name.

The much better reasons were that the codebase was antiquated and made development a slog. There was no underlying design system, so every piece of iteration threatened with collapsing the house of cards. Editors had to jump through hoops to get anything published.

Around this time, Daniel had asked to visit multiple stations to train the staff on the new CMS we had just developed (different story), and I decided it was the perfect time for a roadshow. If I wanted to rebuild the app from the ground up, I would have to make the case to the stations, like when in a proper democracy the executive branch seeks out votes for a bill in the house and senate.

My pitch was oriented around three key axes, and I think this might actually be a useful template for other PMs. I have used this approach ever since; the pitch answered three questions:

• What does this do for me? If you're going to ask stakeholders to disrupt the way they work and relearn a whole new tool, you have to have a clear idea of how the product would impact each group. The deck started with per-group objectives for the project: for the editorial team, the dev team, ad ops, local stations, design team…
• Why do we need to change? I took a deep dive into our numbers (thanks for teaching me how to use Adobe Analytics, Mike), and tried to paint the most complete picture of our users that I could. I particularly went after the preconceptions I often heard repeated in meetings when talking about app users. For example, there was the misconception that people didn't really use the app to read articles because a third only ever read one article and churned. What I found was that the remaining two thirds included significant numbers of power users that read most of the articles we published. I then found user feedback that backed up that claim, and repeated that process for as many relevant points as I could find.
• How are you going to do this? This is perhaps the most important bit, and is part of how I think about work in product. I presented my product philosophy; principles that would guide every decision made from that point on. For this project they were:
  • Relevant: users were to encounter relevant content to engage with at every step. That meant ensuring that publishing and managing stories was easy for editorial, but also that users were always presented with a new story to continue reading.
  • Reusable: to the best of our ability every component we designed and built should be reusable across all 36 apps and serve different roles within them. This ensured that when a bigger station with more sway asked for a feature, that we could steer it towards something that was beneficial to everyone while still meeting the original stakeholder's needs.
  • Adaptive: the app had to have the built in flexibility to be customized on a per-station basis, but more importantly, it needed to be ready to receive and display any content coming from the CMS that powered the websites. This was targeted at specifically reducing the number of app-specific workflows that editors and writers had to engage in. Once you published on the site you could be confident that it would look perfect in the app.

This was all before we wrote any tickets, or wireframed any experiences. I wanted to set the stage for my engineers and designers to do their best work possible without having to backtrack or pause constantly for internal approvals. This didn't mean keeping stakeholders out of the loop, but instead invite them into the loop, show them how the sausage is made, and provide a framework within which to discuss requests. Once you have an established product philosophy, you don't have to immediately say 'No.' You can point back to those principles and ask: how does this new ask fit in those parameters we established together.

So after pitching the roadshow deck to my boss, the VP of Engineering, the VP of the division, the chairman of the division, the chief editor, the ad operations team, the security team, and every station, we had the greenlight to design and build.

04·PROMISES KEPT

The story of how we actually built 36 apps is a lot more familiar to anyone in product: write, design, test, build, test, repeat. I wrote a much more detailed breakdown of the design process and some of the bold ideas that got us the numbers I'm going to share below, but in case you've read enough here they are:

Page views increased by 130% and article views by 109%. The Latest News feed was now used daily by 16% of our users, and generated an average of 165,000 article pageviews a day — about 22.6% of the 730,000 we averaged daily. 1-click publishing to the app was now available to every station. We had a properly codified design system. Engineers could build without breaking. And on a personal level, when Daniel left on paternity leave for 4 months, I was put in charge of the product team. If we (you the reader and me) ever chat, ask me about the other news outlet that I tried this at.