• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

What’s up everyone, today we have the pleasure of sitting down with Hope Barrett, Sr Director of Product Management, Martech at SoundCloud.

Summary: In twelve weeks, Hope led a full messaging stack rebuild with just three people. They cut 200 legacy campaigns down to what mattered, partnered with MoEngage for execution, and shifted messaging into the product org. Now, SoundCloud ships notifications like features that are part of a core product. Governance is clean, data runs through BigQuery, and audiences sync everywhere. The migration was wild and fast, but incredibly meticulous and the ultimate gain was making the whole system make sense again.

In this Episode…

• SoundCloud’s Big Messaging Platform Migration and What it Taught Them About Future-Proofing Martech
• Structuring Martech Like a Product Team Actually Works
• How to Get Internal Buy-In for a Martech Platform Migration
• How to Run an RFP That Doesn’t Waste Everyone’s Time
• How to Vet Martech Vendors for Real Scale Under Pressure
• How a Martech Migration Reshaped the Whole Marketing Team
• Letting 135 People Use Your Warehouse-Native Stack
• Doing Work You Actually Enjoy Without Burning Out

About Hope

Hope Barrett has spent the last two decades building the machinery that makes modern marketing work, long before most companies even had names for the roles she was defining. As Senior Director of Product Management for Martech at SoundCloud, she leads the overhaul of their martech stack, making every tool in the chain pull its weight toward growth. She directs both the performance marketing and marketing analytics teams, ensuring the data is not just collected but used with precision to attract fans and artists at the right cost.

Before SoundCloud, she spent over six years at CNN scaling their newsletter program into a real asset, not just a vanity list. She laid the groundwork for data governance, built SEO strategies that actually stuck, and made sure editorial, ad sales, and business development all had the same map of who their readers were. Her career also includes time in consulting, digital analytics agencies, and leadership roles at companies like AT&T, Patch, and McMaster-Carr. Across all of them, she has combined technical fluency with sharp business instincts.

SoundCloud’s Big Messaging Platform Migration and What it Taught Them About Future-Proofing Martech

Diagnosing Broken Martech Starts With Asking Better Questions

Hope stepped into SoundCloud expecting to answer a tactical question: what could replace Nielsen’s multi-touch attribution? That was the assignment. Attribution was being deprecated. Pick something better. What she found was a tangle of infrastructure issues that had very little to do with attribution and everything to do with operational blind spots. Messages were going out, campaigns were triggering, but no one could say how many or to whom with any confidence. The data looked complete until you tried to use it for decision-making.

The core problem wasn’t a single tool. It was a decade of deferred maintenance. The customer engagement platform dated back to 2016. It had been implemented when the vendor’s roadmap was still theoretical, so SoundCloud had built their own infrastructure around it. That included external frequency caps, one-off delivery logic, and measurement layers that sat outside the platform. The platform said it sent X messages, but downstream systems had other opinions. Hope quickly saw the pattern: legacy tooling buried under compensatory systems no one wanted to admit existed.

That initial audit kicked off a full system teardown. The MMP wasn’t viable anymore. Google Analytics was still on Universal. Even the question that brought her in (how to replace MTA) had no great answer. Every path forward required removing layers of guesswork that had been quietly accepted as normal. It was less about choosing new tools and more about restoring the ability to ask direct questions and get direct answers. How many users received a message? What triggered it? Did we actually measure impact or just guess at attribution?

“I came in to answer one question and left rebuilding half the stack. You start with attribution and suddenly you’re gut-checking everything else.”

Hope had done this before. At CNN, she had run full vendor evaluations, owned platform migrations, and managed post-rollout adoption. She knew what bloated systems looked like. She also knew they never fix themselves. Every extra workaround comes with a quiet cost: more dependencies, more tribal knowledge, more reasons to avoid change. Once the platforms can’t deliver reliable numbers and every fix depends on asking someone who left last year, you’re past the point of iteration. You’re in rebuild territory.

Key takeaway: If your team can’t trace where a number comes from, the stack isn’t helping you operate. It’s hiding decisions behind legacy duct tape. Fixing that starts with hard questions. Ask what systems your data passes through, which rules live outside the platform, and how long it’s been since anyone challenged the architecture. Clarity doesn’t come from adding more tools. It comes from stripping complexity until the answers make sense again.

