<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Vadim Koenen</title>
    <description>The latest articles on DEV Community by Vadim Koenen (@vkoenen).</description>
    <link>https://dev.to/vkoenen</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3943023%2F613e906f-4c28-48aa-8db5-ecc388c4a56a.png</url>
      <title>DEV Community: Vadim Koenen</title>
      <link>https://dev.to/vkoenen</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/vkoenen"/>
    <language>en</language>
    <item>
      <title>Why most Marketo audits start at the wrong layer</title>
      <dc:creator>Vadim Koenen</dc:creator>
      <pubDate>Thu, 21 May 2026 02:37:21 +0000</pubDate>
      <link>https://dev.to/vkoenen/why-most-marketo-audits-start-at-the-wrong-layer-npb</link>
      <guid>https://dev.to/vkoenen/why-most-marketo-audits-start-at-the-wrong-layer-npb</guid>
      <description>&lt;p&gt;A lot of Marketo "audits" start at the campaign layer because that is where the visible work happens. New programs. A cleaner folder structure. A tightened tokens list. Smart-list filters rewritten so they actually reference fields that exist. The work shows up in screenshots, which makes it easy to scope, easy to bill, and easy for marketing leadership to point at when someone asks what we have been doing for the last six weeks.&lt;/p&gt;

&lt;p&gt;I have run a lot of these audits. The output is usually clean. The campaigns run faster. The folder structure becomes navigable. The documentation gets a refresh. And then three months later, the marketing operations lead is asking the same questions they were asking before the audit started, and the VP of marketing is wondering why the numbers feel off again.&lt;/p&gt;

&lt;p&gt;This piece is about why that happens, and how I scope Marketo work differently now.&lt;/p&gt;

&lt;h2&gt;
  
  
  What the standard audit is measuring
&lt;/h2&gt;

&lt;p&gt;The conventional Marketo audit measures the instance. Smart campaign QA findings. Deprecated token usage. Programs that have not fired in ninety days. Fields with low fill rates. Suppression segments that overlap. Lifecycle programs that do not track everyone they should. The deliverable is usually a spreadsheet with severity ratings and effort estimates, and the cleanup follows naturally from that list.&lt;/p&gt;

&lt;p&gt;This is useful work. I am not arguing against it. The reason it feels right is that it produces tangible artifacts: a faster instance, fewer broken things, a documentation refresh that the operations team actually wants to read. If your Marketo instance has been growing for five years and nobody has rationalized it, you do this work, and the symptoms get better for a while.&lt;/p&gt;

&lt;p&gt;The problem is that the symptoms get better and then come back. Not because the team is sloppy. Because the audit treated the instance as if it were the system. It is not. Marketo is the system's enforcement layer. The system itself — what marketing is actually doing this quarter, who owns each lifecycle transition, what counts as a qualified handoff right now — lives somewhere else, mostly in nobody's head.&lt;/p&gt;

&lt;h2&gt;
  
  
  What that measure misses
&lt;/h2&gt;

&lt;p&gt;Here is a clean example. A team I worked with last year had just finished a five-figure Marketo audit. The instance was meaningfully better. Smart lists were filtering on fields that actually got populated. The lifecycle program had been rebuilt from scratch and was working. Suppression logic was documented.&lt;/p&gt;

&lt;p&gt;Six weeks later they called because MQLs were down thirty percent and the VP of marketing wanted to know what had broken in the audit. Nothing had broken. What had happened was this: the new lifecycle program had a stricter definition of MQL than the old one. The old definition had been quietly counting hand-raisers from a webinar series the team had retired in Q4. Nobody noticed at the time because the old smart list was filtering on a field that was no longer being maintained. The audit cleaned up the field. The clean field exposed the gap. The gap was real. The original "MQL number" the team had been reporting for two years was a fiction held together by a stale filter.&lt;/p&gt;

&lt;p&gt;The Marketo audit was technically successful. The operating problem — that nobody had agreed on what MQL meant in 2024, let alone 2025 — was not addressed because it was not in scope. It could not be in scope. It was not on the punch list.&lt;/p&gt;

&lt;h2&gt;
  
  
  A more useful lens
&lt;/h2&gt;

&lt;p&gt;These days, when I scope Marketo work, I spend the first week looking at four things in parallel and writing down where the answers diverge across the team. They are not technical questions. They are about the operating layer that Marketo is supposed to enforce.&lt;/p&gt;

&lt;p&gt;The first is &lt;strong&gt;definition agreement&lt;/strong&gt;. What does each lifecycle stage mean this quarter? Not the documentation. The current consensus. I ask marketing, sales, and RevOps the same five questions separately, and the answers almost never match. Where they diverge is the actual roadmap. The Marketo work flows from those decisions, not the other way around.&lt;/p&gt;

