Your impact is no longer just a function of your own ideas and contributions. It now relies on how well your team performs.

This can be a huge opportunity to scale your impact, but it can also lead to frustration and failure. Your ability to deliver swift and effective feedback might be the difference between those two outcomes.

I started managing people 13 years ago. I was in my 20s and not at all prepared for the experience. I constantly felt torn between managing my team and doing my own work (a common issue for first-time managers). Ultimately, when I moved into consulting and returned to being an IC, it was a relief.

It was a few years before I felt ready to lead again, and when I did, I tried to be very intentional about how to deliver impact through my team—by enabling them to do their best work and to continually level up.

So consider the ideas in this post and the accompanying video to be hard-won lessons. I’m not a leadership guru, but I have seen what works.

Why feedback is hard

Constructive feedback is inherently a form of criticism, and that can feel uncomfortable. You don’t know how the other person will react—will they get mad? Will they quit? Is it even worth the risk?

Given poorly, feedback can leave someone feeling resentful or demotivated. Given inconsistently, it may not be effective. Many managers simply avoid giving it until there’s a significant problem.

But not giving feedback is its own kind of failure.

It’s a lot like exercise: at first, it feels unnatural. Natural inertia and laziness fight against you. But the only way forward is to push through, do it consistently, and make it part of your routine. Eventually, it stops feeling painful and starts feeling necessary.

Great feedback isn’t about how you handle occasional performance reviews or tough conversations. It’s about creating a culture where small, frequent, and constructive course corrections drive continuous improvement. The goal is to get 1% better every day.

The importance of trust

The most important part of giving feedback isn’t in the delivery. It’s the foundation you’ve built with the person receiving it.

Your ability to give impactful feedback is directly tied to the trust you’ve established.

People need to believe, on a fundamental level, that you’re on their side, rooting for them to succeed. This creates a willingness to listen, to internalize feedback, and to act on it. Without that trust, even the most well-intentioned feedback can feel like an attack. You may get lip service, but not a real paradigm shift.

Trust is built in the small moments: how you interact with your team daily, how you recognize their wins, and how you define your relationship with them from the outset.

Be a coach, not a manager

Where I work, they use the term “coach” rather than “manager” or “leader.” I like this term because it suggests a healthy dynamic for giving feedback.

If we think about the player-coach relationship, the coach has one job: help the player succeed. If the player succeeds, the coach wins and the team wins.

But a coach doesn’t wait until the end of the season to give feedback. They give it constantly, in real time, in small doses. They support, but they also push and hold players accountable.

Framing feedback as coaching removes tension and normalizes it. It’s not about pointing out mistakes—it’s about enabling continuous improvement.

I try to define this relationship starting from the interview process itself. This immediately sets expectations for what the coaching experience will be like and validates that the person is able to receive feedback.

Give feedback fast and often

One of the biggest mistakes leaders make is waiting too long to give feedback. If you’re only doing it during performance reviews (or when there’s a huge problem), you’re setting people up for failure.

Feedback should be:

• Fast: Ideally, the same day you notice something worth commenting on.

• Frequent: At minimum, every week.

• Small: Delivered in bite-sized pieces rather than overwhelming, high-stakes conversations.

Why does this work?

It’s easier to give and receive

A single critical comment in isolation can feel like an attack. But a steady rhythm of feedback, both positive and constructive, makes it a normal part of how you work together.

Small nudges keep people on track

Imagine a large cruise liner drifting off course. At first, the deviation is small. But over time, it compounds, and suddenly, the ship is miles off track. Correcting that is now a BIG problem.

Now imagine someone making tiny course corrections along the way. Those nudges are nearly imperceptible and effortless, but the ship stays on course without any fuss.

This is the power of giving feedback fast and often.