Back to the top ⬆️

Why Legacy Messaging Platforms Quietly Break Your Customer Experience

Hope realized SoundCloud’s customer messaging setup was broken the moment she couldn’t get a straight answer to a basic question: how many messages had been sent? The platform could produce a number, but it was useless. Too many things happened after delivery. Support infrastructure kicked in. Frequency caps filtered volume. Campaign logic lived outside the actual platform. There was no single system of record. The tools looked functional, but trust had already eroded.

The core problem came from decisions made years earlier. The customer engagement platform had been implemented in 2016 when the vendor was still early in its lifecycle. At the time, core features didn’t exist, so SoundCloud built their own solutions around it. Frequency management, segmentation logic, even delivery throttling ran outside the tool. These weren’t integrations. They were crutches. And they turned what should have been a centralized system into a loosely coupled set of scripts, API calls, and legacy logic that no one wanted to touch.

Hope had seen this pattern before. At CNN, she dealt with similar issues and recognized the symptoms immediately. Legacy platforms tend to create debt you don’t notice until you start asking precise questions. Things work, but only because internal teams built workarounds that silently age out of relevance. Tech stacks like that don’t fail loudly. They fail in fragments. One missing field, one skipped frequency cap, one number that doesn’t reconcile across tools. By the time it’s clear something’s wrong, the actual root cause is buried under six years of operational shortcuts.

“The platform gave me a number, but it wasn’t the real number. Everything important was happening outside of it.”

Hope’s philosophy around messaging is shaped by how she defines partnership. She prefers vendors who act like partners, not ticket responders. Partners should care about long-term success, not just contract renewals. But partnership also means using the tool as intended. When the platform is bent around missing features, the relationship becomes strained. Every workaround is a vote of no confidence in the roadmap. Eventually, you’re not just managing campaigns. You’re managing risk.

Key takeaway: If your customer messaging platform can’t report true delivery volume because critical logic happens outside of it, you’re already in rebuild territory. Don’t wait for a total failure. Audit where key rules live. Centralize what matters. And only invest in tools where out-of-the-box features can support your real-world use cases. That way you can grow without outsourcing half your stack to workaround scripts and tribal knowledge.

Back to the top ⬆️

Why Custom Martech Builds Quietly Punish You Later

The worst part of SoundCloud’s legacy stack wasn’t the duct-taped infrastructure. It was how long it took to admit it had become a problem. The platform had been in place since 2016, back when the vendor was still figuring out core features. Instead of switching, SoundCloud stayed locked in and built layers of fixes around it; internal APIs, homegrown middleware, and a custom implementation that got harder to maintain with every passing year.

By the time the team recognized the cost of inaction, it was too late for small changes. Hope inherited a situation where key functionality lived outside the product entirely. And the consequences showed up in every support interaction. Whenever something broke and her team escalated it to the vendor, the response was always the same: “You’ve got a custom implementation. Go talk to your engineers.”

That sentence, repeated enough times, becomes a business case to rebuild.

“You want the new features, but you’re not in the queue. Out-of-the-box users always get the roadmap first.”

Hope’s philosophy now is direct. Custom implementations are a liability unless they’re portable. You can’t just chase functionality and patch around missing pieces. You have to plan for vendor obsolescence. That means limiting hardcoded dependencies. If your frequency logic, messaging throttles, or segmentation filters only work with one vendor’s stack, then you don’t have infrastructure. You have lock-in disguised as flexibility.

Every workaround adds friction to future change. The lesson from SoundCloud’s delay was clear: early adoption without reevaluation turns into deadweight. The longer you wait to fix it, the more expensive it becomes to leave.

Key takeaway: Build every martech layer like you’ll need to replace it. Avoid custom setups unless the infrastructure can be reused across vendors. Out-of-the-box users get product attention first, so align your stack accordingly. Future-proofing doesn’t mean chasing edge-case features. It means making clean exits possible before you’re forced to take them.

Back to the top ⬆️

Structuring Martech Like a Product Team Actually Works

How Product Teams Can Actually Own Martech Without Breaking It