&lt;p&gt;The second is &lt;strong&gt;ownership clarity&lt;/strong&gt;. Who owns the transition from MQL to SAL? When sales rejects a lead, what happens to that person, and who decides? When an opportunity is created but stalls, does Marketo know it stalled, and is anyone supposed to act on that? Most instances have the technical capability to handle these transitions cleanly. What they lack is a person whose job description includes deciding when each one fires.&lt;/p&gt;

&lt;p&gt;The third is &lt;strong&gt;explainability&lt;/strong&gt;. Pick a lead from last quarter who reached MQL and try to reconstruct, step by step, what happened to them. Which behavior triggered the score change. Which campaign produced that behavior. Which smart list grouped them. Why the lifecycle status updated when it did. If the team cannot walk through that story for any given lead in under two minutes, the system is not really a system. It is a collection of automations that nobody can audit.&lt;/p&gt;

&lt;p&gt;The fourth is &lt;strong&gt;sales usability&lt;/strong&gt;. Do the alerts Marketo sends into Salesforce contain enough context for an AE to act on them without rolling their eyes? When the field team gets a "this account is hot" notification, do they trust it enough to drop what they are doing? If the answer is no, no amount of smart list cleanup will fix that. The signal-to-noise ratio is operational, not technical.&lt;/p&gt;

&lt;h2&gt;
  
  
  How this changes the recommendation
&lt;/h2&gt;

&lt;p&gt;If you score a team on those four dimensions before the audit, the recommended scope changes significantly. A team strong on definitions and ownership but weak on explainability has a tooling problem. They need a real Marketo audit, plus a documentation rebuild around how decisions are encoded. A team weak on definitions and ownership but strong on explainability has the opposite problem. The audit will produce clean cosmetics on an unstable foundation, and the symptoms will come back inside a quarter. Different problem, different work.&lt;/p&gt;

&lt;p&gt;The most expensive mistake I see is teams running a tooling audit when the operating layer is the real issue, because the tooling audit produces visible progress, leadership feels good for a quarter, and the underlying disagreement quietly compounds. By the time someone notices that the "improved" lifecycle program is reporting fictional MQLs, the audit budget is spent and there is no political appetite to start over.&lt;/p&gt;

&lt;h2&gt;
  
  
  The diagnostic
&lt;/h2&gt;

&lt;p&gt;The diagnostic I leave teams with is simple. Pick a deal that closed-lost last quarter. Walk through the system's view of that account, in chronological order, from first touch to the loss. If anyone in the room is surprised by something the system did or did not do, that is the real audit scope. The instance cleanup is downstream of resolving those surprises.&lt;/p&gt;

&lt;p&gt;If any of this sounds familiar, more notes on how I scope Marketo and marketing automation work are over on the owned page: &lt;a href="https://vadimkoenen.com/marketo-consultant/" rel="noopener noreferrer"&gt;vadimkoenen.com/marketo-consultant&lt;/a&gt;.&lt;/p&gt;

</description>
      <category>marketingautomation</category>
      <category>marketo</category>
      <category>revops</category>
      <category>marketingops</category>
    </item>
    <item>
      <title>RevOps alignment is an operating-model problem, not a tooling problem</title>
      <dc:creator>Vadim Koenen</dc:creator>
      <pubDate>Thu, 21 May 2026 02:37:20 +0000</pubDate>
      <link>https://dev.to/vkoenen/revops-alignment-is-an-operating-model-problem-not-a-tooling-problem-6p3</link>
      <guid>https://dev.to/vkoenen/revops-alignment-is-an-operating-model-problem-not-a-tooling-problem-6p3</guid>
      <description>&lt;p&gt;Most RevOps "alignment" projects are tooling projects in disguise. New routing rules. A cleaner scoring model. A tighter Salesforce report. The work happens at the system layer because that is where it is easiest to ship — a routing change has a date, a pull request, a release note, a slide for the next QBR. The system layer is legible.&lt;/p&gt;

&lt;p&gt;I have been brought in for a lot of these projects. The output is usually good. Routing improves, scoring recalibrates, the lifecycle program stops double-counting opportunities. And then about a quarter later, the same RevOps lead is on the phone asking why marketing and sales are arguing again, and whether maybe a different attribution model would help.&lt;/p&gt;

&lt;p&gt;It would not. The problem was never attribution.&lt;/p&gt;

&lt;h2&gt;
  
  
  The standard alignment audit
&lt;/h2&gt;

