A new Ad CMS for Morning Brew

Rethinking content structures with scalability in mind, streamlining internal and external user workflows, and shifting to a developer-friendly platform

A view from Meteor’s dashboard, Morning Brew’s Ad CMS

When I joined the team at Morning Brew, the company had very quickly grown from a single daily newsletter to over 10 daily or weekly newsletter brands, a handful of podcasts, plus a booming YouTube and social presence. The existing ad platform couldn't keep up with this growth and had serious limitations:

Lacked flexibility to expand beyond newsletter ads to support the company's growing media channels or experimental ad formats
Inefficient workflows and handoff processes created bottlenecks in ad creation and some truly wild workarounds (like opening incognito windows to complete approvals!)
Collaboration between internal teams and external partners was cumbersome, with critical information often lost in email chains
Built on soon-to-be-deprecated Rails infrastructure that our engineering team was actively trying to phase out

My Role & Approach

Initially brought in to lead user research, I stepped into a product lead role when the technical PM departed mid-project. I played a key part in several phases of the initiative:

Discovery & Direction: answered the question: fix, buy, or build?
Design, Architecture & Development: mapped out Mimimum Valuable Product features, fast follows, nice to haves, and future visioning
Migration & Launch: minimized disruptions to workflow during cut-over period
Ongoing Iteration: continuing to plan for the evolution of the product

Discovery & Direction:
Product Strategy Development

I led a comprehensive discovery process alongside engineers and product leadership, to answer the question of whether to fix the existing system, buy an off-the-shelf solution, or build something new.

Conducted a listening tour with revenue stakeholders and company leadership to understand their immediate needs and long-term vision for new ad products
Led in-depth user interviews across roles: account managers, writers, editors, and ad operations teams
Observed real-time platform usage to document workflows, workarounds, and pain points
Partnered with engineers to evaluate potential vendor solutions (Kevel, AdButler)

It was apparent fairly quickly that our recommendation would be to build a custom solution using Sanity—the same content operations platform powering our editorial CMS. There were several factors in this decision:

Revenue leadership had many promising early-stage ideas, but without sufficient data to commit to any long-term changes, so we wanted a platform that would allow for ongoing experimentation and quick iteration
Off-the-shelf tools would have still required substantial customization to support our core ad products
Our engineering team had strong React expertise across the board and was already familiar with Sanity
Using the same platform would enable us to share data between systems and easily connect schemas between the two platforms

I’d love to tell you even more about this project! Get in touch →

Design, Architecture & Development

Working from our earlier research, I helped develop the plan for what we'd build. With our “small but mighty” product team being tapped for several concurrent initiatives, It was important to stay focused on MVP requirements for the initial launch, and even more important that our users would find true value in this new system immediately out of the gate.

User Experience: Focused on solving several “low hanging fruit” issues with the new system design. Opted for a universal dashboard with customizable filters that allowed different roles to view their most relevant information without the need for super individualized views. Account managers could see team assignments and due dates, writers could see their assignments, and ad ops could see which ads were ready for QA all from one place
Content Structure: Very intentionally set up content schemas with the future in mind—designing for a future where partner information might sync directly to this platform from a CRM, or could connect to event landing pages and sponsored content in our editorial CMS.
Partner Collaboration: Built a separate companion tool that external partners can access directly, that ensured assets and messaging points would be immediately available to the creative team in-platform, eliminating email chain hunting for things like images, UTMs, and pixels associated with the ads
Workflow Improvements: Implemented automated Slack notifications to alert team members at critical handoff points, such as when a partner submitted the asset collection form, or when copy was ready for an editor to review
Better Tracking: Built in metadata for ad placements to support post-run reporting both on the individual ad performance, but also on our types of ads and ad characteristics in aggregate (is there meaningful difference generally between using a photo vs. an illustration, including a discount offer? etc.)

Throughout this phase, I facilitated collaborative workshops and user testing sessions to validate design decisions and workflow improvements as the engineering team worked alongside us. We tested small things, like status color schemes, and big things like “repeat ad copy” workflows, and ended up with a very bought-in ad creation team who felt included and heard in the process

A detail from Meteor’s dashboard

Small details can go a long way, like this logo sizer/preview on the partner schema that adjusts relative sizing of a partner’s logo and tests dark mode accessibility across all MB newsletters and websites

The Partner Desk’s task-focused dashboard

Migration & Launch

Ad insertion is a mission-critical part of Morning Brew’s business, so we took extra care in the migration from the old system to the new one to avoid disruptions to the workflow:

Collaborated with engineering to automate migration of the more “evergreen” content (partner profiles and team member information for example) from the old system. By the time account managers were setting up individual ad placements, those “related” documents were already in place, and any new partners or team members had already been synced up
Recruited a small group of power users to test early versions, using their feedback to fine-tune functionality and identify edge cases before wider rollout
Worked very closely with the engineering team and account managers to find a suitable cut-over date, setting up any future ads in the new platform while still running business as usual until the switch
Tested the complete workflow with one newsletter brand for two weeks before expanding to all publications

Initial Results

Faster Ad Placement Setup: Reduced ad setup time post-sale from approximately 4 minutes to 1 (multiplied by the 6500+ ads we’ve synced and sent out over the last year)
Better Collaboration: Created seamless workflows and added accountability between partners and internal teams, eliminating the need to hunt through email chains for assets and approvals
Clear Status Tracking: Provided transparent status visibility for all stakeholders, reducing the need for status update meetings and emails
Platform Consolidation: Successfully migrated from legacy infrastructure to a more sustainable, scalable solution aligned with engineering team expertise
Improved Data Collection: Enabled more sophisticated reporting on ad performance and campaign characteristics both individually and in the aggregate
Flexible Foundation: Created architecture that supports ongoing expansion to new ad formats and media types as the business continues to grow

We rolled out the new platform, Meteor, with a series of demos that included some “light jabs” at its predecessor:

Ongoing Vision & Roadmap

I continue to work closely with the Product Manager for Advertising and Revenue to prioritize the platform roadmap. Up for consideration is:

Continuing to evolve the Partner experience by converting our work to a standalone application using Sanity's newly released App SDK (which was partly inspired by our work on this tool, and our continuing relationship with their team)
Exploring integration of podcast ad assignments and statuses into the dashboard via Monday's API to continue the move to centralize assignments and status tracking across channels
Expanding metadata capabilities to support more sophisticated targeting and personalization

Takeaways

Working on this project reinforced several principles that I find apply to most platform work:

Strategic Technology Decisions: Choose technologies that match your team's skills and future scalability needs, while carefully evaluating build vs. buy tradeoffs based on specific business requirements
User Observation Reveals Hidden Insights: Direct observation of user workflows often reveals pain points and opportunities that stakeholders might not explicitly mention in interviews or requirements discussions
Flexible Systems Serve Diverse Needs: Modular, configurable platforms with thoughtful information architecture can serve multiple user types while maintaining system coherence
Content Architecture is Foundation: Investing time upfront to create a solid content structure and data model enables future expansion and integration without major rework
Integration Drives Adoption: Connecting with the tools people already use (like Slack) significantly increases adoption and perceived value