Hope runs martech at SoundCloud like a product. Not a marketing sub-function, not a side branch of engineering. It lives inside the same cross-functional team that ships core user features. Messaging isn’t treated as a campaign layer or an afterthought. It’s considered product surface. When a listener gets a push notification that an artist dropped a new track, that message is the feature itself, not “spam” like a lot of product/engineering folks would say.

This structure only works because it reflects how the platform behaves. Messaging isn’t just external communication. It’s a critical part of how the app functions. If a user DMs someone, they expect a message to go out. If someone likes your upload, the artist should hear about it. These are not campaigns, they are direct extensions of user behavior. Hope’s team sits alongside engineering, product, and design. They meet together. They ship together. And they’re evaluated on product performance, not marketing metrics.

At her previous role at CNN, Hope owned newsletters. She loved them. But she also saw the difference. A newsletter there was a record of what happened. At SoundCloud, messaging is what’s happening. The distinction matters. When messaging becomes fundamental to how users interact with your product, the ownership model has to evolve. That means breaking down traditional silos. It means embedding martech talent where product thinking happens, not where campaign calendars live.

“If an artist drops a new track and I follow them, I get notified. That message pulls me back into the product. It’s not a follow-up, it is the product.”

SoundCloud’s team isn’t bloated. They’re around 425 people, which helps keep collaboration direct. The martech team sits in Slack with lifecycle leads, engineers, and vendors. Everyone is in the same conversation, aligned on the same goal. They don’t just talk about campaigns. They talk about SoundCloud. That structural clarity lets them move fast without creating messes. It protects engineering time without creating bottlenecks. And it gives lifecycle work the internal visibility it deserves.

Key takeaway: If messaging is core to your product experience, martech should sit inside product. Align teams based on behavior, not department charts. Structure around how the system functions, not just who pays the invoice. That way you can deliver messaging that feels like part of the product, not commentary on it. Lifecycle stops being a channel and starts becoming a feature.

Back to the top ⬆️

Why Lifecycle Messaging Should Be Built Like Product

Hope thinks about messaging the same way she thinks about core product features. Not because it sounds good on a slide, but because that’s what it is. At SoundCloud, lifecycle messaging isn’t an add-on to the product, it’s embedded into how users experience it. From the first notification that someone liked your track to the weekly emails recommending songs based on your listening behavior, each message is an extension of the product itself. Messaging isn’t commentary. It’s infrastructure.

That thinking shapes how Hope builds her team. In a single Slack channel, you’ll find engineers, lifecycle marketers, data teams, and vendor reps all working on the same set of problems. No one’s talking about “email sends” or “campaign volume.” They’re talking about SoundCloud. The app. The system. The user experience. That structural overlap matters. It changes how decisions are made and keeps everyone focused on the actual outcome; user value, not channel metrics.

SoundCloud’s newsletters are a good example. On the surface, they look like traditional lifecycle content. But they’re not driven by a calendar or campaign. They’re triggered by behavior. The recommendation engine surfaces tracks based on what users are already listening to. The newsletter packages them, sends them, and pulls users back into the app. It’s not a broadcast. It’s a dynamic, product-led loop. And it requires cross-functional teams who understand messaging not as a send, but as a signal.

“Even our newsletters are product. They reflect how users engage with the app, and they drive that engagement forward.”

Hope still maintains a welcome series for new users. There’s structure there, and it follows some conventional patterns. But the real strength of SoundCloud’s messaging is how little of it depends on guesswork. It reacts to real usage. It blends product data with delivery mechanics. And it creates a feedback loop that marketing teams alone can’t build. You need engineers. You need data. You need a product mindset. Otherwise, it’s just noise in the inbox.

Key takeaway: Lifecycle messaging should act like product, not promotion. Design it around real user behavior, not calendar pushes. Build your teams cross-functionally, with engineers, marketers, and data working side by side. That way you can create messaging systems that respond to users in real time, reinforce product value, and actually feel like part of the experience, not just a follow-up to it.

Back to the top ⬆️

Why Martech Teams Should Prioritize Users Over Internal Stakeholders

