How to Manage Marketing Operations in Agile Sprints
Marketers know the challenge all too well of showing up to work and a new lead from a small, San Francisco based firm has been incorrectly routed to the account executive responsible for mid-market in New York City. Before the rogue lead can brew distrust from the sales team in their CRM, you are investigating if this is an isolated incident or if there’s a larger pattern.
Sometimes it’s both: to run automation at scale, there is seldom 100% accuracy in the methods when thousands of new people and companies enter the databases each day. There is always a fraction of marketing ops under construction, which means some portion is underperforming.
How do we move progress forward when we feel like we’re triaging to gain trust?
With experience from SaaS startups to an enterprise, here’s how I’ve managed it with teams time and time again:
understanding marketing ops challenges
getting started with agile
measuring and communicating results
Plus, some humbling confessions along the way.
Challenges
Marketing operations is about ensuring that when someone asks to learn more about your product, their inquiry ends up with the right person.
That is the job to be done, yet the paths to get there are numerous.
People can inquire through your website for sales or support information. They can attend an event and speak with you at your booth. They can download an eBook, which tips you off that they’re learning, but you’re left guessing when (or even if) they’ll be ready and willing to buy.
Each of the above scenarios could be owned by a different person on your marketing team. Email marketers, field marketers, and campaign managers all use the marketing automation tools to send customer emails, track event registrations, and pass that information to sales for outreach.
As you can see, these responsibilities are owned by other roles and each person’s influence varies. I find the best way to tell who is most responsible for the platform is to look at the scenario I introduced at the start of this piece: When something fails, who on your team is expected to diagnose it?
Which signifies the first challenge, these responsibilities can be owned by others roles, but also that titles vary for the same set of work.
Marketing operations, campaigns manager, CRM manager, and product marketing can all be expected to own the automation of the marketing team’s work and results. I’m originally from the Boston area, where product marketing owns more of the sales enablement side, such as sales materials and messaging, as well as the marketing automation to CRM integration. In San Francisco, product marketing owns research and messaging, and leaves any automation to the dedicated marketing ops person or team.
The biggest challenge I see by far, as illuminated by the original story, is that people mistake the cause of mistakes to be an individual's action, instead of the root being a poor process.
Marketing operations can use sprint planning to repair a poor process. These are the areas that discipline owns:
Lead qualification
Lead scoring
Lead routing
Email sending
Email tracking
Analytics
Integrations with CRM
Integrations with tools for SMS, direct mail, in-app notifications, social media, the list goes on for infinity
The Benefits of Agile
Agile methods focus on aggregating ideas from the team, prioritizing them to be finished within a set time frame (sprint), and then collecting feedback after each sprint to improve process. At it’s core, it’s meant to democratize ideation and suggestions, build a better project management process by feedback loops, and have grounds to say “no” when surprise projects threaten your team’s productivity.
Change management of moving to agile can be a game of “who moved my cheese,” where most of the team is more concerned about the change itself than what the actual work entails. Here are the benefits to making the investment in time and energy to adopt agile:
Your team will have a baseline measure of productivity
In a 2-week period, do you know just how much work your team accomplishes? The first few weeks of agile are to help quantify when things feel busy, productive, or sluggish.It creates a paper trail of deadline adherence vs interference
When faced with a leader who makes last-minute requests, it can be tough to say “no” without the data to back it up. Being able to point to projects to say “this got delayed by X days because we had this new request mid-sprint” helps take the focus away from blame and places it on productivity.Quantify if prioritized tasks are given time and attention
Sometimes the loud stakeholder (also known as a squeaky wheel,) even if their project’s not revenue-generating or goal-aligned, gets the team’s attention. Sprint planning helps take the blame off the culprit, gives the team space to identify interference or delays, and focuses on laddering up sprints to larger goals.Impact-driven
Without new processes, people repeat the same mistakes. If you want to minimize surprises from sales upon entering the office, this is one way to do it. It also means that when those urgent tasks come up, you can measure how often they do, and hopefully measure over time, as your processes improve, that they come up less (or at least more predictably.)People begin enforcing the guidelines among themselves
The early adopters will make a habit of the new way of doing things, and will soon encourage their coworkers to do the same by asking questions: “Hey, I see this piece of information is missing, can you fill it in?” sometimes the best way to learn is by making mistakes in an environment where it’s encourage to learn from them.Share results!
Lunch & learns work effectively to demonstrate the behind the scenes success. It also communicates the why and how to the rest of the team, who is usually blissfully unaware of all the guardrails and teamwork it takes to make a marketing automation machine run smoothly.
Getting Started with Agile
If your marketing team has never used this method before, and you’re interested in implementing it, here are 4 perspectives to leverage and a bonus confession:
1. Manage Up
Advocates
The benefit: The leadership within and above the marketing group will know, if not advocate, for marketing adopting a framework that’s been used by engineering for a minute. They can also be bad cop if the team is resistant (“I know it’s annoying, but the CMO insisted we try it.”)
The risk: They’ll think it’s a waste of time themselves and set the example for the naysayers on the team to adopt it.
Goal setting
The benefit: Agile sprints ladder up to monthly, quarterly, and annual goals, which is something Directors and above often lead.
The risk: Without connecting the short-term goals to the long-term goals, these productivity exercises will happen independent of company value, and be seen as cosmetic changes.
Expectations
The benefit: Set clear expectations that this change could take 1 month, 1 quarter, or 1 year to fully adopt.
The risk: Leaders expect results too early, and divest (either their attention or budgets) when there is sunk cost but not yet ROI.
2. Managing down and around
Define the stakeholders who will lead process, monitor use of the project management tool, and collect the team’s feedback. I recommend approximately 1 designated leader per 10 team members.
The benefit: Soliciting feedback during a retrospective at the end of the sprint will allow everyone to hear the collective input. Real-time feedback is important if you see data entered incorrectly in your project management system, so best to review daily to help people course correct before they develop unintended habits.
The risk: Without a driver of the change, the new process will not gain momentum. Without a retrospective, your peers will pepper you with questions, complaints, and suggestions all day, interrupting your work.
Recognize the adoption curve will vary by person
The benefit: The perspective that the resistance is often more about change than it is about the process itself. Once people get started, they’ll be comfortable with the new way so long as they feel that they have a voice in the process.
The risk: Assuming everyone will be proficient in week one and losing confidence in the team when it takes longer (it will take longer!)
3. Select your tech wisely
Software in this category include things like Asana, Wrike, Workfront, Robohead. Even Airtable can be templatized for project management purposes.
The lower the cost, less pressure to prove out
Benefit: The team’s process matters more than the tech you use, but best to introduce both at the same time. If budget gets cut for another reason, it means your process is less likely to be impacted.
Risk: If there are too many features, and there are cost-cutters above you, they may view it as a “feature tax”, not something you’ll grow into, and want to cut what they consider bloated software and its costs (without much consideration for the time costs of change management, which are plenty.)
Identify the need to have vs. nice to have features
Benefit: This helps remedy for the above challenge. If your team needs time trackers for client work, the ability for non-users to view (such as legal reviewing your email), or an intake form to standardize requests, make note of the must-have features. G2Crowd, Capterra, and recommendations from industry peers to identify solutions are a great place to start.
Risk: Skipping this step would leave you with an under-resourced solution, a bloated product prime for cost-cutting evaluations, or something the team finds difficult to use.
4. Documentation
Standardize what you expect your team to do so they can follow instructions and build new habits.
Outline task requirements
Benefit: An instruction guide with what details to include for each type of ask (banner ads might need dimensions, emails might need copy limits) as well as timelines will help your team get the info they need from each other at the start, plus set expectations on how much time to allocate per deliverable.
The risk: Without this written down, it turns into a game of telephone and a lot of transactive knowledge can go missing if someone leaves the company (or just takes a day of work off.)
Implement intake forms
Benefit: These forms often have conditional fields based on the task requested. Using the same example as above, if someone selects “paid ads” as the asset they’re requesting from design, a field might pop up to enter “dimensions.” However, if they choose email, they’ll instead see a text box to enter their proposed copy, with the suggestion it be shorter than 200 words.
Risk: Humans have better things to think about than what dimensions their designer is going to need, so why not help them avoid that awkward follow-up a few days later when their colleague finally answers their incomplete request? Forms help minimize those oversights.
At the retrospective, dedicate at last 25% of the time towards feedback. Write it down in a shared document.
Benefit: Everyone feels heard, knows if their request was already said, and can put some of the suggestions in motion during the next sprint.
Risk: Without feedback loops, it defeats one of the tenets of agile to encourage team participation and involvement. Your Slack and email will also be much more crowded with suggestions and questions from colleagues when they face uncertainty with the change.
With these tools, you’re better equipped to create successful change management and not repeat my mistakes.
Ready for the confession?
I worked on a team that changed systems 3X within 2 years. We struggled with leadership buy in outside of our immediate team and less than a year into implementing the tool the team had become proficient in, it was cut for budgeting.
Not only did the marketing group have to learn a new process all over again, now with an inferior system, so did the legal department. Changes in cross-functional teams have ripple effects through other departments. Agile can help measure costs of switching when you know how long it took to adopt one system.