Hundreds of systems, too many manual processes, and a marketing backlog that never seems to get smaller. Sound familiar?
A few weeks ago, I sat down with Kelli Johnston from Amazon Music’s design organization at MOPZA to talk about rethinking marketing operations in the age of agents.
Kelli leads a team of five non-technical PMs who own systems, tooling, automation, enablement, and training for design and its partner teams, with no dedicated engineering support.
A familiar problem at an unexpected scale
Kelli’s first point surprised me. Amazon Music operates like a startup, with the same resource constraints as everyone else. The issue isn’t scale; it’s volume.
As Kelli put it, “We have resources, but we also have a lot of scale that those resources are dedicated to.” The business moves fast, and like most organizations, every team fights for engineering prioritization.
Their backlog came from all the familiar places. The team works across hundreds of disparate systems, and rapid growth in 2021 and 2022 left no time to standardize how people work. Even the asset management system is just folders with no metadata or consistent structure, so there is no data on how people search for and use assets.
Solving these common problems never seems easy at first glance. Traditional implementations can take years, require significant engineering resources, and still fall short of what Kelli’s team actually needs.
And with technology changing so quickly, Kelli started questioning whether the solutions they'd been working toward were still the right ones.
From working around systems to working differently
What struck me about Kelli's story wasn't just how much her team was juggling. It was her willingness to question the way they'd been solving those problems in the first place.
With AI changing what's possible, the old playbook of lengthy implementations, rigid systems, and workarounds no longer made sense. And for Kelli, that meant reconsidering some big investments, getting new methods into people's workflows, and finding ways to give designers more time for the work they actually love.
This is how they ditched the old marketing methodologies and changed their approach:
Build-vs-buy flipped
Instead of relying on years-long legacy implementations or internal builds, Kelli’s team works with Gradial to put a prototype in front of users in weeks. If it doesn’t work, they move on. Letting go of four weeks of work is easier than letting go of two years. In fact, Kelli's team is reconsidering a project they've already spent two years building in favor of something faster and more AI-forward.
Demos beat documents
Kelli’s stakeholders are designers, and designers need to see something. Requirements docs don’t land; a prototype does. Feedback that used to feel like pulling teeth now flows.
Automation freed people to grow
At Amazon Music, production teams create more than 1,000 creative assets every week. Many follow standardized templates. Some are used for just a week and may never be seen again. It's important work, but it doesn't always give designers the opportunity to exercise their creative skills. Automation is changing that and giving capacity back to the team.
In Kelli's words:
“With just the little bit of automation…they've been able to learn new design tasks. They came in as static designers. They're now learning motion design because that's the way the business is going.”
And the opportunity goes beyond learning a new skill. Kelli described it as “allowing people to grow and expand and do higher complexity, higher visibility, higher impact work and saying, hey, maybe you don't need to actually copy/paste this template anymore.”
Other designers saw their colleagues taking on more interesting work and started asking, “What does that mean for me? What can I do with that?” That was the turning point for the broader organization.
Why a marketing harness matters
Kelli described the relief of not evaluating a million LLMs or having ten people vibe-coding different solutions. For the group, I defined the term marketing harness, which comes from the coding world and means the platform around the agent. It carries your context (DAM taxonomy, naming conventions, brand guidelines), connects to your systems, and works across models, so you aren’t juggling seven point-solution agents. As Kelli noted, you can vibe-code anything, but the harder question is whether you should.
Tangible takeaways
Start with the pain your team hates most. Solve it, show the value, and earn buy-in for the next problem.
Think system-agnostically. Define the ideal solution before asking what a tool can do.
Show, don’t tell. Prototypes and sandboxes teach faster than documents. Get people hands-on early.
Use early builds to learn how people work. A quick build is a good way to gather missing usage data.
Redesign the process, not just the stack. Agents are becoming coworkers, so they belong in a system of work, not just your tech stack.
Be willing to let go. If a system you’ve invested in for years no longer fits, move on.
Automate the template, then plan for the freed capacity. Decide where the bandwidth goes: motion, video, more complex design.
Don’t make people fit the tool. Ask how users want to work, then build toward them.
The final_final point
The throughline is simple: start with your pain, your business problem, and the possibility in front of you. The tools finally make it realistic to build for how your people actually work, instead of asking them to adapt to the system. Because the real payoff isn't just getting through the backlog faster. It's what your people can do when they're no longer buried under it.
Thank you to Kelli, for your candor, and to everyone at MOPZA. If you’re wondering where your biggest pain point sits, give me a shout.