Hope does not think of marketers as her primary customer. She thinks of the end user as the customer, always. That framing changes how decisions get made. It also reframes how internal teams collaborate. Lifecycle isn’t treated as a sandbox where marketing gets to test flashy ideas unchecked. It’s a product surface. The message a user receives is part of their experience with the platform, which means governance is built into the system from the start.

At SoundCloud, most messaging has a clear and defined purpose. It’s either triggered directly by user behavior, or it’s embedded into structured flows like onboarding. Hope’s team doesn’t “approve” these messages after the fact. They build them with the lifecycle and product teams from the beginning. When the onboarding journey for artists was designed, it wasn’t just lifecycle marketers stringing emails together. The product team responsible for upload tools was directly involved in mapping what should be taught, when it should be surfaced, and how that learning should be delivered.

“It’s not lifecycle owning a stream and hoping it fits. It’s lifecycle and product designing it together, step by step.”

That structure makes a huge difference. Governance doesn’t mean slowing things down. It means there’s no guesswork about why a message is going out, who it’s for, or what part of the product it supports. The volume stays under control because the logic is built from the user’s perspective, not the team’s desire to hit an email quota. Hope is protecting product coherence. And because that governance is embedded in how work happens (not tacked on after) it scales without adding friction.

SoundCloud has managed to keep lifecycle operations collaborative without compromising user trust. Not because they have a strict approval committee, but because they treat messaging as a product responsibility, not just a marketing tool.

Key takeaway: Let the product experience define your messaging priorities, not just internal marketing goals. Treat the user as the customer, and build governance into the design process, not as a layer of approval. That way you protect the user experience without becoming a bottleneck. Sound control doesn’t come from saying no, it comes from designing better, earlier.

Back to the top ⬆️

How to Get Internal Buy-In for a Martech Platform Migration

Hope didn’t sell the platform migration at SoundCloud with a deck. She didn’t evangelize it either. She just pulled out a Confluence doc from 2019. That single move changed the entire dynamic. It wasn’t some big, disruptive shift. It was a long-overdue response to a pattern of complaints that had been quietly tolerated for years. Hope didn’t pretend the platform was suddenly broken. She showed it had been broken for a while. And people finally stopped hoping it would fix itself.

There were still skeptics. There always are. People who’ve been burned by vendor migrations before. People who think waiting it out might hurt less than ripping it out. People who have no idea how much backend tape and ductwork is holding the current stack together. So she built credibility with transparency. She walked through every step of the RFP research. She didn’t just list vendors. She showed who backed them, their financial viability, and how each one stacked up against the team’s needs.

Hope’s position helped her move quickly. She wasn’t full-time staff at the time, so she didn’t have managerial overhead slowing her down. She had one job and no internal baggage. But that also meant she had to win trust without a title to lean on. She built that trust by making the process visible. She didn’t just announce the decision. She showed how the decision got made.

“You can tell people you did the work, or you can just show them the work. Showing is faster.”

The real unlock wasn’t the analysis. It was the early interviews. Hope and the lifecycle lead spoke with stakeholders across the org before anything was decided. They asked real questions about what was broken, what people needed, and what had become too painful to ignore. Those answers didn’t just inform the vendor checklist. They became the checklist. When people saw their own concerns reflected in the plan, they stopped resisting it. They already saw themselves in the outcome.

Key takeaway: If you want consensus, start before the decision. Pull the history. Surface the pain. Interview the people who will live with the result. That way you can anchor the change in their own experience. Show your work and keep the process visible. People rarely push back on a decision they helped shape. They only push back when they feel like the work happened in the dark.

Back to the top ⬆️

How to Run an RFP That Doesn’t Waste Everyone’s Time

Hope doesn’t treat RFPs like homework. She treats them like real decisions with real consequences. No templated grid. No fake scorecards. No copy-pasted legalese that pretends to be due diligence. When she ran the process at SoundCloud, she didn’t just write a list of requirements and call it done. She built a 13-page briefing that gave vendors context, history, and a sharp definition of what was actually broken. It read more like a pre-mortem than a pitch.

She started with people, not paperwork. Before writing anything, Hope went straight to the internal teams. She wanted to know what was frustrating, what had stalled, and where people felt cornered. She didn’t assume a new vendor would magically fix it. She wanted to know what kind of fix would even matter. That prep became the spine of the RFP. It wasn’t about checking boxes. It was about writing questions that mattered to the people doing the work.