Consider the example of how marketing leader Thao Ngo gives feedback. In this clip (from Episode #29) she describes how to give quick corrections in the flow of work. It’s no coincidence Thao’s LinkedIn profile is flush with recommendations from people who have been on her team.

You don’t blindside people

At my first “real” job, I learned what bad feedback feels like.

I was young and eager and excited to be working in an office. For three months, I received nothing but positive reinforcement. Then, at my 90-day probationary review, I was blindsided with negative feedback.

Beyond the feedback itself, I felt betrayed. Why hadn’t my manager mentioned this sooner?

Since then, I’ve adopted a no surprises policy. If something’s an issue, I raise it immediately, before it festers.

Any feedback in performance reviews should just reiterate topics already discussed on a regular basis.

The One-on-One Doc: A Simple System for Better Feedback

One of the most practical ways I’ve seen to implement this is through a shared one-on-one doc.

It’s a simple setup: each week has a heading, and we list discussion topics. Any feedback (positive or constructive) gets documented, even if we already talked about it.

Why? Because writing it down:

1. Ensures clarity: Sometimes people don’t fully hear or understand verbal feedback. Writing it down gives them a second chance to process it.

2. Creates a record: At performance review time, you don’t have to rely on memory; you can search the doc for everything discussed.

3. Demonstrates consistency: If there’s ever a performance management issue, you have clear proof that feedback has been given regularly, not just when things escalate.

Celebrate Wins

A big part of showing people you’re invested in their success is enthusiastically celebrating their wins, with no strings attached.

I say “no strings attached” because because too often, praise is a setup for criticism. The classic feedback “sandwich” (positive, negative, positive) makes people feel that praise is only used to soften a blow, which seems disingenuous.

However, when you call out positive things frequently and for their own sake, people feel encouraged and recognized.

From a practical perspective, it’s also a great way of encouraging the person to repeat that positive behavior. If you want more of something, celebrate it.

The Bottom Line

At the end of the day, feedback isn’t just about correcting issues—it’s about creating an environment where people can do their best work.

Done right, it builds trust, drives continuous improvement, and keeps small things from turning into big problems.

It doesn’t require complicated frameworks or difficult conversations. Just a commitment to small, frequent, and thoughtful feedback and a real care for your team’s success.

After my recent chat with Scott Brinker, I’ve been delving deep into the world of agentic AI.

I try to avoid excessive hype around these topics, but it really hit me that agents are how AI will deliver radical business transformation.

Generative AI has already reshaped how we work—personally, I’ve replaced 95% of my internet searches with LLM chats. Yet, if LLMs disappeared tomorrow, I suspect most businesses, including SaaS companies, would still continue operating as usual.

I believe we’ll only see a truly disruptive impact from AI—and a dramatic reshaping of the workforce—when the following conditions have been met:

• We identify the right type of labor that AI should replace

• We enable AI to access the necessary tools to fulfill those tasks

• We have the frameworks / platforms / expertise to easily make these AI-driven processes a reality

These three pillars define the foundation for agentic AI to move beyond hype and into meaningful operational change.

In this article I share some early thoughts as well as resources I’ve been exploring. I don’t claim mastery of this topic, but hopefully you can come along on the journey or contribute resources you’ve found helpful.

What is agentic AI?

While there’s no universally accepted definition of “agentic AI,” most experts agree on two core elements:

• A Large Language Model (LLM)

• Automated or autonomous execution

For Scott Brinker, the defining characteristic of agentic AI is tool use—that is, the ability for the AI to take action in other connected systems, either via APIs or manipulation of human interfaces.

Cobus Greyling similarly distinguishes between LLMs, which generate media in response to user prompts, and Large Action Models (LAMs), which “make real-time decisions based on tools at [their] disposal, [including] API’s and other integrations.”

For the purposes of this post, I’ll follow the more expansive definition provided by Anthropic in their research paper Building effective agents.

They define two types of agentic AI—workflows and agents—based on how they handle decision-making and tool usage.

Some customers define agents as fully autonomous systems that operate independently over extended periods […]. Others use the term to describe more prescriptive implementations that follow predefined workflows. At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents:

• Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

• Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

I think this broader definition is useful, because:

• In practice, vendors are using the term “AI agents” very loosely. This level of precision offers a vocabulary to distinguish various applications.

• Finer distinctions enable operators and system architects to chose the correct design pattern for their application.

Why many first-wave AI applications fall short

Many current implementations fall short of their potential because they focus on single-step tasks rather than full-process orchestration.

A few examples of what I mean below.

Prompt-based builders

Many platforms now offer chat-based interfaces for building assets as an alternative to traditional UIs. Instead of using clicks to build out your workflow/campaign/whatever inside the platform, you use a prompt.

Perhaps analytics show great results from these features, but I’d be surprised. I think this paradigm suffers from two fundamental flaws:

• The outputs of these prompt interfaces are usually not precise or complete enough to deploy to production without the assistance of experts. So they don’t enable true independence.

• Tasks often span multiple systems. (For example, an email campaign may require configuration in Marketo, Salesforce, etc.) A human expert is still needed to stitch everything together.

• Unless the volume of assets is significant, a truly proficient user probably won’t save much time by chatting, as they have already mastered the existing UI.

Example: 

Zapier introduced a chat-based interface for creating Zaps. It's cool, but the initial output is still relatively imprecise and requires additional configuration. 

As a proficient platform user, it doesn't really save me time. I'd rather just retain control and build from scratch. 

These “build via chat” implementations often seem like solutions in search of a problem.

AI content

In Scott Brinker’s and Frans Riemersma’s recent report, Martech for 2025, they surveyed nearly 300 marketers on how they’re using AI today.

Five of the top ten applications—and three of the top five applications—are related to content.

Obviously marketers are finding AI useful for content creation. What’s the problem?

My concern here is that some marketers are using AI to optimize for the wrong things—focusing on content creation velocity vs. content quality.

I’m not suggesting AI has no place in content. I often use AI as a thought partner for refining ideas or coming up with first drafts for technical or descriptive content like podcast show notes. I used AI to copyedit this article.

The issue arises when people rely on AI to draft LinkedIn posts or articles that should convey authentic human thought. When it comes to content, the currency is authenticity and original insight—precisely the things that AI lacks and is definitionally incapable of producing.

On the other hand, process-driven tasks are ripe for agentic workflows that automate without sacrificing creativity.

So how do we identify valuable applications for agentic AI?

We first need to describe the type of labor AI is best suited to replace.

• The work follows a structured and predictable process

• It requires human-style evaluation and decision-making within component steps

• The output has a low requirement for originality or uniquely human contributions (e.g., intuitive leaps, novel insights)

• The output has a high requirement for consistency and conscientiousness

These criteria describe a middle-ground between purely deterministic workflows (that can be fully automated with existing iPaaS-type tools today) and tasks that are highly dependent on creativity, originality, and unique perceptions such as strategy development or thought-leadership.

These middle-tier tasks often demand significant skilled labor but could be largely automated by AI.

Practical Use Cases for RevOps

Considering my own field of revenue operations, I can see many types of work that fit this description. These are just a few.

(Note: most of these use cases are still speculative, NOT things I’ve rolled out in production. But they should be theoretically possible with tools we have today.)

Campaign Operations Agent

I estimate that somewhere between 25-50% of marketing operations resources are allocated to campaign building.

A campaign ops agent team could execute across multiple systems, interacting with users to adapt requirements for individual campaigns, and manipulating GUIs where system APIs fall short.

Lead Management Agent

Many teams have complex rules-based routing systems—but they will never be perfect, because the underlying data is never perfect, and require manual human review.

An agent could flag cases where human intuition currently compensates for rules-based system gaps, such as:

• Leads misrouted due to mismatched address data

• False negatives (e.g., due to email domain variation), where a lead that seems to be from a small company is actually related to a large account

• etc.

Data Quality Agent

Rules-based data tools, even those with “fuzzy” matching logic, can still leave a lot of gaps. Many ops teams spend hours manually fighting bad data.

An AI agent could perform that next level of review—evaluating and merging suspected dupes, normalizing address data, updating parent-child account hierarchies, resolving conflicts around company size between different enrichment tools, and so on.

Reporting and Analytics Agent

Ops teams spend a huge amount of time producing reports that go unread and have no impact. An AI agent can perform the first level of analysis, calling out insights and trends that a human should pay closer attention to.

My friend Grant Grigorian is building a platform that does exactly this.

Ad Operations

Performance marketing agency NewForm created their own agent for ad operations.

This agent builds reports, detects issues/opportunities, and proactively makes changes in different platforms to address them.

They estimate they’ve saved 90 hours per week—that’s over 2 FTEs!

Content Operations

While I believe the heart of content should remain uniquely human, there is a huge amount of labor surrounding the production of content that is ripe for AI replacement.

For example, producing my podcast involves:

• Editing the episode

• Creating a title

• Creating thumbnail graphics

• Inserting the graphic and intro sound file into the podcast

• Inserting ads at relevant points (if the episode is sponsored)

• Creating show notes

• Publishing the audio file to podcast networks

• Publishing the video file to YouTube

• and so on…

It can take 5-10 hours per episode easily.

I use in-platform AI tools in various ways at each step of that process, but there is no single tool to execute the entire workflow. But potentially an agent could, while keeping the human in the loop for important decisions.

Learning resources

These resources are a great starting point for building your understanding of agentic AI and how it can transform operational processes. In future posts, I’ll share more insights from my own implementation journey.

Overviews and Architecture

• AI agents are the new iPaaS and the next frontier of intense competition in digital ops orchestration - Scott Brinker

• Building effective agents - Anthropic

• The Rise Of AI Agents And Agentic Reasoning - Andrew Ng, Snowflake BUILD 2024 Keynote

Agentic AI Examples

• Building AI Agents for Marketing - NewForm

• 112: Stephen Stouffer: The dawn of AI Ops and the practical wonders of combining AI tools with iPaaS - Humans of Martech

• Research a contact using AI workflow - Kyle Coleman

Courses

• Introduction to AI Agents - DAIR.ai (I took this paid course, and it was $39 very well spent. You will walk away with first-hand experience building multi-agent systems in Flowise.)

Platforms and Frameworks

• Flowise - Open source / low-code AI app and agent builder

• Relevance AI - No-code and looks very easy to use

• CrewAI - No-code UI and development framework for multi-agent automation

• Tray.ai - iPaaS tool that is leaning into AI in a significant way

• Make - another automation tool with AI capabilities

  ---

Introduction

Reporting is one of those critical elements of business infrastructure that often goes unnoticed until something goes wrong.

When it works seamlessly, business users tend to assume everything comes together like magic—much like how we expect light when we flip a switch or water when we turn on a tap.

But when reporting doesn’t meet expectations...well, we’ve all been there.

Unfortunately, there’s no easy mode for building robust reporting capabilities. While AI might alleviate some of the pain over time, there will always be a need for good planning, careful stewardship, and a bit of grit.

I began writing an article to consolidate some frameworks and routines that I’ve found useful. However, I quickly realized it would be far too long and time-consuming for a single piece.

So, in an effort to resist my tendency towards monolithic and comprehensive posts, I've decided to break this into a multi-part series. It’s probably for the best.

This series will primarily focus on scale-up stage companies, which is my area of expertise.

Note, I recently appeared on Beyond the Pipeline with Vivin Vergis, whose questions helped me distill some of this content. He’s a great host—check it out:

Roadmap

It’s still hypothetical, but here is roughly how I see this series playing out over time.

I’d love feedback on other topics you’d find interesting or useful.

• Reporting Workstreams (today’s post)

• Reporting Systems and the Single Source of Truth

• Dashboard Development Process

• Defining, Modelling, and Documenting Your Data

• Data Culture and Communication

• Common Challenges

On to today’s topic.

GTM Reporting Workstreams

Not every report or dashboard is created equal.

There are various types of reporting needs, each with implications for how and where you build them, the level of data quality required, and prioritization.

Keeping these distinctions clear brings order and structure to your reporting universe.

Core Operating Reports

These reports contain the primary business KPIs for each function (e.g., funnel metrics, channel performance, new bookings, churn, sales forecast, etc.).

These metrics reflect each team’s core accountabilities and how the business is managed.

Audience

• Company wide, manager and executive level.

• Every relevant person should know that a particular dashboard is the source of truth for a specific KPI.

Design

• Clear and simple, foregrounding the most important information and free of extraneous detail.

• Aside from filters on time range or market, they offer limited interactivity. You want each stakeholder to see the same thing.

Maturity

• These reports are mature and should be viewed as a trusted source of truth.

• They provide consistency and stability, delivering reliable insights each time. They are relatively slow to change.

Data Quality

• The tolerance for data discrepancies or errors is very low.

• The underlying data should be kept pristine. Definitions are very well-documented.

• Mature processes for governing and cleaning this data are essential.

Development

• These core operating dashboards are managed like a product, either by RevOps or the data team, depending on org structure.

• They evolve iteratively based on business needs and feature requests.

Reporting Environment

• Most early-stage businesses will start off building these reports in CRM.

• However, past a certain inflection point, CRM capabilities may be exceeded.

• For example, integrating targets into CRM reporting can be challenging, but targets vs. actuals should be a fundamental view in operational reports.

• For this reason, core operating reports are best built in a BI tool connected to your warehouse.

Performance Management Reports

Unlike core operating reports, which focus on a consistent set of KPIs that are intrinsically important to the business, performance management reports address issues in the revenue engine. They delve into the underlying causes of changes in your primary KPIs and are typically focused a few levels deeper in your KPI tree.

These reports aim to provide answers to specific questions, like

• Why is conversion dropping for our organic handraisers WoW?

• What’s contributing to a slower SLA for our SDR team in the US market?

• How many demo requests don’t have a meeting booked and require follow up?

Audience

• These reports are designed to enable functional team members to troubleshoot and manage their part of the business.

• They are typically more granular and detailed than core operational reports, which have cross-functional audiences.

Design

• It’s impossible to pre-build every report to answer every question, so these reports should be flexible and filterable.

• They need to enable functional owners to drill, filter, and pivot by whatever dimensions they care about to answer questions based on the needs of the moment.

Maturity

• These reports tend to have a spectrum of maturity.

• For established channels and business functions, there is likely to be a well-defined process for troubleshooting and analyzing the business, with mature reporting interfaces.

• Reporting for newer business activities may be more ad-hoc, only becoming crystallized as the business process matures.

Data Quality

• Data still needs to be clean enough to drive accurate decision-making, but the acceptable margin of error is slightly larger.

• More mature reports will have greater data quality, whereas newer areas of investigation may rely on less certain data.

Development

• Mature reports should be productized, similar to core operating reports.

• Ad-hoc reporting requests should be prioritized based on ease of development and business impact.

Reporting Environment

• Typically these reports begin in an ad-hoc way, e.g., “I wonder how much of x is y,” etc. You don’t initially know whether that question is useful, so you want to build the report as quickly and easily as possible. Typically this means doing a v1 in a source system like Salesforce, unless the data has already been operationalized inside a BI tool that makes it easy to explore.

• Once a report becomes “established” as part of a team’s optimization and troubleshooting methodology, it makes more sense to formalize it in a BI tool, where you can add more powerful filtering and drilling capabilities or integrate additional datasets.

Innovation / Ad-hoc Reporting

These reporting requests are usually exploratory in nature—evaluating “what if” scenarios or new ideas.

For example, they could be aimed at identifying the most valuable segments or markets, testing a hypothesis, evaluating opportunities, etc.

Audience

• Varies from individual contributors optimizing a specific channel to executive-level audiences developing business strategy.

Design

• Generally more simple and focused on answering a specific question—e.g., “Should we expand into the ANZ market? Let’s review how many hand-raisers we’ve had in the past 12 months and whether any of them became opportunities.

Maturity

• By their nature, these reports are answering new business questions and tend to be immature.

Data Quality

• Because this analysis is new, the data typically won’t be perfect. The insights here are typically directional rather than absolute.

• Either the source fields may not be clean, or the data may only be available in a sub-optimal format (a concatenated or overwritten field, for example).

• It’s not wise to invest too much time in producing perfect data when the report may not be useful in the long-term. Instead, get comfortable delivering the report with caveats (this is missing, this is approximate, this may lack fidelity, etc.).

• Your stakeholders will usually understand, and if the data is truly useful in that state, you can then feel more confident prioritizing additional effort to clean it up.

Development

• Depending on the availability of the underlying data, developing these reports can be expensive and time consuming.

• Also, the long-term usefulness of ad-hoc reporting is unknown.

• So it’s important for the team responsible to vet these requests carefully, interrogate the potential for impact, and prioritize them accordingly.

• Prioritize a quick-and-dirty v1 over something perfect.

Reporting Environment

• Because it’s far from certain this analysis is useful on an ongoing basis, focus on building a v1 as quickly and cheaply as possible.

• Typically this means doing it in source systems like CRM where possible, unless the data has already been operationalized inside a BI tool that makes it easy to explore.

Share RevOps FM

Give a gift subscription

A friend of mine asked what a 90-day plan for a newly-hired RevOps leader would look like. The right plan is going to be very different depending on the company size and context, but I thought it would be interesting to flesh out my thoughts and share with you all. It’s a good exercise in prioritization.

Objective

As a newly-hired RevOps leader, create a plan for the first 90 days of your tenure.

Company context

Hypothetical assumptions for the purpose of the exercise:

• Early-stage scale-up, about 80-100 employees

• Approximately $25-$30M ARR

• Blended PLG / sales-led motion

• Strong product-market fit and growth

• Strong GTM functional leaders in place

• Tech stack: Salesforce, Hubspot, Chili Piper, Gong, etc.

• No existing RevOps team. Tasks are handled ad-hoc by GTM functions with a small amount of agency support. So assume a relatively blank slate.

Guiding principles

In tackling a problem like this, here are a few key principles I’d keep in mind.

• Embrace the chaos: Your job is to work towards order, but things will be messy and imperfect for a while. That’s OK.

• Focus on revenue impact: You need to build for the future while driving the biggest impact today. Aim for quick wins and direct influence on revenue.

• Be realistic: It can be tempting to run straight towards your ideal state. But it’s dangerous to bite off more than you can chew. Start with what’s achievable and good enough, then lay plans for future improvements.

Key priorities

With all that said, let’s go on to the plan.

Days 0-30

Learning and onboarding

Starting at a new company gives a huge shock to the system. There are a thousand unspoken cultural norms and ways of working that will seem strange and unfamiliar.

You can’t stay in learning mode for too long, but take the first few weeks to acculturate, form relationships, and build a context-picture.

• Standard company onboarding

• 1-1s with GTM leaders and company execs

• Quick audit of existing systems

• Ride-alongs with SDRs, AEs, CSMs, etc. Get to know the process first hand.

• Review Gong calls.

• Review existing dashboards and reports.

Take copious notes during all of this. Your perception will never so fresh, and you’ll notice things that later on will become invisible.

Universal GTM reporting

In the absence of RevOps, it’s likely reporting is done ad-hoc by different teams, with each leader having their own reports with different numbers.

Without a common view of the world, teams aren’t fully aligned. And in the absence of revenue observability, the exec team has a harder time making good decisions and reacting nimbly.

So aligning the team around a universal set of executive-level GTM KPIs and reports is the first step. This is just a v1 and will surely evolve.

You should be able to pull these reports from CRM, while accepting data quality won’t be pristine.

There should be a weekly ritual to review this data as an executive team, discuss issues, and identify where action is needed. If this ritual doesn’t already exist, create one.

Get some professional help

At the current scale of our hypothetical company, it’s impossible for one RevOps person to do everything.

Plus, if you have no help, you’ll inevitably get pulled into a tactical / supporting mode and fail as a leader.

It’s too early at this stage to hire an FTE, so the best bet is support from an agency/contractor. They can help you run systems, troubleshoot, and take care of day-to-day issues while you put bigger building blocks in place.

Hypothetical-but-reasonable volume for this:

• 10 hrs / week to manage day-to-day support requests and issues from the field

• 10 hrs / week on new feature development and improvements in systems

Days 31-60

From this point, in the real world, you should ultimately be making prioritization decisions based on your KPIs. (This is the key to doing the right work.)

But for the purposes of our hypothetical plan, here’s a reasonable set of next steps.

Forecast accuracy

Job #1 for RevOps is to bring predictability and insight to the business. Without this, leaders can’t make good business decisions.

The biggest pain is usually the sales-led revenue and churn forecast. To bring this under control, we need:

• A structured pipe-cleaning process for reps to follow (expectations for updating close dates, amounts, next steps, etc.). For the renewal pipe, this would include measures of account health, escalations, etc.

• A coaching process to drive rep accountability, ensuring pipe gets reviewed weekly in rep-manager 1-1 meetings. As a RevOps leader, you also need to be applying scrutiny and creating a culture of rigour.

• An executive-level ritual to review the forecast in a weekly meeting and discuss significant changes. This ensures revenue leaders remain highly focused on keeping the pipe clean, actioning deals or customers at risk, etc.

Funnel Optimizations

Based on KPIs, call reviews, and ride-alongs, you should now have some sense of where the revenue process is most broken. And within those areas, there are hopefully some quick wins—usually related to increasing velocity and improving customer experience.

This is your chance to deliver quick revenue impact while you simultaneously build longer-term infrastructure. A few good options:

• Speed-to-lead: Improving response time for hand-raisers with a quick SLA.

• AE handoff: Automating the handoff process between SDRs/AEs using a calendar tool, so that prospects get to the demo as quickly as possible.

• New customer hand-off: Getting enterprise projects kicked off as quickly as possible and shrinking the time to value delivery.

Days 61-90

Funnel Optimizations

Continue your work on funnel optimization quick wins.

Roadmap

Plan your roadmap for the next 1-2 quarters, maximum.

At this stage of growth I don’t find it very useful to plan ahead further than this (aside from a few big rock items). The revenue function needs to be more agile and reactive at this stage, and so ops needs to flex along with it.

Here are some future initiatives to consider:

• Hiring: at around 6 months in, you should consider the design of your team for longer-term growth and your first few hires. A few likely candidates are a CRM Admin, a marketing/campaign ops role, and a sales ops / CS ops role focused on analysis, performance improvement, territory, comp, etc.

• Funnel tracking: I’m a big believer in the need for a clean data layer for funnel tracking using a custom object. This is critical for reliable funnel metrics and measuring the efficacy of different buying signals to optimize sales efforts.

• Churn prevention: It’s far cheaper to keep an existing customer than acquire a new one. Ensure you have the right processes to get customers to value, monitor their success, and react swiftly to any warning signs.

What did I miss?

This is one possible path. What would you change? What would you add?

The greatest moments for a RevOps pro are when you identify targeted adjustments to the funnel that produce significant, compounding results.

And one of the highest-impact changes you can make is to reach out to people who submit a demo or contact request (a.k.a. “hand-raisers”) as quickly as possible.

I love this project for three reasons:

• It greatly improves the customer’s experience with your brand

• It has a concrete, significant, and measurable impact on pipeline

• It burnishes your credentials as a strategic operator with business acumen

In this guide, I’ll show you exactly how we do it at my company. Implementing this process increased our lead-to-opportunity conversion rate for hand-raisers by 40%. Hopefully this helps you replicate the same results.

Summary

This post is, by necessity, quite long, so here’s a graphic with a quick executive summary.

Part 1: Strategy

The goal

The principle here is simple: when someone raises their hand by filling out a demo or contact us form (indicating that they want to begin a sales process) get back to them as quickly as possible.

Why is this so important?

You’ve probably seen these stats before, but it’s worth noting:

• A study in Harvard Business Review in 2011 found that companies who reach out within an hour were 7x more likely to have a conversation than companies who didn’t.

• Another study by Lead Connect indicated that 78% of prospects buy from the company that responds to your inquiry first.

• …there are others, but you get the point.

More importantly, it’s just common sense.

We can all relate to the experience of having a problem to solve and reaching out to multiple vendors to build a short list.

Some vendors respond quickly and professionally, others are more sluggish, and some simply ignore the inquiry.

Which vendor are you more likely to choose?

Remember, customers are looking to disqualify you

They don’t have time to evaluate every vendor, and the window during which a person is building their shortlist closes quickly.

If you take too long to respond, the person has already selected their top 3-5 options and moved on to engaging with the faster vendors.

Conversely, a quick response is a powerful signal of competence. It makes you look sharp and on the ball and suggests you’ll be easy to do business with.

The Business Process

First, define your SLA for the sales user to reach out. We use 10 minutes. This is highly achievable.

The SLA timer begins once the lead has been routed to the user. This is because there’s usually some time required for upstream processing (enrichment, sync to CRM etc.) before the lead is routed.

The SLA is only fulfilled once a call has been made. It’s very easy to automate an email that goes out instantly, but we’re looking for a 1-1 conversation here.

I recommend restricting this process to hand-raisers because typically this is where the vast majority of pipeline comes from (>80%). 

Also, getting a quick response to your contact request is a very different customer experience than being immediately hounded after downloading an ebook or attending a webinar. 

The former is delightful, whereas the latter can be annoying or even creepy. 

Part 2: Technical Implementation

So, let’s assume that you’re ready to implement your SLA.

How do you actually set it up operationally?

Pre-requisites

• A team of sales users responsible for qualifying inbound leads (typically a BDR/SDR team at more mature companies)

• Defined territories and routing rules

• A routing tool to perform the actual distribution

To execute this process, you’ll most likely need a specialized tool like LeanData, Ringlead (ZoomInfo), Traction Complete, or Distribution Engine. (Alternatively, you’ll need a fair bit of customization in your CRM.)

I use Distribution Engine for routing, and so this guide is based on that tool. I’ve tried a handful of the major players, and Distribution Engine is my favourite by far because of its robust feature set, flexibility, and ease of use.

I’d love to show how to achieve this process in all the major tools or even other CRMs, but it’s not practical. However, you should hopefully be able to follow the same principles I describe below to make this work with your tech stack.

Route hand-raisers separately

Whatever tool you use, it’s important to segment hand-raisers into their own pool for routing purposes.

This will enable accurate reporting and even load balancing of hand-raisers across your sales users (something that’s impossible if you mix them in with lower intent leads).

In Distribution Engine, we’ve configured multiple “teams” to handle these different routing scenarios. Each team can route to the same group of users, but this structure enables us to define different working hours and SLAs for leads with different levels of intent.

Only route handraisers to users available right now

🚨 This is really the critical feature that makes the process work.🚨

If you route to a user that isn’t available to work a lead, there’s no way they’ll meet the SLA.

But how do we know if a user is available? There are multiple layers to consider.

Working Hours

On the most basic level, you need to ensure you only route to a user when they are working that day (i.e., not on PTO), and it’s within their working hours as defined within your routing tool.

Most tools have a place to configure working hours and time off.

In Distribution Engine, we define standard shifts for our teams across different markets, and we log public holidays in each of those markets to restrict availability. Users are also enabled to log their own PTO.

Real-time availability

Now, just because a user is working that day doesn’t mean that they’re actually available to receive leads at that specific moment. They could be in another meeting, on lunch, away from their desk, etc.

If a user isn’t available in that moment, they won’t meet their SLA. So, we need to validate the user is actually free to action the lead before we route it to them.

This requirement is the most difficult to execute, but it’s the difference between a 10 minute response time and a 2 hour response time.

After considering various options, we decided to use Distribution Engine’s User Availability Toggle.

The benefit of this toggle is that this gives users direct control over their own availability, which is usually more accurate. None of the other options we considered (e.g., a calendar sync) would have been robust enough.

The downside is that it requires continual action from users and a relatively significant change management cycle. I’ll discuss that further below.

What if your routing tool doesn’t have an availability toggle?

Unfortunately, I’m not aware of a similar “availability toggle” feature in other tools. However, you can create similar custom functionality with a bit of effort.

For example in Salesforce you might:

1. Create a custom field on the user object called Availability

2. Create a Flow that toggles the value in this field from “Online” to “Offline” or vice versa

3. Add that flow to the Utility Bar in a Lightning app, where users can trigger it

Here’s a quick mock-up of this approach in action from Todd Sprinkel, Principal Solution Architect at Sponge.

Routing based on availability

Once your team is using an availability indicator, it’s pretty simple to configure specific distributors / routing scenarios to respect that property in routing rules. For example, you can use this field as a filter in the nodes on your LeanData graph.

Distribution Engine makes it even easier, with an option available in the distributor settings to respect or ignore the toggle status:

Holding hand-raisers until a rep is available

Most lead routing systems work like a coin sorter or decision tree, where a lead passes through a hierarchical series of rules and gets routed according to the first matching scenario.

But you may have windows during the day where all your reps are unavailable. Depending on your configuration, your hand-raisers may then get routed via a different branch of your routing logic with a more permissive SLA. This is bad for conversion and also throws off your load balancing.

To prevent this, it’s important to create a “dam” to keep these leads in a holding pattern and ensure they get routed the first available rep within the hand-raiser scenario.

To achieve this in our system, we have a filter on the next Distribution Team in the hierarchy that excludes hand-raisers. This prevents them from moving onwards in the process. They stay in a holding pattern until a rep is available.

Pro Tip: Always couple your automated routing with a human safety net that checks for any hand-raisers that may be “stuck” for whatever reason. This ensures that no one slips through the cracks. 

Hand-raisers on evenings and weekends

It’s inevitable that some hand-raisers will come in after hours—evenings, weekends, holidays, etc.—when no one is available.

We’ve found it’s important to handle these a bit differently, as otherwise the first rep to toggle on the next business day gets the entire pool of leads. This uneven distribution gives them an unfair advantage and offers no benefit, since the lead has already been waiting hours or days for a follow-up, and the rep can only handle one lead at a time.

So we have a separate distribution team for evening and weekend hand-raisers, which isn’t subject to the 10-minute SLA. It has a unique shift that kicks in one minute before our standard shifts do, and it distributes any after-hours hand-raisers evenly to the team.

Tracking SLAs

Distribution Engine has a built in feature for defining and tracking SLAs—for example, how long a rep has to take action, what data points in the system indicate the SLA has been fulfilled, and so on. Other tools have a similar capability.

All the SLA-related data (time to action, SLA infractions, etc.) gets stamped on a custom object log record for that specific routing event. This data model allows you to track SLAs granularly every time a lead is routed without needing to overwrite lead or contact fields.

For us, the “Time to Action” is stamped when a call activity is logged, which triggers an automation that updates the lead status and fulfills the SLA.

Pro Tip: To achieve maximum accuracy, you need to log the call activity when the call begins, not just when it ends. (Otherwise, a long connected call could create the appearance of a failed SLA.)

Unfortunately, relatively few softphone providers support this feature. 

When you have the data tracked with this level of granularity, it produces beautiful reporting. You can now track the average time to action and the % of records where reps are meeting the SLA—and slice it all by rep, market, and so on.

Integration with a meeting scheduling tool

In addition to our 10-minute SLA for hand-raisers, we also use Chili Piper to enable leads to book a meeting immediately after submitting the form.

There are a number of tools in this category (Calendly, Revenue Hero, etc.). I highly recommend you use one of them. It’s very easy to set up and super high impact.

For the people who book a meeting, we still send follow-up emails, but we exempt these leads from the 10-minute SLA since the meeting is already on the books.

Only about 40% of our hand-raisers use the meeting booker. This process is for the other 60%.

Part 3: Change management

The technical aspect of this project does have its challenges. But it’s the change management work that will really determine your success.

The only way you win is if your reps are bought in and committed.

Addressing your team’s concerns

Whatever your team’s status quo is today, they most likely aren’t required to click a button every time they leave their desk or face scrutiny if they don’t action a lead in minutes.

The bar is being raised for them significantly. I’d argue this is a good thing, but you need to have eyes wide open about all the anxieties this change may produce:

• Performance implications if they don’t hit their SLA

• Feeling trapped at their desk to avoid toggling off and missing a hand-raiser

• Missing their target if they don’t get an even share of hand-raisers

• Feeling rushed / stressed and overall experiencing a decline in work satisfaction

We had to address all these concerns and more.

The good news is that these problems are solvable, and our team went on to thrive under the new process. However, you need a thoughtful and sensitive approach to get everyone on board.

Get your messages clear

There’s a few key messages you need to relay to the team:

1. This will help them earn more $$$: the reason for implementing this initiative isn’t to punish anyone—it’s to generate more opportunities. Everyone wins if that happens.

2. 10 minutes is highly achievable: our team was concerned about the feasibility of a 10-minute SLA, but as you can see in the report above, most reps are in the 90-100% SLA fulfillment range and many have sub-5 minute average response times!

3. No one is getting fired for missing an SLA: the initiative should roll out gradually, with plenty of grace in the beginning as the team learns the ropes. Systematically slow response time does become a performance issue—but there’s no reason to stress about a few leads that slip through the cracks.

4. Hand-raiser distribution evens out over time: some days, a rep will have lots of meetings and receive fewer hand-raisers. But then those hand-raisers will generate meetings for other reps, who will become less available, and more hand-raisers will go to others….everything balances out assuming that everyone plays by the rules.

Have a structured communication plan

This isn’t the sort of initiative you roll out by email.

You should have a structured communication plan with a variety of touch-points. For example:

1. Join rep team meetings to introduce the project and share a plan with them, emphasizing the messages above. Highlight that there will be a chance to ask questions and address concerns.

2. Have the SDR/sales manager(s) raise the topic in 1-1s with each of the affected reps, giving a chance for them to surface concerns they might hold back in a group setting.

3. Join team meetings again, this time to listen to questions / feedback and provide answers.

4. Provide a thorough enablement on all new processes and features related to the process. Ensure that reps take the training.

5. Once the initiative goes live, celebrate wins and don’t dwell on failures. If you make a hero out of the reps that are doing well, others will want to emulate them.

Managing performance

After you go through the initial learning period, you’ll likely settle in to a steady state where most reps are meeting or beating the SLA. And you should start to see a corresponding increase in conversion.

It’s now up to managers to monitor response time as a KPI, just like any other metric, and to make it part of coaching and performance improvement discussions. Ops should also keep a watchful eye here to surface any issues.

Pro Tip:

Watch for sneaky behavior. Some reps may decide to just leave themselves as "available" all the time (i.e., never toggle off), even if they have no chance of responding in 10 minutes. 

They'll realize it's better financially to take the hit on their SLA and create more deals by getting a bigger share of hand-raisers. 

These sort of shenanigans need to be dealt with quickly and sternly, as it can destroy team morale and create resentment. 

Distribution Engine has a report that allows you to audit when reps are toggling on and off, which exposes this behaviour instantly. 

Conclusion

I hope this guide gets you started on a path to improved customer experience and higher conversion.

Feel free to post a comment if you have any questions about the implementation in your org. I’m happy to help where I can.

In earlier posts, we’ve looked at defining the overall mission for your ops team, budgeting your time into workstreams, and how to prioritize for maximize impact.

Follow these steps, and you can be confident you’re doing the right work.

But doing the right work isn’t the same as doing things right. And this is where many teams fall down.

There’s nothing magical about great execution. But doing it consistently requires a clear process and a disciplined team.

The Stages of Work

As a general rule, the following stages apply to any task you might work on.

• Initiation: Identifying or proposing potential work

• Triage: Assessing and clarifying the task

• Prioritization: Determining if and when the task should be executed

• Execution: Doing the work. This may have sub-phases:

  • Design: Defining requirements and designing the solution

  • Build: Configuring systems or creating the deliverable

  • QA/UAT: Testing the work to ensure it meets requirements

  • Enablement: Training and communication

  • Go-Live: Deploying the new solution or process

  • Monitoring: Continual observation and intervention to ensure impact

Let’s review each stage in detail.

Initiation

Initiation is how work gets started.

Any ops team will inevitably field many incoming requests, but to avoid being pigeon-holed as a service department, make sure you’re also starting with business KPIs, and doing your own holistic evaluation of what work is most important to do.

Triage

It’s easy to work reactively or try to rush a task without considering its true scope or potential downstream ramifications.

Triage forces you to slow down and evaluate the task critically, identify missing information, and enforce project management system hygiene standards.

Triage tips

Effective triage relies heavily on your common sense, good judgement, and experience. It improves with practice.

But here are some tips that can help.

Enforce your intake process

• Teams often need reminders and reinforcement to follow the intake process.

• If stakeholders initiate work through unauthorized channels (Chatter, Slack, etc.), this is your chance to push back.

• If you aren’t 100% consistent, people will do what’s easiest for themselves and your execution will suffer.

Watch for feature requests masquerading as bugs

• Sometimes people consider something "broken" if it isn't working according to their expectations.

• This creates pressure to fix it quickly.

• But what they consider broken may just be a requirement that was never previously considered.

Collect all the information upfront

• If a request is vague or lacking detail, request it now before starting work.

• This is particularly important for marketing campaigns with many moving pieces.

• For example, if your stakeholder needs to provide a subject line, a feature image, a sender name (etc.)—make them do it upfront, so you aren’t blocked later on.

Enforce project management hygiene

• If your project management system is a mess, you most likely aren’t executing well.

• There’s no need to overcomplicate things, but you should insist that all tasks/cards have a clear title, a sufficiently detailed description, an assigned owner, and any labels needed for filtering / reporting.

• Reinforce this with your ops team members so it becomes second nature.

Identify the root business need

• Stakeholders often come with a specific solution in mind. But this may not be the right solution.

• It’s your job to dig deep into the root pain / business need to ensure you solve the right problem in the best way.

Be judicious about “quick wins”

• I define a “quick win” as a high impact task that takes 30 minutes or less.

• These are typically faster to execute in real time than to backlog and prioritize for another day.

• However, you can easily get bogged down in quick wins that aren’t so quick and lose sight of your strategic priorities. So evaluate them carefully.

Assigning a T-Shirt Size

We use the "T-Shirt Size" methodology to estimate effort.

The purpose of this estimating methodology is not to be precise—it's to be reasonably accurate and fast.

Use your best judgement and don't worry if you aren't right. Just learn, and use the knowledge to be more accurate next time.

As a rough guide for translating effort to hours:

• Extra Small (XS): 1 hour or less

• Small (S): 1-5 hours

• Medium (M): 5-10 hours

• Large (L): 10-20 hours

• Extra Large (XL): 20+ hours

Prioritization

Tasks that aren’t executed immediately as a quick win or rejected due to lack of impact go into a backlog for future prioritization.

For some teams, prioritization might occur on a quarterly basis, when preparing OKRs, but could happen more frequently if you’re using a sprint framework.

So how do you prioritize?

There are many frameworks you can use—Jeff Ignacio has a great roundup here.

In my current stage of company (~400 people), I generally prefer to keep prioritization as simple as I can, focusing on big rock initiatives clearly aligned with our corporate OKRs. Common sense is also a useful guide.

Execution

Execution can be simple or complex, depending on the task. Typically it should be broken down into the following sub-phases.

Design Phase

Design phase ensures the work is aimed at the right outcomes and that all stakeholders are aligned on the work to be done. That means everyone agree on what "success" looks like. 

It can be tempting to go fast by skipping this stage and to start building in tools.

This is the wrong decision pretty much 100% of the time.

It typically results in more re-work and ultimately slows things down when the end result doesn't meet expectations or achieve the intended impact. 

The requirements, business logic, and technical solution defined during this phase should be captured using the appropriate level of documentation. Don’t put it off.

Build Phase

The build phase is when the work product or deliverable gets made—i.e., you configure the system, you design the process, you build the report, and so on.

Some tasks may not have a build phase (e..g, the task is more conceptual, like defining a KPI or providing information). 

QA / UAT

As a general rule, any new system configuration should be tested before being activated/released. 

How much testing should you do? This is a common-sense judgement based on the risk / impact of potential errors and time required. 

What’s the difference between QA and UAT? Both are aimed at ensuring that work meets its requirements, but I define QA as testing done by ops and UAT as hands-on testing from users / stakeholders.

Enablement 

Even a perfectly-designed and well-tested solution can fail if users don't understand it or know how to use it. So your enablement plan is a vital part of the work. 

Although formal training might only happen near the end of a project, your communication and change management efforts should span the entire project.

This is a detailed topic, so check out my complete guide to change management here.

Go-Live

Deployments are fraught with peril and need careful planning to avoid system disruption or unintended regression.

Pay special attention to data updates that might overwhelm system integrations and create backlogs. Evenings and weekends are your friends here.

Monitoring

This phase is about ensuring impact.

We added it as an explicit step to our process relatively recently. It’s something we always knew we should do, but without a formal step and process, it relied too much on individual discretion.

Monitoring means you proactively ensure a system is functioning without waiting for user bug reports.

It means being able to answer the question in 6 months, “what did this actually do for us?”.

You may need multiple interventions and iterations to ensure a project is actually achieving the intended impact.

Final thoughts

There’s obviously no one-size-fits all process here. You may need to tweak things based on the size and maturity of your team, your scope of responsibility (e.g., whether business systems live inside ops or in a separate team), and your business context.

But the work you put in to develop rigour here will pay huge dividends in the quality of your output, the impact you have, and your credibility in the organization. Of course, it also makes work way more enjoyable!

Stay tuned for a follow-up post where we’ll look at how to execute this process within a project management system.

Almost any work in operations affects other people and requires their adoption or support to be successful.

You may not be trained for this—but if you’re an operator, you’re also a change manager. It’s as simple as that.

It’s core to the job

The most common change management strategy might be described as “hope for the best.”

Even when it’s included in the plan, change management is often treated as an extra—an afterthought to be tacked on to the end of a project and perhaps addressed with a bit of training or documentation.

This usually won’t be sufficient. Change management has to be incorporated into the foundation of how you operate, starting with initial planning of a project and extending well beyond the go-live date.

The impact when change isn’t managed well

What happens if you don’t manage change properly?

Best case: it will make your job and life harder, forcing you to spend time on re-work or re-enablement.

Worst case: it will cause your initiative to fail, damaging your credibility and job security.

Practical examples: 

- You design a new dashboard without consulting all stakeholders. Executive leadership doesn't adopt it and continues to use other ad-hoc reports, leading to fragmented sources of truth. 

- You want your sales team to start asking prospects "how did you hear about us?" so you roll out a process and some new fields. Sales doesn't see the benefit and generally ignores you. The field has a 1% completion rate.  

- You roll out a new CPQ system. Despite the training and extensive documentation you prepared, reps feel blindsided, leading to general confusion, anger, and frustration when the system goes live. You find yourself under intense executive scrutiny for the impact on pipeline and forecast accuracy. 

- You create a self-serve model for marketers to launch their own campaigns in your marketing automation platform. You have templated assets and clear documentation, but marketers struggle with the new process and continue to barrage you with questions. It's harder to get campaigns out the door, and word trickles up to your CMO. 

- You rearchitect your lead flow to make it more streamlined, robust, and scalable. The new design is objectively superior, but some operators on your team don't understand it and now struggle to make changes that interface with it. 

The last example is interesting, as it shows how even largely “technical” or internal operations projects aren’t exempt from needing change management.

Operators need to manage their own change cycles too.

Why we struggle

Few of us have formal change management training.

Also the type of people who enter operations tend to be left brain thinkers—analytical and process and data-oriented.

A poorly functioning system is frustrating, but at least it can be de-bugged, re-architected, and optimized. It’s a logical machine.

Human beings are far more complex to “debug” and often aren’t entirely logical. Sometimes they can be irrational, unreasonable, and even hostile.

The solution

I have no silver bullets for you, only insights and tactics learned over the years, usually through repeated mistakes.

Make change management a priority

It’s critical to recognize the necessity of managing change and to integrate it into our workflows.

It should be part of the discussion whenever a new project / idea / initiative is brought to the table and fully baked into the plan,

Develop situational awareness

Your change management requirements are going to be driven by your context and your project.

Regardless of the project, driving change in a young startup of five people is far easier than in a massive 10,000 person company.

And regardless of your context, implementing a small change that requires no behavior modification is different than a huge project that requires people to completely change their routines.

So as you consider any new initiative, take stock of your context and how people will be affected.

Some questions to ask yourself:

• What teams and people will be impacted by this change?

• Does it require an active change in behavior?

• Does it affect information or systems people use regularly?

• Does it impact sensitive topics like incentives, performance reporting, financial data, etc?

• Is there a company “history” that might come into play? Personal sensitivities? Baggage or tension?

Practical example: 

Your company's suite of products is growing in complexity, and you see a clear need to roll out a CPQ system in your CRM. 

However, there was a similar initiative that failed miserably a few years ago. Many reps remember this failure and the pain it caused. 

This company history will dramatically increase the change management requirements for any new attempt in this area. 

Understanding and addressing concerns

There are always reasons why people don’t embrace (or even actively resist) change.

“Stages of Concern” is a useful tool to help identify and address those reasons.

It’s part of a broader framework called the Concerns-Based Adoption Model, originally designed for use in an educational context.

The Stages of Concern model how an individual moves through different attitudes towards a particular change, progressing from indifference / apathy to a focus on broader impacts and eventually to collaboration.

Here’s a table of the different stages and a typical statement associated with each (I’ve adapted them to a RevOps context, continuing with the example of our hypothetical CPQ project).

You can use this framework in a few ways.

Creating empathy

Before one major change at a previous role, we applied the Stages of Concern to proactively identify and anticipate the potential concerns that stakeholders might have.

There are many possibilities:

• Seems disruptive / too busy / can’t be bothered

• Lack of understanding

• Fear of increased work / reduced productivity

• Fear of reduced visibility / access to information

• Fear of impact on ability to perform / loss of credibility

• Fear of the unknown

• Politics / turf wars

Working through the stages helps you get inside the head of your stakeholders and make sure you address their concerns in your messaging.

Gauging impact

The Stages of Concern was originally designed as an assessment model with a questionnaire to identify the stage people were at.

While I haven’t applied this formally, you could take a similar approach with a survey or 1-1 interviews with your stakeholders. This helps you understand your progress and how to communicate better.

Practical example: 

You distribute a brief survey to your sales team, and the majority of them agree most with the statement, “I think I heard something about this CPQ project, but I'm too busy right now with other priorities to be concerned about it.”

This means the team is largely unaware of or indifferent to your initiative—they're at Stage 0 (Unconcerned). 

So your primary goal is to help them become aware of and interested in your project. 

A few weeks later, you give the same survey and the team now aligns most with the statement, “I'm concerned about the changes I'll need to make when I’m creating opportunities.”

You're now at Stage 3 (Personal). 

Your goal now becomes to show them how the opportunity creation process will be simple, fluid, and make their lives easier. 

Creating your communication plan

A Slack message is not a communication strategy.

You need to think of this like a multi-channel nurture, where you reach people with a variety of messages in a variety of formats from a variety of personas over time.

Of course, you need to right-size it for both the size of your company and the complexity / impact of your initiative.

Here’s an example communication plan for our CPQ project:

Access the Spreadsheet

The goal is to keep up a steady drip of information that informs, educates, and engages.

If done well, it should both address concerns and build excitement. Yes, it’s a lot like marketing. 😊

You’ll also notice it doesn’t stop at the delivery date. It should continue until the new initiative becomes the status quo.

Don’t change alone

If you look closely at the communication plan, you’ll notice it’s not just the project owner being a lone voice in the wilderness, hoping that the team will pay attention.

Change management is most effective as a team sport, and so you should be cultivating allies, sponsors, and supporters to help drive the process.

Top down

The most natural support is from your own executive leadership as well as the leadership of impacted teams.

This kind of alignment is a critical part of project planning, so ideally you have these people bought in by the time your project has the green light.

Now you need to keep them engaged throughout the process—both as part of managing their own change cycle and so they can reinforce your messages with their team.

People may ignore Slack messages from ops, but they’ll be unlikely to totally disregard a message from their manager in a 1-1 saying “this is important.”

Bottom up

People are also highly influenced by their peers, especially those perceived as influential top performers.

You should identify these people at the start of a big project and enlist them in the process. If the impacted team is large enough, you can form a smaller “advisory committee” that gets early access to new ideas / features, gives feedback, and helps communicate back to the broader team.

This is a great way to course-correct early if something is wrong and to turn the most influential team members into evangelists.

If an influential team member has concerns, including them in the process can also be an effective way of diffusing those concerns and making them feel a sense of ownership in what you’re delivering.

Conclusion

This whole thing can be uncomfortable, and it can feel like a lot of extra work.

It’s easy to cut corners or take shortcuts.

But keep this in mind: if our goal is to drive impact, then we only achieve that when our work is fully adopted and operational.

Change management is how we do it.

Your most important job as an in-house operator is to make wise choices about the work you do.

Unfortunately, it’s all too easy to hustle and grind through a quarter without getting the impact you hoped for.

There will always be far too many projects competing for some of your strategic, discretionary time.

So, how do you choose the right work?

Beware of the backlog

Most operators have a backlog of potential work. These ideas can be generated by the RevOps team or requests from client departments.

When it’s time to plan your next month / quarter / sprint, you try to groom the backlog and prioritize it in some way to select the work you’re going to do.

Don’t get me wrong: a backlog is useful and necessary. But if you rely solely on a backlog to define your work, it can create blindspots.

In episode #5 of RevOps FM, Jen Igartua (CEO of Go Nimbly), talks about the risks of letting a backlog drive your priorities:

You already have a backlog somewhere, right? You've got a bunch of requests that have come in. You have a bunch of problems you've found….And typically when a team says, “Hey, we need a roadmap” or “we need to plan for next quarter,” they'll pull up that list. […]

And then we'll give it some sort of framework [for prioritization]. Maybe we'll do the urgent versus important framework, or we'll do impact versus effort, and we'll figure out what we need to work on. […]

The problem with that is it's starting with ideas and features and work, and it's not talking about the gap or the problem or the inflection point that we're going after.

Backlogs can be dangerous because they aren’t comprehensive. Even if you apply a rigorous prioritization methodology to your backlog, you’re still starting from a limited set of potential ideas.

What if the highest-impact activities didn’t make it into your backlog in the first place?

Practical example: 

As a home owner, you keep a backlog of work you want to do around the house. 

You've just prioritized your house projects for the year, and the highest-priority item by far is to put on a new roof. Roof leaks can be very damaging, so this seems like a sensible priority. 

You get to work on your new roof, but meanwhile there's a fire in the basement you didn't know about that threatens the entire structure...

Of course, no one’s going to make this mistake in real life.

But in business, it can happen easily! The fires can be invisible if you don’t look at the data.

It's not uncommon for operators to focus on projects that are useful in themselves (the roof) while disregarding significant, revenue-impacting issues in the funnel (the fire) due to lack of situational awareness.

If this happens, it’s a sign that you aren't close enough to your KPIs.

Starting with the business

To avoid these blindspots, you need a way to look at the business holistically and identify where your effort can have the most impact.

Instead of basing your priorities solely on the backlog (which may be non-comprehensive) consider the performance of the business against its key objectives. By identifying the gaps in that performance, you can determine where to direct your effort.

Jen uses the term “gap-first thinking” to describe this process:

…start with [the question] “What's the outcome?” Are we doubling our sales team by next quarter? Are we going to IPO? Do we have new products launching? […] Then what's getting in our way of that work? That needs to be prioritized first.

Having that clarity gives you an ability to look at something and be like, “well, that's not important. I'm not going to do that work.”

And without it, you end up prioritizing things that you are speculating will have impact.

Now, take a look at this quote from Ben Marchal, COO of 360Learning, in episode #8. He describes a nearly identical process:

I [started to look at] what are the main KPIs…that are actually driving performance.

And once I had that, I had…a very clear picture of where we should focus our efforts.

So I can have the discussion with the VP or the C-level and say, your managers are asking me to do X, Y, Z, but looking at this picture… don't think this is the main issue of the team. I think actually the main issue is there and and this is what we should do.

And you know, switching that, having that conversation then with the VP or the C-Level changes completely the dynamic in in the work. Now you become a strategic partner for them.

Let’s examine the common elements between how both operators approach prioritization:

• The starting point for prioritization is to look at business goals

• Next you evaluate the most significant gaps or opportunities related to those goals using objective data, like KPIs

• With that understanding, you can push back against lower-value work and build consensus around the work that will be most impactful.

Using KPIs to identify the most important gaps

Even with a gap-first mindset in place, it’s not always easy to identify where the most important gaps are.

You need to be data driven. But I find you also need a healthy dose of common sense, as otherwise you can spend all your time planning and succumb to analysis paralysis.

KPIs are the most logical place to start. Jen recommends using “3VC” (Volume, Value, Velocity, and Conversion) as a set of KPIs that can be applied to any stage of the funnel.

By examining these KPIs for different funnel stages, you can drill down into where your gaps might be and also evaluate different points of leverage for closing those gaps.

Practical example:

Your marketing team is behind on its pipeline goal this quarter. They could impact this metric in a variety of ways: 

Volume: produce more leads, leading to more opportunities

Value: generate leads that become bigger opportunities (higher amount)

Velocity: generate leads that convert more quickly

Conversion: convert a higher percentage of leads to opportunities

Ben similarly focuses on KPIs to identify gaps, but he recommends building a “KPI tree” for each part of the business.

I like this approach as it allows you to get very granular and uncover factors that might be hidden from view or masked by over-performance in other areas.

Example KPI tree for an inbound BDR team

Here’s a practical example of a KPI tree for an inbound BDR team. These are the real KPIs we use at my company for BDR Operations (which is part of my team’s scope).

You can see that many of the metrics are one of the 3VC KPIs that Jen describes.

But some of them are arguably slightly different—for example, quality-related KPIs like the % of leads that are higher intent or that are not a fit.

We might also include additional tangential metrics like

• cadence engagement metrics (a proxy for the effectiveness of our sales outreach)

• BDR employee satisfaction surveys (a proxy for morale / motivation of the team)

• individual rep target achievement (as high performers can balance out low performers in aggregate)

• and so on

I also like that the KPI tree reveals the hierarchical relationship between KPIs, allowing you to dig deeper in specific areas to discover root causes.

Finding the “why”

KPIs are essential for showing you WHAT is happening—whether that’s positive or negative.

And they can, to an extent, reveal the WHY behind your performance as you go deeper and deeper.

However, after a certain point, you hit a floor. The numbers don’t explain themselves, and you have to go back to physical reality to really understand why things are the way they are.

This is where qualitative data becomes just as critical as quantitative data. It’s why call intelligence tools like Gong have become so business-critical.

Practical example: 

You're seeing a drop in qualified opportunities created by your BDR team. 

Using your KPI tree, you drill down and identify that the gap is due to a drop in your meeting attended to qualified opportunity rate. 

You further identify that the gap is almost entirely due to the performance of a new BDR that recently joined the team, and that their opportunities are being rejected by AEs at a much higher rate. 

The KPIs helped you triangulate the gap with a high level of precision—but they can't offer more insight into the critical question: 

Why does this BDR have such a high reject rate? 

You use qualitative data to answer that question. 

By listening to that BDR's calls, you identify that they need to improve their discovery skills and are doing a poor job recording information from the call for the sales team. As a result, the opportunities don't appear qualified, and sales is disproportionately rejecting them. 

Armed with this information, you can work with the rep's manager and your enablement team on a performance improvement plan. 

Besides calls, Jen also suggests several other qualitative methods you can use to better understand gaps you’ve identified or to proactively discovery new ones. These include:

• Ride-alongs with GTM team members

• Competitive analysis / secret shopping

• Customer experience mapping

Conclusion

The ability to prioritize well and communicate your plan can ultimately make or break you as an operator—especially if you’re leading a team.

It’s the difference between feeling overwhelmed-yet-under-appreciated and being seen as a strategic partner, who has a lot of capital built up to say “no” or to drive net new initiatives.

Don’t get me wrong: this type of prioritization is hard.

Not because the analysis itself is particularly difficult.

But because it forces you to

• maintain a high level of situational awareness

• be rooted in business performance and KPIs

• budget time for analysis and planning when you’re already overwhelmed with execution

On the flip side, when you invest that time, you’ll feel a great sense of satisfaction and confidence at the end of a quarter.

You’ll know you did the right work.

Resources

• RevOps FM Episode #7: Habits of a Highly Effective COO - Ben Marchal

• RevOps FM Episode #5: Aligning RevOps with C-Level Priorities - Jen Igartua

• What is Gap-First Thinking for RevOps Teams? - Go Nimbly

• How RevOps Teams Find Gaps- Go Nimbly

You might notice I write a lot about the need for RevOps to focus less on technology and more on business impact.

This is, in part, a nudge to correct what I see as an imbalance of focus in our field. But, of course, that doesn’t mean tech isn’t important — far from it!

Technology and data are the backbone of modern ops teams. And the technical anchor of your ops team is the systems architect.

What is a systems architect?

We can think about systems skillsets in a rough hierarchy. This is often reflected in the different tiers of platform certification a vendor offers.

• System User: executes key tasks within the system.

  • Example: executing a webinar campaign in a marketing automation system.

• System Admin: configures the global settings and environment that users operate within.

  • Example: configure fields and page layouts in CRM.

• System Architect: creates the vision and design of the system as a whole. This potentially spans many discrete platforms.

  • Example: define jobs-to-be-done, determine which tools will do which jobs, define how all the tools connect to each other.

Profile of a Systems Architect

I’ve observed that people who excel in each of these roles tend to have a particular orientation.

By “orientation,” I’m speaking less about skills and more about the type of work that people find interesting, exciting, and gratifying to do.

People succeed when their role matches the work they love.

Practical example: 

Campaign Ops

People who excel at campaign ops tend to have amazing attention to detail and get satisfaction from working with stakeholders to bring a campaign vision to life. 

However, if tasked to design a net new solution without an existing framework, they may find it stressful. 

Systems Architect

Conversely, an architect absolutely craves to be the one solving that new problem. But they're unlikely to do well in campaign ops. 

Repetitive work doesn't suit them, and they and may find the communication with campaign stakeholders frustrating rather than fulfilling. 

In both cases, it's not really about skills. The two personas are simply oriented towards a different type of work. 

I used to lead a solutions architecture team at a marketing ops agency. When evaluating if someone would make a good architect, these were the main attributes I looked for:

Figure-it-out-ability

When presented with a challenge that has no existing solution, can the person autonomously take the steps to solve that challenge?

(E.g., through searching documentation and forums, trial and error, asking peers, etc.)

Craving for challenges

Do they love the process of solving those new challenges — of being the one to figure it out? Does their hand shoot up right away if someone needs to volunteer to do it?

Systems thinker

Are they able to quickly perceive or envision the different parts of a system and how they relate to each other as a functional whole?

Do they have an innate drive towards clarity and logic in how roles are assigned within the system?

Fastidious

Do they sweat the details?

Good architects are generally allergic to loose ends, redundancy, or messiness.

They have a drive to create order and to account for edge cases.

Love of tech

Architects have an intrinsic fascination with tools and technology. They’ll gravitate here naturally, and if left alone will usually focus on the systems aspect of a project.

Developing a systems architect

So are architects born, or are they made?

In my personal experience, I’ve found that many of the personality and interest factors are relatively fixed and innate (at least for the purposes of work).

You might be able to take someone who is a 7/10 on figure-it-out-ability and get them to a 9/10 with coaching.

But it’s extremely difficult to get someone from a 3 to 7. Or to take someone who simply doesn’t enjoy solving new challenges and get them love it. They won’t be happy or successful.

So in the first place, you need to select for people that demonstrate the interest and aptitude for architect work. Then you can train them on the hard skills required.

If you’re an aspiring architect, or if you have one on your team, here’s a non-exhaustive list of things you can do.

Cultivate an architect mindset

Mindset isn’t a specific skill. It refers to your whole way of thinking and approaching work. It’s the “lens” you’re viewing problems through.

I’ve found the most efficient way to cultivate an architect mindset is through osmosis — by observing and ideally interacting with other architects and technical folks.

Practical example: 

Earlier in my career, I subscribed to Sanford Whiteman's posts on the Marketo community. So I got emailed every time he posted.  

Keeping in mind he sometimes posts dozens of times a day, this provided a steady intravenous drip of developer mindset that I took in for years. 

I learned a lot of valuable information this way, but the more important benefit for me was internalizing how Sandy thought about problems, the types of thing he was concerned with, and how he talked about them. 

I acquired the developer mindset through osmosis.

To work on your mindset, here are some resources and people / channels to follow:

• RevOps FM Episode #6: The MarTech Developer - Sanford Whiteman

• RevOps FM Episode #23: Building a Next-Gen Composable Martech Stack - Niels Fogt

• Sanford’s posts on the Marketo community

• Sanford’s blog

• Todd Sprinkel’s blog posts

• Niels Fogt’s posts on the Tray.io blog

• The #advice-mops-dev channel in the MOPs Pros Slack community

Understand software architecture best practices

Software architects have been figuring out best practices for decades, and many of these principles apply to no-code/low-code/configured solutions. So we don’t need to reinvent the wheel.

Keep in mind that, depending on your application, we aren’t always applying these principles 100% literally. It’s more a way of thinking about system design.

Practical example:

You can create “microservices” (operational programs) inside your Marketo instance to perform different functions. 

These probably wouldn’t be considered literal microservices by a developer; it’s more an application of that idea to the configuration within Marketo. 

Alternately, you can also apply that design by building a composable stack made of totally separate applications connected by APIs.  

Each of these concepts would be a long post in themselves, but here are some topics to read up on to get started.

Microservices and Composability

• An Introduction to Microservices by Amanda Bennett

• Microservices explained - the What, Why and How? (Video) by Techworld with Nana

• Microservices as a Future Approach to Marketing Tech by

  Leonardo Federico

DRY (Don’t Repeat Yourself)

• Understanding the DRY (Don't Repeat Yourself) Principle

• Programming Terms: DRY (Don't Repeat Yourself) (Video)

• DRY Clean Your Marketo Engage Instance by Amy Goldfine

Separation of Concerns

• Separation of concerns on Wikipedia

• Separation of Concerns by Talin

Build your hard skills

APIs

A composable martech stack is built on a foundation of APIs.

Modern iPaaS tools have pre-built connectors for many common apps, which makes it easy to connect tools without any direct knowledge of their APIs.

However, inevitably you’ll need to perform an API action that isn’t supported by the pre-built connector, and so being able to work with APIs directly is vital.

• What is an API? by Postman

• Postman API video series:

  • What is an API? | Intro to APIs Part 1

  • How to use an API? | Intro to APIs Part 2

  • HTTP Protocol | Intro to APIs Part 3

• Demystify the API by Tyron Pretorius

JSON

JSON is the data format commonly used by modern APIs.

• JSON - Introduction by W3Schools

• Learn JSON in 10 Minutes (Video) by Web Dev Simplified

iPaaS Platforms

An iPaaS platform allows you to sync data and orchestrate and automate processes across your martech stack.

There’s a bunch of them out there. Some truly do require a developer skillset. And some, like Zapier, are too limited for serious use in my opinion.

There are two platforms I’m aware of that find the Goldlocks zone — combining enterprise-grade power with a GUI friendly for non-developers: Workato and Tray.io.

Workato has an Automation Institute and a free trial instance (kind of like Salesforce Trailhead). So you can really get your feet wet and start learning right away.

Coding

I don’t think coding is essential for an architect, especially if they’re working in a larger team with access to developers.

However, there’s no denying that coding is very useful and will extend your capabilities significantly.

I tend to pick up bits and pieces of coding knowledge on an as-needed basis and then forget them in between projects. 😂

If you want to invest in your coding skills, the two languages to think about are:

• JavaScript (for web / client-side work)

• Python (for API / scripting work)

The biggest problem in revenue operations is finding the time to get it all done.

The sheer volume of requests, problems, opportunities, and expectations can be overwhelming. It's easy to feel like you're failing no matter how hard you work — that something is always slipping through the cracks.

Two common traps

I’ve observed two common challenges in how teams deal with this problem (and have fallen prey to both of them myself).

🫡 Working reactively

In working reactively, you aim to provide the best service you can and to be maximally responsive to your stakeholders.

• Jumping on the most recent notification in your inbox as soon as it arrives.

• Responding to Slack / chat notifications in real time.

• Always making yourself available.

The downside is that you lose all control of your time and make very little progress on your planned priorities.

Your stakeholders will generally feel positive about how helpful you are. But you also end up plagued with nagging guilt that key projects aren’t moving forward, and leadership will perceive you as lacking strategic acumen.

🙅 Working in a silo

This is the opposite extreme. You go heads down on your own priorities and respond slowly/infrequently to inbound requests.

You end up deep in “communication debt.”

While you will deliver on important priorities, the sentiment about your work will generally be negative among the teams you support. Stakeholders will become increasingly frustrated and complain that ops doesn't support them.

Also a lot of those requests ARE still important to the smooth operations of the business, even though in isolation they’ll never seem as impactful as the priorities you have planned. By ignoring them, you clog the gears of your own machine.

The solution: workstreams

Workstreams are simple in concept but powerful in practice.

Rather than trying to prioritize between dissimilar tasks, you recognize that your team has different streams of work that all get a certain “budget” of time.

Then you prioritize tasks within those workstreams.

Workstreams span functional areas and are more about the type of request. I also divide them between “run” activities (that relate to day-to-day operations) and “innovate” activities (that aim to change or improve the business).1

Here are the five main workstreams we use on my team (yours may be different depending on the mission and scope of your RevOps team).

🎯 Campaign operations

Executing a discrete and time-bound marketing or sales initiative in our systems.

• Examples: email campaign, webinar, event list upload
• Run or Innovate: Run
• Intake: project management request form
• Time-frame: Execute per SLA

🤝 Support

Request for help with an existing process or system.

• Examples: wrong lead assignment, fix attribution, create ad-hoc report, bug fix
• Run or Innovate: Run
• Intake: project management request form
• Time-frame: MOPS team to assess urgency and act accordingly

🔄 Operating rhythm

Supporting the planning cycle and operating rhythm of a revenue team.

• Examples: target setting, incentives, staffing, etc.
• Run or Innovate: Run
• Intake: established cadence depending on the activity
• Time-frame: ongoing

💻 Products

Process and system configuration to support our business needs. Products are continually created and developed with new features.

• Examples: new routing scenario, new program template, new dashboard
• Run or Innovate: Innovate
• Intake: project management request form OR MOPS planning process
• Time-frame: opportunistic (low effort + high impact) = immediately; strategic (higher effort + high impact) = prioritize in roadmap

💰 Performance

Analysis and initiatives to improve the business performance of the marketing team.

• Examples: optimizing lead management process, improving a follow-up cadence, identifying channels to increase/decrease investment
• Run or Innovate: Innovate
• Intake: project management request form OR MOPS planning process
• Time-frame: opportunistic = immediately; strategic = prioritize in roadmap

Here are the workstreams summarized in a table format that you can copy and customize for your own needs:

Access the workstreams sheet

Using workstreams to budget your time

With workstreams in mind, you can make intelligent decisions about how to budget your time.

For example, you may agree with your stakeholders that RevOps time will be budgeted as follows:

• Campaign operations: 30%

• Support: 15%

• Operating Rhythm: 15%

• Products: 20%

• Performance: 20%

However, this ratio may be different for different team members.

Campaign Operations Specialist

• Campaign operations: 60%

• Support: 30%

• Operating Rhythm: 0%

• Products: 0%

• Performance: 10%

Platform Operations Manager

• Campaign operations: 0%

• Support: 20%

• Operating Rhythm: 0%

• Products: 80%

• Performance: 0%

Sales Operations Analyst

• Campaign operations: 0%

• Support: 30%

• Operating Rhythm: 30%

• Products: 0%

• Performance: 40%

Summary

I find this framework gives a lot of clarity. You can better control your work, assess true capacity, and funnel tasks into specific workflows depending on what they are.

Life will never be easy in ops, but I find this framework ensures a good balance of high-impact strategic work and daily stakeholder support.

What’s the purpose of your ops team?

Why does it exist at all?

This may seem totally obvious. But often, it’s not.

Just like “lead” or “campaign” or “MQL,” different people may have completely different definitions and expectations. Even your own definition may not be precise.

Why mission and scope clarity is important

It enables clear decision-making

We make a never-ending series of prioritization decisions at work.

If you aren’t clear on your mission, you can easily focus on the wrong things.

This creates potential for a troubling scenario where you’re working hard - maybe even focused on the right problem - but not actually delivering what the business needs most.

Practical example: 

Your company is struggling to close new business, so your ops team launches a project to tackle some technical and process inefficiencies that sales has been complaining about. 

What you don’t realize is that most AEs aren’t clear on your positioning and aren’t delivering a consistent pitch. 

The company relies on you to enable the sales team to succeed, but you thought of your mission only in terms of tech and process. 

You limited the scope of inquiry and missed the root cause.

It aligns expectations

Businesses are networks of collaboration. Collaboration works well when participants have (more or less) shared expectations.

It tends to break down when expectations aren’t aligned.

Like it or not, our success at work is a combination of delivering impact AND the perceptions that others have of us.

Depending on impact and perception, you fall into one of the following categories.

• Imposter: You deliver no impact but people think highly of you. Some people are surprisingly good at this, but it’s obviously not the road we want to take.

• Unsung hero: You deliver great impact but it’s not aligned with stakeholder expectations. Bad for job security.

• Winning: You deliver great impact, and everyone recognizes it. You want to be here.

A clear mission for your ops team creates alignment on how you will deliver impact for the business.

Practical example: 

Part of your scope is to enable marketers to be autonomous in executing emails, webinars, and other marketing initiatives. 

You deliver a great decentralized system with tools, enablement, documentation, and templates to make this easy. Impact is high. 

But, some team members just want you to send the emails for them. They expect this to be part of your scope. When you don't deliver it, they have a negative perception of your impact and complain to your boss. 

You have a misalignment of expectations. You're an unsung hero. 

How to create the team mission and scope

Ideally, try to keep it simple and not overcomplicate things.

Building the definition

This may simply be a matter of transcribing tribal knowledge that is already largely recognized into a written format.

But in a larger company, or where expectations are currently seriously mis-aligned, the process may be more difficult.

I believe it’s always best for ops leaders to propose their own definition and solicit feedback vs. wait for one to be handed down.

Note, I’m not suggesting there’s a single universal definition for what your mission/scope should be. It’s always company-specific and needs to complement the scope of other teams.

Format

Mine is a single slide. It includes:

• A single mission statement that summarizes our team’s role in the business.

• Three pillars that capture our scope - the ways in which we deliver that impact.

In my company, the role of ops is broad and performance-oriented. Our efforts need to be aligned with the success of our teams. So I wrote the mission to reflect this performance-orientation.

Alignment

It’s obviously not enough to just write it down - you need other teams to agree and validate your mission and scope.

This again may be relatively simple or very complex depending on your organization.

At minimum, I would solicit input from your GTM leadership, direct manager, and operations leadership as applicable.

You also need to socialize this with the revenue teams you support so that THEY are crystal clear on what you do and how you’ll partner to gether.

Practical example: 

When I started at my current company, I was building the team from scratch. 

I wrote the mission and scope with relative autonomy, validated it with my boss (the marketing leader) and then presented it to the marketing team along with my first roadmap.

I now include it continually in other documents, including the onboarding presentation that all new hires go through. 

If I was working at a 10,000 person company, the process would likely be quite different. 

Resources

I highly recommend RevOps FM episode #7, Habits of a Highly Effective COO, for one of the clearest definitions of the role of ops that I’ve heard.

Reminder - you can get 20% off for life if you subscribe to this newsletter during the launch period.

Get 20% off forever

Everyone is talking about how transformative AI is, but the information is very piecemeal.

There are tons of app-focused listicles or cool tricks for Chat GPT - but if you’re like me, you don’t have time to go LOOKING for ways to put apps to work. You have business problems to solve. 

I hadn’t yet seen anyone take a comprehensive look at the business of marketing, breaking it down into the fundamental jobs to be done, and creating practical guidance for marketers on incorporating AI into their daily work in each area (where it’s even possible). 

So that’s what set out to do. I created an Airtable Base to document all the use cases I’ve identified so far, and I’ll keep adding to it as time allows.

Access the Airtable Base

How is this different?

The main thing that makes it special is that it starts with marketing use cases - rather than with tools - and identifies where AI can help with each one. 

It then looks at some apps that can support each use case and provides an analysis of both potential feasibility as well as potential impact. 

Not every use case is a great fit for AI, and identifying where to apply this technology is just as important as knowing how to do it. So consider it an opinionated guide.

To start with there are ~35 use cases and over 40 apps, and to be honest I could have kept going, but I do have a day job. 😉

It’s a v1, and I hope to keep it updated over time.

Suggestions Welcome

I’ve certainly missed many things, so if you have suggestions for additional use cases, types of AI activities, or noteworthy apps that should be added, feel free to comment on this post or send me an email (justin at revops dot fm).

Note, I’m not aiming to make this a comprehensive guide to every AI tool out there. I aimed only to include a representative sample of the best apps for each use case. But I’ll happily add something that’s unique and valuable.

Stay Tuned for the AI Episode

I’ve also recorded a feature episode focused on AI, with deeper analysis and commentary on the marketing use cases that have me most excited, where I think AI is less appropriate, and my outlook on AI in general.

Edit: it’s live!

Edit: As of January 2024, Google has changed their sender policies, making it clear that the requirements I describe below are specific to senders targeting Gmail, not Google workspace.

This article still reflects my understanding of the available information as of the time of publication.

For the most recent information, I recommend Dave Rigotti’s post here.

The dynamics of outbound are changing.

This has implications for your tools, your team structure, and your strategy.

We can’t send cold emails the same way in 2024.

These changes are driven by two converging issues:

• Decreased efficiency of the motion

• Restrictions from the underlying platforms used to send cold email.

1) Reduced Effectiveness of the “Predictable Revenue” Outbound Playbook:

Everyone’s inbox is saturated with 22-year-old BDRs asking for a meeting.

For a long time, this was the way.

Now many companies using this methodology have seen their response rates plummet. Once those rates dip beneath a certain threshold, the math no longer works.

2) Google / Yahoo Announcements on Stricter Spam Policies

On October 3rd, Google and Yahoo jointly announced new email sender policies.

The most significant change is a far stricter requirement to keep spam complaints low. If you hit a threshold of 0.3% - meaning that your company receives 3 or more spam complaints for every 1,000 emails sent - you may may be penalized.

In the worst-case scenario, your emails could be blocked completely. This means you would lose the ability to send ANY EMAILS to Google / Yahoo accounts from your corporate domain.

• No marketing emails

• No emails from AEs

• No emails from CSMs

This would be catastrophic for any company.

Now, the details of how these penalties will be applied (for a single infraction? three strikes? only for large offenders?) are not clear. I suspect that nobody outside Google / Yahoo knows precisely how it will work.

And while it seems unlikely that a single incident of reaching the 0.3% threshold would cause a total block, it’s still an extremely low bar to clear for outbound.

What does all this mean for ops teams?

Disclosure1 and disclaimer2.

I think job #1 should be risk mitigation for your corporate domain, whether or not you’re doing outbound.

Even a small chance of a catastrophic risk should cause 🚨🚨🚨 to flash in your mind.

You might be fine if you do nothing, you might not. But the way I see it is: I don’t want my corporate email infrastructure to be destroyed on my watch.

Here’s a punch list of things to consider.

Validate Basic Authentication

Most of the requirements in Google’s email sender guidelines are things you should already be doing, but they may have been missed or set up incorrectly.

Create a checklist for each of these items3 across each sending platform and validate them.

• SPF authentication

• DKIM authentication

• DMARC

These three items can be easily checked using MXToolbox Email Headers Analyzer.4 The video below shows you how.

There are some other technical requirements that your ESP should handle for you, but review the list in detail in case they require some action on your part.

Humans of MarTech also has a useful episode that goes into detail here.

What does “by sending platform” mean?

It’s not enough to only make sure that your Marketo or Pardot instance is up to scratch.

You also need to validate settings on your corporate email provider (e.g., Google Workspace or Microsoft365 account), as this is where your Salesloft/Outreach emails get sent from.

If your company makes a product that sends transactional emails from your corporate domain (e.g., using Amazon SES or SendGrid), you need to look at that too.

Google / Yahoo won’t differentiate between emails sent from marketing / sales / product - a penalty will affect the whole company. So you need to tackle this as a team.

Ensure You Have 1-Click Unsubscribe

This DOESN’T mean the unsubscribe link in your footer (although you should have that).

It refers to the use of List-Unsubscribe headers, which enables the “Unsubscribe” link you see in the screenshot below:

There are two ways of implementing these headers:5

1. mailto: This option specifies an address that receives a pre-constructed email when the user clicks the link. It is the sender’s responsibility to monitor and action those emails.

2. POST: This option submits a POST request to a web URL, unsubscribing the user automatically.

   

As far as I’ve been able to discern, it’s best practice to include both mailto and POST headers. The mailto option has wider client support, but the Google sending guidelines specify the POST method as per RFC8058.

The good news here is that all major marketing automation platforms either include or provide an option to add these headers automatically, although most appear to only support the mailto option at this time. (They typically process the unsubscribe emails for you automatically on the back-end.)

I expect support for the POST method will come soon.

• Marketo

• Hubspot

• Pardot

• Eloqua

If you’re sending subscription-based messages from other services that may not add these headers automatically, you should make sure to configure them.

Spam Complaint Rate

This is the biggest cause for concern.

It’s not a hypothetical. I reviewed the Postmaster tools for one company with typical sending practices and a small outbound team, and they had met or exceeded the 0.3% threshold eight times in the past 120 days.

Again, it’s not clear whether that would be enough to trigger a major penalty. But I think playing it safe and aiming to never reach that threshold is the responsible thing to do.

Here are some ways to consider reducing your spam complaint rate.

Follow Good Opt-In Marketing Practices

For marketing, these best practices are well known.

Have an opt-in database, don’t upload purchased list into your MAP, honour all unsubscribe requests, don’t over-communicate, and age out people who haven’t engaged in a very long time.

Restrict Outbound on Your Corporate Domain

Cold outbound emails are likely the biggest cause of spam complaints, especially if messages are irrelevant, targeting is poor, or sequences are aggressive.

I think it simply won’t be possible to have large BDR teams doing cold outbound on the corporate domain without exceeding this threshold.

If you choose to continue to send cold emails from your corporate domain, they should probably be:

• Few in number: both in terms of the number of reps sending and the total they send per day. 50 per day per inbox seems to be common a rule of thumb, but I suspect it’s not very scientific.

• Well-targeted: sent to relevant people.

• Personalized: so they don’t feel spammy or generic.

• Non-aggressive: avoiding multiple follow-ups, breakup emails, and whatever else pushes people to the brink and makes them rage-click the spam button.

Implement Multi-Domain Email Infrastructure for Outbound at Scale

You’ll often see it suggested to use a separate domain for your outbound activities, but it’s generally not explained exactly how to set that up.

The guidance below is summarized from resources shared by Jesse Oullette, who is widely regarded as the authority on cold email deliverability. If you want to binge his stuff, go here.

So what might that setup look like?

• Multiple domains6 per campaign (e.g., tryyourcompany.com, getyourcompany.com, yourcompany.io, etc.) - each in a totally separate Google or Microsoft workspace

• Domain warming

• Max 2 sending addresses per domain, 

• Unified inbox to enable reps to access all these accounts in one place

• 50-100 emails sent per inbox daily

• Automated AI personalization (AI researches each prospect and writes custom text)

• AI “Spintax” to further increase uniqueness of each send

• Waterfall email validation to keep bounce rates low

• AI random sending throughout the day

There are sequencing tools built for modern outbound (smartlead.ai, lemlist.com, uptics.io, etc.) that include/support these features.

Now, let’s be clear: once you pursue this sort of thing, you’re in the Wild West.

There’s no question it’s a strategy that deliberately subverts the rules of the underlying technology (otherwise, you wouldn’t need so many domains).

I’m not advocating for it or saying you should do it.

But we also have to recognize that outbound is a major part of the GTM strategy for many companies. It’s not going to just go away. And I expect many will pursue this as a way of doing outbound at scale while minimizing risk to their corporate domain in 2024.

What’s the outlook for outbound going forward?

Everyone Hates It, Everyone Does It

No CEO wants to receive cold calls or outbound emails. But a vast majority7 of SaaS companies make those calls and send those emails, many of them using outbound as their primary GTM motion.8

Why? Well, historically the math has worked in many cases.

For every 995 emails that are ignored or land in spam, 5 might reach people with a legitimate interest and who agree to a meeting.

As long as companies can find a way to achieve significant growth via outbound at a unit cost less than paid channels, they will continue to pursue it.

But the way in which that happens will have to evolve.

Quality AND Volume?

There’s traditionally been two approaches to outbound:

1. Target fewer accounts with a high level of manual personalization. This is the more socially acceptable and “best practice” approach.

2. Target a high volume of accounts with relatively little personalization and high level of automation. Kind of like…spam. A lot of companies do it.

The next wave of outbound is likely to be one in which automation and personalization are not mutually exclusive. Companies will use AI to automate research and personalize emails at scale.

To be transparent, this idea makes me cringe as a buyer.

I don’t want to receive artificially-generated emails referencing publicly-available data points in an attempt to deceive me into thinking that a real person took the time to research me. I expect most people don’t.

However, at what point does the AI capability to personalize meet or exceed that of the average BDR (if it hasn’t already)? And when it does, how could any company justify paying a BDR to do that work?

I’d like to think that the best sales pros will still be able to send messages that feel hand-crafted and unique, in ways that AI can’t replicate.

For example, a piece of mass-produced budget furniture may look similar to a high-end piece, but the high-end piece feels hand-crafted in imperceptible ways, whereas the budget piece feels mass-produced.

We’ll see whether I’m being naive.

Predictable Revenue 2.0

So I think we may ultimately continue to see those two streams of outbound:

1. Very high-quality outreach - primarily from more mature and business-savvy consultative sellers and not junior BDRs. The outreach may lean heavily on high-quality personalized offers - e.g., a custom video analyzing the prospect’s website - that would be difficult to automate at scale.

2. Auto-personalized, high-volume emails that do a decent job imitating it. See Scott Martinis’ post here or Adam Robinson’s post here for convincing takes on what Predictable Revenue 2.0 looks like. Totally different tech stack, totally different org structure.

Companies will need to invest in 2.0 architecture and skillsets OR hire a specialist agency to run it for them.

Of course, all tactics have a lifecycle. As more companies jump on a bandwagon, the approach loses freshness and originality, people block it out, it becomes less effective…and tactics need to shift yet again.

The underlying principles of understanding your customer and providing value are what remain the same.

Many talented ops leaders struggle with communication.

In this post I explain the most likely reason for communication issues and how to fix them.

Common Symptoms of a Communication Problem

• Feels like execs are tuning out your presentations

• Alternately, listeners start nit-picking or going on tangents

• Requests or proposals are full of friction, you get lots of push back, everything feels like pulling teeth

The Issue

Ops people are system thinkers. We’re trained to work a problem rigorously from one step to another.

This makes it natural to structure presentations the same way.

Example:

• Lots of context and detail about the problem

• Step-by-step walk through of what we did to investigate it

• Lots of supporting detail on how we arrived at our conclusion

• Conclusion!

The problem here is that we confuse the mental journey with arriving at the answer with the best way to communicate that answer.

The two are not the same - in fact, they need to be inverted.

An executive's most precious resource is TIME. They trust you to go on the journey to get the answer. (Or at least, the want to trust you.)

Ultimately an exec wants a clear understanding of your conclusion, the main reasons for it, and access to details to feel confident.

If you don’t give them that, they will either

• Get impatient / frustrated (“why won’t they get to the point?”)

• Feel a lack of confidence and start diving into or challenging small details along the way, because they’re not clear on your overall proposal and argument

The Solution

I use a method called "The Pyramid Principle," invented by Barbara Minto at McKinsey. They teach it to all new associates.

My current COO is an ex-McKinsey consultant, and we make it a standard part of our company onboarding too (where I learned about it).

The Pyramid Principle teaches you to focus and structure your thoughts, so you can communicate complex ideas QUICKLY and in a way that inspires confidence.

Here’s how it works.

Start with the Answer

Give a quick problem statement (just enough to orient the person) and then your recommendation

• Problem: Our CRM has thousands of duplicate contact records.

• Recommendation: We should procure a data management platform to mitigate dupes and maintain data health.

By focusing on the answer, you’ve made it crystal clear what you recommend. You now focus the audience on understanding why you’ve recommended this instead of getting lost on tangents.

Summarize Supporting Arguments

Next you want to provide your main supporting arguments in summary. These should be crisp statements that you will back up later with more detail.

• Argument #1: Duplicates cost us 1,000 hours of lost productivity across the sales org yearly.

• Argument #2: Duplicates cost us $50,000 in wasted spend on marketing automation.

• Argument #3: A data management platform is the most cost-effective solution to this problem.

This step allows you to clearly position your main arguments in the listeners mind.

Sometimes, this alone is convincing. The exec trusts you have data to back up your claims - you’re good to go.

Provide Supporting Detail

Lastly, you can provide supporting detail to back up each of your claims, logically-ordered together under each main argument.

Argument #1: Lost Sales Productivity
• Sales people spend 5+ mins managing dupes every time they work a new lead.
• We often have multiple sales people working dupes, leading to extra lost time.
• This happens 5-10 times per week with each incident costing 30 minutes of sales and ops time.
• [show the math for how you reached your estimate of 1,000 hours]

Impact

Overall this method will sharpen and clarify your thinking and help you make sure you're confident in your ideas.

That confidence will transfer to your audience, transforming your communication and how you're perceived by executives.

It will be far easier to get a "yes" on whatever you're recommending. It really is magical once you train yourself to use it.

This doesn’t mean you’ll never get pushback or that 100% of your requests will be approved (if only!).

But discussion tends to be much more productive - focused on clarifying an argument or suggesting additional points to consider.

Resources

• The Pyramid Principle: Logic in Writing and Thinking - This is Barbara Minto’s book.

• How to Use The Pyramid Principle (Barbara Minto) - A brief and helpful video that goes into more detail on how to apply the framework.

When I got my first Marketo instance, I thought it was the coolest thing in the world.

As a non-programer, I could create these amazing, complex workflows and do almost anything. It was like a new super-power.

The problem was, I leaned into the tech too much.

My interest became intellectual. I was chasing the thrill of doing the next cool thing, but losing focus on whether it was moving the needle for the business.

This came home to roost when I was in a meeting with Mitch Solway, my boss at the time.

I commented how a particular idea was "interesting." Mitch said to me, "Justin, I want you to think less about 'interesting' and more about 'impact'."

😓 😬 😩

It hit home hard. And it made me really question how I was wired, what my motivations were.

Ultimately, I realized Mitch was right.

It wasn't that my passion and intellectual enjoyment of tech was BAD. But in a small-team startup environment, we couldn't afford to have someone pursuing science experiments for their own sake. We NEEDED everyone to be laser-focused on moving the business forward.

I've thought about this often over the past ten years. For a while I pursued a consulting career where the impact I delivered was THROUGH the technical innovations I could achieve. And I think this is a perfectly viable path for someone who gets the most satisfaction from climbing technical mountains.

But after some time, I realized I DID also crave the experience of impacting business results directly, which fortunately I could do by moving into a leadership position within the agency and eventually back to an in-house role.

A few take-aways from this experience:

The best feedback is sometimes painful

As Mitch notes in the video clip, the sting tells you it's true.

(Obviously feedback still needs to be delivered with kindness / sensitivity.)

Be aware of your motivations

You need to be self-aware about what motivates you and gives you satisfaction.

These are the factors that what will drive you to do your best work and produce happiness in your job.

Align your role with your passions

I was in a phase of my career where I really wanted to work with systems and technology. So I chose a role where I was rewarded and celebrated for innovating in that sphere.

Had I stayed in-house at that time, I don't think I would have enjoyed the same success.

When I reached a point where I wanted to do great work more by impacting business results directly, I was able to shift my role to do it.

Neither is "better" or "worse" - the key is to have alignment between your passion and job expectations.

Ops needs to be impact-oriented

At the functional level, I believe strongly that ops should be impact-oriented.

It's the only way we'll deliver on the right things for the business.

If we're pursuing projects for their own interest or simply fulfilling requests and not focused enough on how we're impacting the business, we won't be the growth-driver that we need to be. 

In this post I want to look at

• what it is

• did it work

• if so, why

• did it fail

• if so, why

• what we should take away

Lead Gen/Inbound Marketing

The term inbound marketing was popularized by Hubspot around 2005. In parallel, companies like Marketo developed and adopted a similar framework.

The principles were:

• Outbound marketing (cold calls and emails) are interruptive; inbound marketing educates your market with content (e-books, blog posts, webinars, infographics, etc.) and builds trust.

• Using acquisition channels like SEM, SEO, social media, etc., inbound marketers drive traffic to landing pages with forms to trade this educational content for contact information, building an email database of “leads”.

• Not all leads are ready to buy. So you don’t send them all to sales. For non-hand-raisers, you attempt to build a long-term relationship by “nurturing” them with more content (e-books, blog posts, webinars, etc.) via email marketing.

• In order to tell which leads should go to sales, you use lead scoring. Scoring evaluates whether leads are a good fit (right company/persona) and are showing buying intent (actively engaging with your content). If they reach a threshold, they become a marketing qualified lead (MQL).

• MQLs are assigned to sales — usually to some sort of SDR/BDR function — for qualification.

So, did it work?

It’s hard to deny this was an effective framework in its heyday (late oughts, early tens).

Hubspot used (and uses) their own methodology and grew to a 23 billion market cap.

Marketo followed this process, went public, private, and eventually sold to Adobe for 5 billion.

(You can hear Marketo CMO Jon Miller describe their early revenue process at about [10:45] in the episode below.)

Why It Worked

Inbound marketing recognized a few essential truths:

• Outbound sales is typically very annoying / interruptive.

• People buy from people/companies that they trust and respect.

• High-quality, educational content is effective at building that trust and respect.

• It’s more effective to send sales leads that are ready to buy today then to have sales cold call uninterested people.

Did it fail?

Although Hubspot appears to be doing just fine with it for SMB, lead gen is certainly déclassé today.

Most B2B tech companies I’ve observed still have an MQL-based waterfall for inbound. Abundant cheap capital and a “grow-at-all-costs” mindset could mask the inefficiency of this strategy for a while, but not anymore. The constant layoffs we see are likely a partial indication of poorly-designed revenue processes (among other factors).

In recent years the lead gen model has taken the biggest beating from Refine Labs CEO Chris Walker, who posts frequent (and justified) critiques of the “MQL Hamster Wheel.”

Overall, while I don’t have access to the same broad data set Chris does, my general observation is that a lead gen model is a less efficient and less effective GTM framework today, even if some companies can still achieve costly growth using it.

Issues with the MQL Model

• Still interruptive: inbound marketing claims to engage with value vs. interrupting people. But it still sneaks outbound sales in the back door. It just waits until people come inbound before beginning the outbound sales process.

• Saturation: As playbooks achieve hegemony, the market is saturated by those tactics. It feels generic, and you lose the ability to build trust as buyers understand they are in a sales process masquerading as education.

• Junk content: Quality content is the lifeblood of this process. But companies thought they could replicate the workflow and achieve success with thin content that lacked original insight. This won’t work. You need a unique point of view and content that people actually want to consume.

• Ineffective nurturing/scoring: The easy part of inbound marketing is capturing email addresses. The harder part is effectively nurturing the vast majority of leads that aren’t in market today. Most companies just send everyone to sales or have poorly-calibrated scoring models that don’t produce reliable sales leads. Email nurturing could be a powerful way to create demand, but I’ve seen few companies do it well.

• Focus on measurability: Waterfall metrics box marketing teams into specific, highly measurable activities. CEOs, boards, and VCs have come to expect these metrics — our ecosystem is built around it. This has wired our GTM around activities that can be easily measured vs. activities that are highly effective (not always the same thing).

• Weak brand-building: As a corollary of the point above, companies don’t focus on less-easily-measured brand building / top of funnel activities that can create demand. So they have weak brand and are forced to pay top dollar to compete for the small % of companies in market today. It’s an addiction spiral that’s hard to break.

You can see Jon Miller and I discuss these points in more detail in the clip below.

Take-Aways

Over the last few years, Chris Walker has articulated the concept of “creating demand” as an alternative to the MQL/lead gen process.

Demand creation involves educating the market at scale — sharing thought-leadership and value-added content and using some paid channels to communicate key messages to a broad audience.

This builds trust, which then causes people to come directly to you when they are ready to buy.

Notice anything familiar? The same principles of educating and building trust are at the core.

However, the application of those principles has been adapted to a modern context (focusing on un-gated sharing on native platforms vs. lead generation) and it avoids the obsession with linear measurability that holds many teams back.

At the end of the day, GTM tactics and revenue processes will inevitably evolve based on buyer behavior, shifts in technology, and market saturation. But certain core principles remain the same.

Jon articulates his marketing axioms in the video above. These have also held true for me over the last 15 years:

• Understand your audience, their needs, their values

• Talk more about your audience and less about yourself

• Create value before you ask for value

• Have a differentiated point of view — if you try to be something for everybody, you’ll end up something for nobody