Weekly insights about GTM effectiveness, building brand reputation, and AI adoption.
I drank the GTM Kool-Aid like every other marketer.
For years I ran the playbook and didn’t question it. I believed the dashboards. I treated attribution as evidence, measurement as truth. I knew B2B buying was messy, then built plans that assumed it wasn’t.
Then I started writing Achim’s Razor, hosting a live show with a guy who keeps me honest, and co-writing with someone who walks into the same kind of wrong turns I do.
The person I’ve had to correct most often turned out to be me.
Early in my conversations with Mark Stouse, CEO at Proof Causal Advisory, I said something that went kind of like this, “That correlation is why this happened.”
Mark didn’t mince words.
No. Let me stop you right there. Why something happens is not correlation. That’s causation. One is a cause. The other is an effect. Don’t confuse the two.
Marketers do this all day. Two lines move together on a chart and we call it proof. Opens went up, pipeline went up, so the campaign worked. Except we rarely know whether one caused the other, and most of the time we never check. We just needed a number to point at in the meeting.
That correction stayed with me because I hadn’t made an obscure analytical mistake. I’d made a common marketing one. I had dressed up an observation as proof.
Nobody made me see this one. It was an epiphany.
We are all buyers and sellers. As buyers, we block emails, screen calls, ignore the “just circling back” follow-up, tell the rep we’ll think about it to get off the phone, change our minds, and put off deciding for months, if at all. We are impossible to sell to.
Then we sit down to build a campaign and forget every bit of it. We write the nurture sequence we’d delete. We plan the cadence we’d screen. We build for a buyer who behaves nothing like us, because it’s more comfortable than building for the one who behaves exactly like us.
We also do it out of survival. We need that job. So we don’t rock the boat.
I ran those campaigns for years without noticing the contradiction. The gut check I use now is one question: would I answer this if it landed in front of me? If the honest answer is no, another nurture step won’t save it.
Gerard Pietrykiewicz and I write about AI adoption together. What’s odd is how often we reach the same lesson without comparing notes first. This one we both walked into on our own.
I was letting ChatGPT run down a rabbit hole on a GTM plan for a client. The output looked thoughtful and confident enough to feel finished, but something felt “off”, which should have made me more cautious. Then I remembered something Mark does: he plays different AI tools against each other to catch where each one is hallucinating. So I dropped the ChatGPT output into Claude, then Gemini, and vice versa.
All three had roughly the same information and produced plausible answers that contradicted each other on points that mattered. A few rounds later, the plan was more credible than the one I’d been ready to ship. The disagreement forced me to inspect the reasoning and provide further context instead of taking the output at face value.
AI can be wrong. My bigger mistake was handing the decision itself to the tools. One AI answer is not a second opinion. Three don’t make the machines accountable — they make the disagreement visible so I can inspect the assumptions and make the call. Human in the lead. AI in the loop.
Gerard and I wrote that reframe up in Human in the lead. No one else in the loop. What I didn’t cover there was how I did it: don’t trust one model’s confident answer. Make them argue.
For about twenty years, GTM got very good at measuring what’s easy. Clicks, form fills, MQLs, sourced pipeline, attribution models with confident arrows. We called it proof, and we optimized for it.
Then the CFO asked for something that survived contact with the P&L, and too much of the evidence fell apart.
GTM confused “measurable” with “true,” and the bill just came due.
Buyer signals get read the same way. Mark and I spent an episode on why they aren’t buyer readiness.
My End of MQLs series, prompted in part by Kerry Cunningham’s “MQL Industrial Complex” argument, followed the same thread. An MQL can hold information. The mistake was the meaning we assigned to it. An MQL tells you someone took an action you chose to score. It doesn’t tell you that marketing created demand or moved a decision. Forget that, and you stop using data to test what you believe and start using it to decorate what you already believed.
Get back to the basics. They’re timeless. Read the books that taught strategy before software vendors repackaged it as a DemandGen fairytale. Then read them again next year. And every year after.
Don’t dig in against AI either. Add it to your toolkit and learn to run it properly. Make it argue with itself. Keep your name on the final call. The skill that lasts is knowing the difference between an answer and a good one.
Then take one campaign or plan you already believe in, and stress test it. Try to prove yourself wrong. It’s cathartic.
This is Razor #100. I went back and reread the first one to see how far off I’d been.
It opens with a TL;DR. It stacks bolded triads. It calls a product groundbreaking and innovative in the same breath. It borrows HubSpot, Slack, and Zoom’s taglines to explain what a value proposition is. It signs off with “No obligation. No pressure.” Half the tells I now edit out of my work are in there. I cringe reading it, which is more or less the point.
A hundred articles, a hundred chances to catch what you got wrong. The first 99 taught me where to cut and how to keep it real.
The biggest one I’m still working on: how little I understood the CFO’s language, and how much it cost me. More on that later.
After more than three decades in this industry, I’m still wrong more often than I’d like to admit. But I’m also still unlearning and relearning.
I hope you are too.
If you like this content, here are some more ways I can help:
Cheers!
This article is AC-A and published on LinkedIn. Join the conversation!
Yet another CFO put it bluntly in a recent conversation with Mark Stouse, CEO at Proof Causal Advisory.
His go-to-market effort wasn’t paying for itself. Not even close. He wasn’t calling his team incompetent. He was just saying the math had stopped working, and everyone in the room knew it.
That’s not one bad quarter. That’s what happens when a GTM system spends years optimizing for signals instead of readiness.
Yes, that’s one more CFO. And it’s becoming more and more common.
Mark and I got into this in our latest Causal GTM Leader chat.
Here’s the recap.
Demand isn’t something a vendor “generates”. It’s intrinsic to the buyer, and it shifts because of things happening in their world: their boss, their risk tolerance, whether they trust vendors generally right now. None of that shows up on a dashboard unless you build it in deliberately. Most GTM teams don’t.
So when Mark and I talk about signals, we’re not talking about bad data. We’re talking about a category error.
A signal is deterministic in the sense that the recorded event happened or it didn’t. Readiness is probabilistic: you’re never certain, only more or less confident. Treating the first as proof of the second is where GTM teams keep losing the thread.
“Buyer Signals” is an attempt at determinism.
GTM teams default to signals because signals feel safer, not because they don’t know better.
We mistake precision of understanding for utility of understanding.
A precise number is comfortable. It looks like proof. But precision about the wrong thing isn’t insight, it’s just a number you can point to in a meeting. And there’s a career incentive underneath it, too: coming up with a new metric feels safer than sitting with the uncertainty that readiness actually involves.
Even a real signal can arrive too late to explain anything.
You launch a campaign right on the first day of the quarter. You are not going to drive any additional deal flow with that campaign within that quarter. It’s not happening... usually it’s three or four quarters later that it starts to really culminate.
This is a common trap many CFOs, like the one from the opening, fall into: months of spend went out on the assumption this quarter’s activity would show up in this quarter’s numbers. By the time the mismatch became visible, the money had already been spent.
Brand carries the longest lag of anything in the GTM toolkit because brand takes time to earn confidence and trust, which is a big part of why it fell out of favor for so long. It’s hard to keep defending spend whose payoff you can’t see for a year. But without it, your GTM has little air cover when future buyers are ready to talk.
One shift that teams underestimate is the stronger role Finance now plays in B2B purchases.
A huge change on the buying side is the role that Finance plays as a policeman. That was not the case pre-COVID.
The functional buyer may still want what you sell without having the authority to approve it.
Budget scrutiny, tighter approval chains, more people with a say before a deal closes — the effect is to slow decisions down and give the functional buyer more time and more reasons to second-guess the purchase.
An account that looks “engaged” by every signal your team tracks can still stall for months once it hits Finance, and no dashboard built around buyer-side activity will show you why.
If a signal only tells you where to look, what would actually tell you a decision moved?
Something closer to a real shift in how the buyer thinks or feels — proof that something moved because of you, not just alongside you. That’s a much higher bar than “they opened the email” or “they visited the pricing page.” It’s also the bar that most GTM systems still don’t meet.
When spend keeps climbing and pipeline keeps shrinking, most GTM teams can point to plenty of activity: campaigns launched, sequences sent, dashboards updated. What they usually can’t point to is evidence any of it moved a buyer’s actual decision. That gap creates the illusion of control: activity looks like progress, whether or not anything is actually moving.
Signals aren’t useless. They tell you where to investigate. The problem begins when teams treat them as proof of readiness.
Pick one account your team currently calls “engaged.”
Ask these two questions and document the answers:
If you can’t answer the first one, you have activity, not proof.
Nobody in your company should understand your customers and your market better than your GTM team does.
There should not be anyone, ANYONE, in your company who is more of an expert about your audience and your customers and the marketplace than you.
Most GTM leaders can’t honestly make that claim, because most of what passes for customer listening is really just sellers gathering enough to close the deal in front of them.
Knowing your market well enough to understand what those signals can and cannot tell you is how you fix the problem.
Missed the session? Watch it here.
If you like this content, here are some more ways I can help:
Cheers!
This article is AC-A and published on LinkedIn. Join the conversation!
My good friend and AI adoption co-writer, Gerard Pietrykiewicz, asked me a question recently. Are you a sheep or a shepherd? Do you own the loops, or are you a piece of one?
My answer was neither.
Sheep and shepherd both assume you’re inside someone else’s structure. One takes direction, the other gives it.
Independent work doesn’t have that structure.
Nobody assigns my tasks. Nobody checks my drafts before they go out. Nobody tells me when the work is off, because nobody’s reading it before the client does. Run through what that actually removes: no performance review, no peer looking over your shoulder, no boss’s gut check before something ships. When you work for yourself, all of that lives in one person. You.
That’s not a complaint. I chose this. But it’s worth calling out because it changes what “adopting AI well” actually requires.
There are two things that can fill it. Your own judgment. Or whatever tool is fastest and easiest at 4pm on a deadline day.
AI is very good at quietly becoming the second one. Especially if you’re someone who’s used to trusting your own read on things. It’s easy to mistake “the AI didn’t flag a problem” for “there is no problem,” when what you actually needed was a second set of eyes (that you don’t have). It’s the same effectiveness-before-efficiency trap that shows up when teams optimize for output over judgment.
Teams have redundancy built in. A colleague catches what you miss, even by accident, even if nobody’s officially checking.
Independents don’t have that. If your own judgment slips, there’s no safety net until the client notices — and by then it’s not a quality problem anymore. It’s a relationship problem.
You’ve probably seen “human in the lead” this year. It’s been framed, repeatedly, as the shift enterprises need to make — humans directing AI instead of just supervising it, so frontline workers stop feeling like a checkpoint on their way out. Fair point, for an enterprise.
But that framing assumes there’s an enterprise to redefine. A team, a hierarchy to reassure. Strip that away and the phrase means something else entirely. There’s no one to lead but yourself. No org chart to redesign around the new relationship with the tool. It’s not human in the loop. It’s human in the lead, except there’s no one else in the loop. Just you, and whatever discipline you bring to checking your own work.
Here’s where it stops being just an independent’s problem.
A go-to-market team (Sales, Marketing, Product, CS) looks like it has the redundancy independents don’t. Someone signs off on the forecast. Someone reviews the campaign brief. Someone technically outranks the person who drafted it. That structure implies a check exists. That’s the same illusion of control that shows up whenever process gets mistaken for oversight.
Often it’s signing off on the output, not the judgment behind it. A VP approving a forecast built with AI assistance is rarely re-deriving the assumptions underneath it. They’re trusting that whoever built it did the thinking. If that person leaned on AI to fill a gap in their own judgment, the sign-off doesn’t catch it. It just adds a signature to it.
That’s not a hunch: a 2026 Grant Thornton survey of 950 executives found 78% lack strong confidence they could pass an independent AI governance audit within 90 days. The structure exists. The proof underneath it usually doesn’t.
Ask the same question, just inside a team: what's genuinely being checked here, and by whom, with the expertise to actually catch a bad call? “Someone outranks me” and “someone is checking this” are different claims. Most org charts only guarantee the first one.
It requires a few specific things, not more willpower.
Lovable used to be the same. Before its MCP server launch, it was cut-and-paste like everything else. Now Claude connects to Lovable directly and can build, iterate on, and deploy my prototypes without me relaying anything by hand. That upgrade also changed what kind of dependency it is. Without it, the prototype doesn’t exist. That’s binary.
Most people never sort their own work this way, and fewer still notice when a tool crosses from one category to the other. Workflow dependency means staying sharp enough to catch a bad output. Binary dependency means knowing exactly how exposed you are if the tool disappears — and that exposure can arrive quietly, the moment a tool gets more capable, not less.
Being your own shepherd is a specific job, independent or not. You have to build the checks a boss, or an org chart, would normally imply deliberately, or they don’t exist.
Start with the sort: go through what you actually use AI for and split it in two: what disappears completely without the tool, and what just gets slower. That should take less than ten minutes. Most people have never done it.
Then ask: who’s actually checking the slower stuff before it goes out? If the honest answer is nobody — whether you’re independent or three levels into an org chart — that’s not an AI problem. That’s the job nobody built.
Human in the lead. No one else in the loop. Nobody’s assigning you tasks, or nobody’s really checking them. Same job either way.
Co-authored by Gerard Pietrykiewicz and Achim Klor. Follow us on LinkedIn, schedule a call with Achim, or contact Gerard if you need help with AI adoption. Subscribe below for more.
This article is AC-A and published on LinkedIn. Join the conversation!
A company cuts its corporate officer layer. AI is doing the work now, the thinking goes, “We don’t need as many decision-makers.” Costs come down. Shareholders cheer.
Then the legal letters arrive.
The people are gone. Accountability isn’t. Under Delaware law and the EU’s upcoming AI Act, fiduciary duty doesn’t disappear when the org chart gets flatter. It gets concentrated in whoever’s still around.
Mark Stouse and I got into this during our recent chat on The Causal GTM Leader. We came in planning to talk about what AI actually costs when companies treat it as free labor. We ended up somewhere thornier: what it costs when companies mistake efficiency for effectiveness. And why that mistake is starting to have legal consequences.
When OpenAI launched publicly, Mark did a word cloud of their launch materials. Efficiency was front and center. In business, efficiency has one meaning: cut costs.
The problem is that efficiency is a derivative metric. It tells you how cheaply you’re doing something. It says nothing about whether that something is worth doing.
You have to be effective first for any cost burden to be relevant, to be acceptable.
That’s not a philosophical point. It’s a decision-making sequence. If you don’t know whether a function, a role, or a workflow is producing commercial outcomes, cutting its cost doesn’t save you anything. It just makes a broken thing run cheaper.
There’s an economic frame that fits here: the Jevons Paradox. When you make something cheaper, and there’s already demand for it, consumption expands until total cost rises. You make content generation cheaper, so you generate more. Your total marketing cost goes up while output quality diffuses. More activity. No more effectiveness.
Gerard Pietrykiewicz and I made the same case from a different angle in AI Agents Are Cheaper Than Unmanaged Work, Not People. The per-prompt cost may be low, but the workflow cost is where it gets away from you.
This is the pattern GTM teams are running into right now. The tool can produce more, so the focus becomes MORE, rather than using the tool to make better decisions. The same argument is at the centre of The Decision Layer: effectiveness has to come before scale, or you’re just running the wrong system faster.
Large companies installed automated applicant tracking systems (ATS) to reduce recruiting costs. Fewer recruiters, faster screening, lower cost-per-hire. Reasonable on the surface.
The problem is the human configuring the system’s keyword filters and screening criteria. Research compiled by Select Software Reviews found that 88% of employers believe they are losing highly qualified candidates who are screened out because they didn’t submit ATS-friendly resumes. In other words, the system’s filters weren’t calibrated to what the role actually required.
Mark made it even more concrete. His wife, an ex-Accenture change-management specialist, applied for a role at a major consulting firm. Her CV was rejected by the ATS. When she connected with someone inside the firm later, they told her, “Oh, that happens all the time, and you’re perfect for this job.”
The talent you didn’t hire is invisible. The savings are on the ledger. That asymmetry shapes every one of these decisions.
If you are spending less money and it’s not effective, it doesn’t matter. You should be spending zero money if it’s not effective.
The ATS example is about recruiting. But the logic applies wherever AI is substituting for human judgment without a validated effectiveness baseline.
Automate what’s proven. Don’t automate the question of whether it’s working.
This is where our conversation went somewhere most AI-and-headcount pieces don’t.
Mark referenced a company (which shall remain unnamed) that significantly cut its corporate officer layer based on the AI efficiency argument. Shareholders have since brought legal action. Those officers held fiduciary duties. When they left, those duties didn’t leave with them.
The more you replace people with bots, the more you’re concentrating liability in the hands of a fewer and fewer number of people.
This is grounded in real law. Delaware’s 2022 amendment to the General Corporation Law affirmed that corporate officers have a duty of oversight and that officers of Delaware-domiciled companies can be held personally liable for negligence, not just bad faith. That covers roughly two-thirds of the Fortune 1000 and 90% of venture-backed companies in the US. As Mark put it in an earlier session: Saying “I didn’t know” won’t protect you.
The EU is moving in the same direction. Under Article 26 of the EU AI Act, deployers of high-risk AI systems — which explicitly includes employment and recruiting tools — are responsible for human oversight, monitoring, and audit logs. That obligation doesn’t sit with the vendor who built the system. It sits with the organization deploying it. Full enforcement kicks in August 2026.
A machine cannot bear legal accountability for a bad outcome. That’s not a limitation of current AI. It’s a structural fact. Someone always owns the decision. Remove the people, and the accountability doesn’t disappear. It redistributes upward to whoever’s left.
Removing the people does not actually remove the responsibility.
The efficiency argument for AI is easy to make. The numbers are visible. The savings are immediate. What’s harder to see is the cost of automating something that wasn’t working in the first place, and the exposure created when the accountability chain has a gap in it.
Before any AI-driven headcount or workflow decision, two questions are worth writing down.
1. Can you prove what’s effective here?
Not what the dashboard shows — what you can causally connect to a commercial outcome. If the answer is no, you’re not ready to automate. Keep investigating.
2. Who owns the decision if it fails?
For every workflow or role you’re considering automating, name the person who remains accountable if the system produces a bad result. If that name isn’t clear before the change, the change isn’t ready.
The decision layer doesn’t transfer to the tool. It can’t. Someone always owns the outcome.
Missed the session? Watch it here.
If you like this content, here are some more ways I can help:
Cheers!
This article is AC-A and published on LinkedIn. Join the conversation!
Co-authored by Gerard Pietrykiewicz and Achim Klor
A story has been making the rounds about an unnamed company that allegedly ran up a $500 million Claude bill in a single month because nobody set usage limits. Every account traces back to the same Axios report, sourced from an unnamed AI consultant — no named company, no invoice, no primary confirmation.
Gerard and I are not treating the $500M as fact.
But we are treating it as a warning.
Whether the $500M number is real is neither here nor there. The recognisable pattern is more important. AI spend can behave less like traditional software and more like cloud spend, where it grows quietly, in places leadership doesn’t see until the bill arrives.
The surface pricing doesn’t help either.
Anthropic publishes Claude pricing in dollars per million tokens, which makes individual usage feel small. What it doesn’t show is how fast the meter runs when there are no guardrails on the workflow.
AI agents retry behind the scenes . They loop. They re-read long context windows. They call tools, spawn more work, generate multiple versions, critique them mulitple times, then generate many more. None of that feels dramatic while it’s happening. It just feels like the agent is working.
Until you ask what the work was for.
This is where the conversation can get lazy.
Someone looks at token costs, compares them with a salary, and concludes agents are obviously cheaper than junior employees. In the narrowest possible sense, that can be true. A bounded task can cost pennies in model usage while a human costs considerably more per hour. The Government of Canada Job Bank puts the median for a computer software engineer at CAD $56.49/hour nationally, CAD $62.50 in British Columbia.
But that comparison ignores what a junior person actually is.
A junior developer — or a junior analyst, or a junior content manager — is someone learning your systems, your customers, your standards, your trade-offs. They ask questions. They make mistakes that require review. They also build context, and over time that context turns into someone who can own work, mentor others, and make better decisions because they understand how things actually fit together.
An agent has its own costs that the tokens-versus-salary math skips over. It also makes mistakes. It can produce output that looks right but is subtly wrong. It can generate work faster than the team can evaluate it. And if the task isn’t clearly defined, it tends to resolve ambiguity by generating volume.
That’s the hidden cost. The agent may be cheap per prompt. The workflow may still be expensive.
If AI is cheaper, cheaper than what, exactly?
Cheaper than a salary line? Cheaper than a task taking three days? Cheaper than a senior person getting interrupted ten times to answer questions a clear brief would have prevented? Cheaper than work not getting done because nobody had time to start it?
Those are different questions. The metric that matters isn’t cost per prompt, tokens consumed, or drafts produced. Not even “hours saved” unless those hours convert into something useful.
The better question is this: What did it cost to produce a completed, reviewed, useful outcome?
If an agent drafts a campaign brief in ten minutes but a marketer spends two hours correcting hallucinated positioning and wrong product names, the cheap part wasn’t the whole cost.
If an agent writes documentation nobody trusts, the output isn’t an asset. If it generates twenty prospect summaries and the team acts on two, the activity looked productive but the value was thin.
On the other hand, if an agent takes a messy sales call transcript, extracts the objections and action items, and gives a rep a better starting point for follow-up, that’s real value. The agent didn’t replace the rep. It removed the worst part of the work and made the human part easier to begin.
That’s where agents are most useful. As a way to make difficult work more startable, more reviewable, and less blocked by repetitive setup.
This is why the $500M story, accurate or not, resonates.
Anyone who’s been through enterprise software adoption recognises the pattern:
Then finance or security eventually asks the questions that should have been asked earlier:
Those questions aren’t bureaucratic overhead. They’re how you tell adoption from a “free-for-all”.
Microsoft’s Cloud Adoption Framework guidance on AI agents makes the point plainly: agent observability, governance, and security aren’t optional features — they’re requirements. The framework treats every agent as something that must be auditable and controlled throughout its lifecycle.
Anthropic moved in a similar direction when it released enterprise controls for Claude Code — spend limits at the organisation and user level, usage analytics, managed policy settings, and a Compliance API for programmatic access to usage data. Once agents do real work at scale, governance stops being a side feature.
The leadership question isn’t “how many people can we replace?”
It’s “which parts of the workflow should no human be wasting their best attention on?”
Those lead to very different decisions.
Let agents handle work that is bounded, repeatable, and easy to verify. Scaffold code from a clear spec. Summarise calls. Draft the first version of a brief, a ticket, a proposal. Produce the boring first pass that often prevents people from starting at all.
Keep humans responsible for the work that requires ownership: defining the problem, setting the constraints, judging quality, deciding what ships.
A good junior role isn’t a queue of small tasks. It’s how people learn what good looks like. Remove the repetitive setup with agents — that’s useful. Confuse that with removing the development path, and you’ve cut your pipeline of future senior talent.
More AI output doesn’t automatically mean more business value. Sometimes it’s more material to review, more edge cases to catch, more misplaced confidence to walk back.
Before scaling agents across a team, start with one workflow where the task is bounded and the output can be verified. Put an owner on it. Define what the agent can do alone and what requires human sign-off. Track whether the work gets accepted, reused, shipped, or acted on.
The measure is simple: Did this produce a better outcome, or just more output?
If the answer is better outcomes, expand it. If it’s more output, fix the workflow before adding more usage.
AI isn’t the problem. Unmanaged work is.
Co-authored by Gerard Pietrykiewicz and Achim Klor. Follow us on LinkedIn, schedule a call with Achim, or contact Gerard to see if there’s a fit. Subscribe below for more.
This article is AC-A and published on LinkedIn. Join the conversation!
Mark Stouse went to a baseball game. The Diamondbacks were hosting the Dodgers.
Five minutes after the final out, a guy walked back to his seat, looked up at the scoreboard, and said, “Wow! We won! How did that happen?”
That’s what a dashboard gives you: the final score.
Useful, sure. But not enough.
It won’t tell you how the team got there, who carried the play, who blew it, or almost did.
This is what Mark and I got into during our latest Causal GTM Leader session, the one that picked up right where AI needs human logic left off.
Here’s the recap.
Mark’s read on this concept stuck with me: data is the past by definition. Something has to happen before it can be measured, and by the time it’s measured, it’s already history. A dashboard is just a polished way of looking at history.
That wouldn’t matter much if markets held still long enough for last quarter’s numbers to still apply. They don’t, and never have.
Mark and I have made a related case before about why a forecast that starts with the past is already behind. Most of us spent the better part of the last 30 years in something close to a steady state, and we built our instincts, and our dashboards, around that. The steady state is gone. The dashboard hasn’t caught up.
The truth is nobody’s actually being held accountable for what their volumetric numbers mean to the business downstream. They’re being paid for hitting a KPI, not for understanding its ripple effect. So the dashboard becomes a kind of moat — the one story you can tell about yourself that you fully control, especially when the board or CFO starts asking harder questions.
I made a version of this case already, calling it process theatre. Dashboards do the exact same job, just with pretty charts instead of boring meetings.
This is where the conversation with a CEO or CFO actually gets hard. And in that context, the KPI itself is rarely the issue. What matters more is whether it still explains the market you’re selling into.
A lot of teams miss the headwinds, the tailwinds, and the crosswinds in the marketplace because they’re so focused on getting the deal across the line that they never look up. Buyer fear, budget pressure, trust, timing — most dashboards don’t show those forces unless you deliberately factor them in.
Mark put it about as plainly as it can be put:
There is a capital R reality out there that doesn’t negotiate with any of us, that doesn’t care how we feel. It just is.
You can disagree with gravity. You can resent it. But it doesn’t care if you step off a 30 storey building. The market runs the same way. It doesn’t lower the bar because your forecast says it should hold steady, and it doesn’t wait for your dashboard to catch up before it moves.
Most teams already sense the gap between the dashboard and the market. They just don’t want to be the one in the room who calls it out. Because doing that changes the conversation from reporting to accountability.
There’s a single question that separates a useful dashboard conversation from a wasted one:
Am I trying to defend past performance, or am I trying to learn what the best performance going forward would look like? That’s the fault line.
Try it on your own numbers before your next leadership update. Pull up whatever you’re about to present and ask, line by line:
Is this here to defend what already happened, or to help someone decide what to do next?
If every line is in the first column, you don’t have a dashboard. You have an alibi.
This is also where most GTM frameworks fall apart, including ones I’ve pitched myself. We’ve gotten very good at showing the symptom and very bad at showing the cause.
Dashboards show the symptoms of what’s happened in the past. The market is creating the causes — causes we haven’t even planned for. The internal metrics arrive way too late to matter.
By the time the dashboard flags the problem, the window to do anything about it has already closed.
So no, dashboards aren’t useless.
Dashboards matter. But they’re just instruments. They’re not reality.
That’s the distinction I see GTM leaders forget every week. The mistake isn’t building a dashboard. It’s mistaking it for the market.
Before your next leadership update, sort every metric on the page into two piles: defending what happened, or deciding what’s next. If one pile is empty, you’ve found your actual problem.
In your next weekly GTM review, ask the fault-line question:
Are we defending past performance, or learning what good performance looks like tomorrow?
Then watch who flinches.
Missed the session? Watch it here.
If you like this content, here are some more ways I can help:
Cheers!
This article is AC-A and published on LinkedIn. Join the conversation!