“You don’t want someone to open your doc and say, ‘Wait, when did we start doing this?’ That’s a failure. You bring them in early, or you’re just solving the wrong problem.”

Hope kept everything transparent, down to the smallest detail. Every vendor got the same briefing. Every question that came in got shared with the full group. She ran anonymous Q&A sessions, organized feedback loops in Excel, and created a formal scoring rubric with weighted criteria across 16 categories. Over 200 questions. Six vendors. Every answer was graded and documented. No drama. Just real work.

She didn’t skip the hard part. When vendors lost, she called them. She explained why. She gave them the actual feedback. And because she was so involved throughout, she didn’t have to scramble for answers. She knew the process. She trusted the outcome. Even if the selected vendor ended up being a short-term fit, she could stand behind the process completely. That confidence didn’t come from being right. It came from being thorough.

Key takeaway: If you care about the decision, care about the process. Build your RFP with real input from the teams feeling the pain. Write your questions to reflect actual problems, not theoretical feature lists. Keep the process open, structured, and visible. Score everything. Explain everything. That way you make a call you can defend, improve on, and learn from, even if the vendor you pick eventually flames out.

Back to the top ⬆️

How to Vet Martech Vendors for Real Scale Under Pressure

How to Pick a Martech Vendor You Can Actually Work With

Hope didn’t hire based on demos. She didn’t get charmed by logos or feature charts. She made her vendor decision by watching how teams behaved when stakes were real and timelines were brutal.

The RFP was massive. Over 200 questions, 16 categories, and a calendar that made seasoned vendors sweat. Hope’s deadline was January 19, and she kicked off finalist demos just after Labor Day. That meant every meeting, every reply, every signal counted. She needed execution, not promises. One finalist squinted at her timeline and said, “Yeah, I think you could do that.” MoEngage showed up with a project plan. Not a sales deck. Not an AI-generated checklist. A real, detailed plan for how to get it done.

“I had one vendor say, ‘We’ll do our best.’ MoEngage came with a plan. That was the difference.”

Hope built rapport during the process because MoEngage was consistent and human. She exchanged emails with their sales lead almost daily. The communication was fast, real, and had enough personality to make the process tolerable. When a vendor can be both technically sharp and a decent hang, that sticks with you. In contrast, one finalist sent answers so short they barely registered. Every response raised more questions than it answered. That kind of friction is fine in the early stages, but when you’re staring down a migration window with no safety net, you want clarity. You want partnership. You want someone who shows signs they’ll still be answering emails once the contract’s signed.

Hope also paid close attention to how well vendors understood their own product. She was allergic to third-party integrator models. If the people selling the platform couldn’t explain how it worked or what it would take to adapt it, that was an automatic red flag. MoEngage didn’t bluff. They admitted where things stood and offered realistic workarounds. They didn’t over-promise, but they didn’t sandbag either. They showed her what would be possible and how they’d get there.

None of this came down to a single killer feature or sexy new dashboard. It came down to trust. Not trust as a vibe, but trust built through repetition and rigor. Hope created a selection process that surfaced how vendors operate under pressure, how they handle ambiguity, and whether they treat RFPs like real collaboration or just another bid. MoEngage made it clear they were ready to build, not just sell.

Key takeaway: If you want to know how a vendor will work with your team, watch how they behave during your RFP. Pay attention to how they answer hard questions, how quickly they respond, how well they understand their own product, and whether they bring actual plans to the table. That way you can choose a partner who doesn’t just say yes, but shows you how they’ll make it happen.

Back to the top ⬆️

How to Vet Vendors Who Say They Can Handle Your Scale

Hope had already seen what happens when systems collapse under load. At CNN, she watched platforms choke when traffic spiked. So when she moved to SoundCloud, where the stakes were higher and the messaging volume crossed 100 million, she came in with one question on repeat: can you actually handle this?