&lt;p&gt;The conventional RevOps alignment project starts with a tool inventory. What systems do we have. What are they doing. Where are the gaps. A spreadsheet emerges, severities are assigned, work is sequenced. The first ninety days fix the visible problems — the SLA on lead routing, the broken Marketo sync, the report that has been wrong since Q2.&lt;/p&gt;

&lt;p&gt;This is real work and it should be done. Cleaner tools make every downstream decision faster. But the audit treats the stack as if it were the alignment, and the stack is not the alignment. The alignment is upstream of the tools, in a layer most audits never touch.&lt;/p&gt;

&lt;h2&gt;
  
  
  What that audit misses
&lt;/h2&gt;

&lt;p&gt;The layer that actually matters is the one where marketing, sales, and finance disagree without realizing it. The team agrees on a metric in a meeting. The metric gets shipped into Marketo or Salesforce. Six months later, the original meaning has drifted, and three different people are pulling reports from three different definitions of the same number, each one technically defensible.&lt;/p&gt;

&lt;p&gt;A small example. A team I worked with had agreed in Q1 that an MQL meant a contact with a score above sixty plus a "Marketing-Qualified" stage transition. Q2, a new VP joined and shifted the team's focus toward intent data — accounts hitting a 6sense surge score. The lifecycle program was never updated, but the QBR slides started reporting "qualified accounts" as the primary metric. By Q3, the SDR team was working two different lists derived from two different definitions, and the VPs of marketing and sales had each built reports defending their own number. The system had not broken. The agreement had drifted, and the system was still enforcing the old one.&lt;/p&gt;

&lt;p&gt;Cleaning up Marketo would not have fixed this. The agreement needed to be re-formed first.&lt;/p&gt;

&lt;h2&gt;
  
  
  A more useful lens
&lt;/h2&gt;

&lt;p&gt;These days, when I scope a RevOps engagement, I spend the first week not in the tools but in conversation. I ask marketing, sales, and the SDR team the same five questions separately, and I write down where the answers diverge. The questions are operating ones.&lt;/p&gt;

&lt;p&gt;What counts as a qualified opportunity this quarter, and who decides. When marketing hands an account to sales, what is sales actually supposed to do in the first forty-eight hours. When sales rejects an account, what should happen to that person — back to nurture, hard suppression, recycled in ninety days, or quietly disappeared. When an opportunity stalls, who notices and what fires. How does the team agree that a quarter went well.&lt;/p&gt;

&lt;p&gt;The answers almost never match. The list of disagreements is the actual roadmap. The Marketo and Salesforce work is downstream of resolving those disagreements — once the team agrees on what each transition means and who owns it, the tooling changes are obvious. Without that agreement, the tooling changes are guesses dressed up as best practices, and the next vendor inherits whatever assumptions you wrote into the system.&lt;/p&gt;

&lt;h2&gt;
  
  
  How this changes the recommendation
&lt;/h2&gt;

&lt;p&gt;If you score a RevOps engagement on this dimension before you start, the scope changes. A team strong on operating agreement but weak on system enforcement has a tooling problem — they need clean execution against decisions they have already made. The audit works. A team weak on operating agreement but strong on system hygiene has the opposite problem. Their stack is fine. What they need is a facilitated week where the leaders agree on what they were actually trying to measure, and the system gets rebuilt to enforce that agreement honestly.&lt;/p&gt;

&lt;p&gt;The most expensive mistake I see is teams running the tooling audit when the operating layer is the real issue. The tooling audit produces visible progress, leadership feels good for a quarter, and the underlying disagreement quietly compounds. By the time someone notices that the new routing rules are routing leads into a definition nobody believes anymore, the audit budget is spent, the trust between marketing and sales has eroded, and the next RevOps engagement inherits a more complicated problem than the one it sold against.&lt;/p&gt;

&lt;h2&gt;
  
  
  The diagnostic
&lt;/h2&gt;

&lt;p&gt;If your team cannot answer five specific questions about a closed-lost deal from last quarter — why that account moved when it did, what marketing did, what sales did, who decided to disqualify, and what the system said about the decision — the issue is not the stack. No CRM, no MAP, and no scoring model substitutes for an agreement nobody has written down.&lt;/p&gt;

&lt;p&gt;A clean Salesforce instance under a confused operating model produces faster, more confident bad decisions. The cleanup that matters is the conversation.&lt;/p&gt;

&lt;p&gt;If you want more on how I scope and run RevOps engagements, full notes are on the owned page: &lt;a href="https://vadim-koenen.github.io/revops/" rel="noopener noreferrer"&gt;vadim-koenen.github.io/revops&lt;/a&gt;.&lt;/p&gt;

</description>
      <category>revops</category>
      <category>marketingops</category>
      <category>gtm</category>
      <category>salesforce</category>
    </item>
  </channel>
</rss>