The answer, most of the time, was soft. Hope wasn’t looking for bravado or vague promises. She wanted specifics. That meant asking for references with similar use cases, pressing for hard numbers, and running vendor selection like an infrastructure audit. One tactic stood out. She prioritized vendors from Southeast Asia, especially India. The reasoning was blunt. If your product survives daily internet chaos in Mumbai, it can probably handle scheduled sends in Europe.

“I figured if you’ve got clients pushing that volume in India, you’ve probably already dealt with scale problems we haven’t even thought of yet.”

MoEngage rose to the top because they already supported music streamers in India, with listener bases comparable to SoundCloud. Hope ran reference calls. She asked direct questions. She checked usage stats and load timelines. That was her substitute for sandbox testing, which she had used in longer vendor evaluations. At CNN, she once eliminated a vendor outright for refusing to participate in a sandbox. The others built test environments that gave her team hands-on experience before any contract was signed.

At SoundCloud, time was the enemy. Demos happened in September. Contracts needed to be signed in October. Everything had to be live by mid-January. With that kind of schedule, there was no luxury of pilots or drawn-out validation phases. So she treated the reference calls as her battlefield. She did not rely on sales decks or roadmap fluff. She used track records, stress-tested performance, and conversations with customers who had already been through the fire.

Key takeaway: When scale matters, stop guessing. Run reference calls with customers who match your volume. Pressure test with specifics. If timelines are short, treat real-world customer proof as your sandbox. Prioritize vendors who can point to actual throughput, not just promised capacity. The only reliable indicator of future performance is proven performance under strain.

Back to the top ⬆️

How a Martech Migration Reshaped the Whole Marketing Team

How to Rebuild 200 Campaigns in 12 Weeks Without Losing Your Mind

Twelve weeks. Over 200 campaigns. Three people. That was the headcount and the deadline Hope was staring down when SoundCloud decided to move off their old messaging platform after seven years. Most teams would treat that as a fire drill and copy-paste every dusty workflow into the new tool, bugs and all. Hope did the opposite. She saw it as a kill switch.

The lifecycle team audited every campaign in a spreadsheet. They scored them from zero to three based on priority. Dead weight got cut. Low performers were paused. Anything worth keeping was rebuilt in a brand-new template. That scoring system made triage less emotional and way more efficient. They didn’t need philosophical debates over whether a message from 2018 was still relevant. If it didn’t rank, it didn’t ship.

“What we had was so old and dated. If we’re starting over, we might as well start clean.”

They paid MoEngage extra to help with the migration. That meant using MoEngage’s team to rebuild templates and port campaigns, while Hope’s team stayed focused on strategy. It was not cheap. It was worth every cent. Without that outside help, they would’ve spent the 12 weeks fighting formatting and flowchart logic instead of getting real campaigns live.

There was still pressure. Their old contract ended January 19. They needed to be live that day, with no fallbacks. Hope’s team focused on a minimum viable messaging set (email, push, in-app) anything classified as tier zero. They didn’t hit full parity by January, but the critical pieces shipped. That was enough to keep things moving, and more than enough to avoid a messaging blackout.

Key takeaway: A migration deadline is not a strategy. Use it as a forcing function to cut noise, kill bad logic, and reset templates. Score every campaign by value, rebuild only what matters, and get outside help for the operational lift. If you have 200 workflows and 12 weeks, you cannot afford nostalgia. Prioritize clarity over completeness, and ship the messages that actually do the work.

Back to the top ⬆️

How Martech Tooling Forces You to Rethink Team Design

Before the migration, Hope’s CRM team was mostly duct tape and triage. Two people, sometimes three, hard-coding HTML every day. They weren’t optimizing or iterating. They were drowning in requests and just trying to get emails out the door. The tools technically supported drag-and-drop editing, but no one touched it. Too clunky. Too late.

Post-migration, the whole structure got a reboot. One of those original team members now runs the department. They’ve added roles with actual leverage, not just volume. There’s a senior analyst focused on campaign performance. There’s a lifecycle specialist prototyping flows and testing AI. There’s someone else fully embedded in cross-functional work, aligning campaign ops with product timelines.

“We didn’t just grow the team. We got clear on what roles actually move engagement and subscriptions.”

This shift didn’t happen because the new platform had magical features. It happened because the team stopped reacting and started planning. They used the migration to scrap old assumptions, reevaluate where work was happening, and staff accordingly. They didn’t balloon headcount for the sake of it. They filled gaps that had been quietly draining results for years.

Now, the CRM function looks less like a task queue and more like a team with a roadmap. They aren’t waiting on Jira tickets. They’re pushing strategy upstream and treating campaign management as a product with iterations, experiments, and ownership.

Key takeaway: Replatforming forces decisions. Use it as your window to rethink your team from the ground up. Stop staffing for production speed and start building for outcome clarity. Add roles that handle data, testing, and orchestration. Promote from within if possible, but shift responsibilities based on what actually grows engagement. Your tool isn’t the blocker. Your structure is.

Back to the top ⬆️

Letting 135 People Use Your Warehouse-Native Stack

Warehouse Native Campaign Execution Without Losing Control

Letting non-marketers run campaigns sounds like a governance nightmare. Hope did it anyway. And she made it work by drawing one hard line. Anyone could draft messages. Only the Lifecycle team could push them live.

The shift started with a drag-and-drop editor. No more hand-coded HTML. Anyone across SoundCloud, from product to analytics to support, could log into MoEngage and build a message. That opened the gates in the best way. More ideas, faster turnaround, broader ownership. But no message reached a user without passing through Lifecycle. They owned audience logic, deliverability checks, and send approval.

“Anyone can write a message, but only our Lifecycle team activates it. That way we protect the user experience and avoid campaign noise.”

Guardrails extended to data. Every event (app, web, product) got funneled into BigQuery. From there, Hope’s team used a reverseETL tool to fan it out into MoEngage, AppsFlyer, and a handful of other downstream tools. No more inconsistent tracking across SDKs. No more fragile integrations. Everything flowed through one system of record. That setup reduced tech debt, improved portability, and let her performance marketing and analytics teams work from the same dataset.

This structure let them scale usage without introducing chaos. At last count, 135 employees had access to MoEngage. Hope made peace with that number because the structure was solid. Message creation was democratized. Activation stayed centralized. Data moved predictably. And no one had to build the same audience five times in five platforms. They built it once in BigQuery and sent it everywhere.

Key takeaway: Democratizing messaging and data starts by separating contribution from control. Use low-friction tools like drag-and-drop editors to let anyone draft campaigns, but gate sending behind a team that knows the full system context. Centralize events in your warehouse and use reverse ETL to push audiences into downstream platforms. That way you can scale access across your org without drowning in chaos or duplicating logic. You get more brains on the work and fewer fires in production.

Back to the top ⬆️

Building Audiences Once and Letting Them Travel to Your Stack

Hope is done rebuilding the same segment five different ways just to run five campaigns. If the logic already lives in the warehouse, it should travel. And that’s exactly what her team is doing.

SoundCloud’s audience strategy centers on BigQuery. That is where segments are defined, and ReverseETL pipes them out to wherever they’re needed: DV360, TikTok, MoEngage, you name it. Hope doesn’t want campaign logic reinvented inside every platform. She wants it versioned and owned, like source code. That way you can fix a broken segment once instead of chasing down five broken implementations.

“I don’t want to build the same audience five times. That just adds all sorts of room for error.”

That doesn’t mean every audience needs to start in the warehouse. MoEngage’s drag-and-drop tools still have a place for one-off lifecycle messages or fast iterations. Their Warehouse Segments feature gives marketers SQL-level access to BigQuery without ever leaving the ESP interface. Hope’s team was an early partner on this, and they’ve used it to open up audience building without handing over the keys to the core schema.

The performance marketing team, though, has a stricter policy. Segments live in BigQuery. They get deployed through Reverse ETL. Period. That consistency avoids duplication and lets the team confidently reuse audiences across channels. It also limits error-prone guesswork from vendor-native segmentation that drifts over time.

This warehouse-native approach shifts audience targeting from a fragmented guessing game into a durable system. The benefit isn’t just consistency. It is sanity.

Key takeaway: Store audience definitions in your warehouse and treat them as a shared asset, not throwaway config in each tool. Use reverse ETL to push those segments to all your endpoints. Let marketing teams work inside the ESP when it’s faster, but keep the warehouse as your canonical source. That way you can stop wasting time reconciling mismatched segments and focus on the campaigns themselves.

Back to the top ⬆️

Doing Work You Actually Enjoy Without Burning Out

Hope doesn’t chase balance. She builds a life where work is one of the things that feeds her, not something she has to recover from. She’s been in jobs that looked great on paper, the kind with nice titles and solid paychecks, but where she felt boxed in, micromanaged, or constantly annoyed. She did them anyway, because they served a purpose. She earned her MBA that way. But she never confused those stints with being happy.

At SoundCloud, she’s wired into multiple worlds. She’s product, but also performance marketing. She reads like a machine, keeps tabs on what Google breaks next, and thinks across systems without needing everything to be perfect. She likes context. She likes pulling threads from different teams and seeing what happens when they cross. That’s not multitasking for the sake of busyness. It’s curiosity with teeth.

“I like seeing how everything comes together. That makes me happy.”

She reads fiction like other people binge TikTok. Not serious nonfiction, not productivity manuals, but messier stuff. Romances from the 90s. Throwaway thrillers. Stories with emotional messiness and no pretense. That’s the point. The brain needs outlets that don’t come with dashboards or Slack pings. She lets herself get lost in them, often late into the night, and doesn’t apologize for it.

The trap for most operators is assuming that energy always has to come from breaks or resets. Sometimes it comes from doing work you care about, in a place that leaves you alone when you’re doing it well. Hope’s not obsessed with productivity hacks or pretending to read The Economist. She’s into DSPs and trashy novels. That blend works for her. It keeps her sharp, grounded, and genuinely interested in her day.

Key takeaway: Energy doesn’t come from finding balance. It comes from building a system around your real interests. Say yes to work that energizes you, across functions and disciplines. Let yourself be a generalist. Let yourself enjoy stuff that isn’t impressive. Drop the performative productivity habits. Stay interested, not optimized. That’s how you build a career that lasts longer than your current to-do list.

Back to the top ⬆️

Episode Recap

Twelve weeks. Three people. A stack that was gathering dust. Hope inherited seven years of quiet workarounds that had stopped working. The contract on the old messaging platform was ending in January, and the team couldn’t kick the can any further. They had to rebuild everything. Fast.

Instead of just copying everything to the new tool, they opened a spreadsheet and scored all 200 campaigns by usefulness. Most of it got scrapped. If it didn’t drive value, it didn’t make it. They partnered with MoEngage to rebuild the technical bits so Hope’s team could focus on what the messages should actually do. The goal was a stack they could understand again.

Every decision came from necessity. The old platform couldn’t tell them how many messages went out or what triggered them. Support calls always circled back to the same line: “That’s a custom implementation.” Which meant no one could fix it. And nothing new would ever ship first. Out-of-the-box users got the roadmap. Hope’s team got silence.

She’d seen enough of that at CNN. Legacy platforms age quietly. Features go stale. Teams bend around them until they’re not platforms anymore, they’re sand traps. So she looked for a partner who had done hard things before. MoEngage didn’t flinch at the timeline. They brought a real plan to the call. No sales patter. Just clarity.

SoundCloud treats martech like a product. Not a marketing promotional feature. That structure changed everything. Messaging moved into product. It stopped being a handoff and started being a feature. A push alert was part of the experience. Hope’s team sat inside the product org, right next to engineers and designers. They shipped messaging flows like they shipped app updates. Fast, thoughtful, tied to behavior.

Even governance got easier. Anyone at SoundCloud could now draft a message. But only lifecycle could send it. That meant more ideas, more speed, no chaos. Data stayed clean too, warehouse-native style. Everything ran through BigQuery. Audiences lived there, versioned like code, not duplicated across five platforms. Reverse ETL pushed those segments where they needed to go.

The migration gave them a working system. The restructure gave them a better one. No more praying that a segment meant the same thing in three places. No more guessing. Just a team, a tool, and a structure that actually made sense, thanks to a massive migration that was accomplished incredibly well and fast.

Listen to the full episode ⬇️ or Back to the top ⬆️

Follow Hope 👇

• LinkedIn

✌️

—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

Related tags

See all episodes

Future-proofing the humans behind the tech

Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS

• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed