Why Your Marketing Stack Isn’t the Problem (It’s Your Process)

I get the same email about twice a month. Someone on LinkedIn, someone from a reader who found the site, sometimes a former colleague starting a new gig. The message is always a version of:

“Marcus, we are thinking about switching from Tool X to Tool Y. Do you think that will fix our growth problem?”

My answer is almost always no. Not because Tool Y is bad. Usually because the growth problem has nothing to do with tools.

After 12 years of watching this dynamic play out at agencies, SaaS startups, and the teams I consult with today, I have become increasingly convinced that the marketing stack is the least important thing most teams worry about. What actually kills growth is the process underneath the stack — or more often, the total absence of one.

The Pattern Every Underperforming Team Has in Common

I was called in last year to help a Series B startup with “a content marketing problem.” They were publishing two posts per week, ranking for nothing that mattered, and their CMO was convinced the issue was their CMS. They were a few weeks away from a $90K migration to a “more SEO-friendly” platform.

We spent a morning looking at their setup. The CMS was fine. The templates were fine. The schema markup was fine. What I found was this:

• Topic selection happened in a shared doc that five people edited with no approval step.
• Briefs were written by whoever had time.
• Writing was outsourced to three different freelancers who had never met each other.
• Editing was done by the VP of Marketing, in the last 20 minutes before publishing.
• No one owned distribution. Each piece got one LinkedIn post and a tweet.
• Performance was reviewed quarterly, if that.

They did not have a content problem. They had six disconnected people performing tasks that, added up, looked nothing like a content program. A better CMS would not have changed that by a single percentage point.

This is the shape of most marketing “stack problems” I investigate. The tools are fine. The process is fragmented, unowned, or invisible. No tool fixes that.

What a Real Process Looks Like

Here is the boring truth: the highest-performing content team I ever worked with used a CMS that everyone hated, a keyword tool that was two years out of date, and a Google Doc for briefs. They outproduced a better-equipped team by about 4x on organic traffic over 18 months.

What made them work was not their tools. It was that they had five rituals the team never skipped.

Ritual 1: Weekly Topic Triage

Every Monday, 45 minutes. One person (same person, every week) brought a shortlist of 15 topic candidates, sourced from keyword research, customer interviews, and support tickets. The team killed 10 of them in the meeting. The surviving 5 went to brief writing.

The point was not the 15 topics. The point was that no topic could enter production without a group decision. That single gate eliminated 80% of the noise that content teams normally produce.

Ritual 2: Structured Briefs

Every piece had the same brief structure. Target query, search intent, top 3 competing URLs with what they did well and poorly, the angle we would take that was different, the customer problem we were solving, and three internal links we would include.

The brief was approved before writing started. No brief, no writing. This sounds rigid. It is rigid. It is also why the team never published 1,500-word “What Is X?” posts that nobody searches for.

Ritual 3: Author Pairing

Every piece had two people on it. The writer produced the draft. The reviewer, who was a subject matter expert, red-lined it for factual correctness and removed generic AI-sounding language. This was a 30-minute review, not a rewrite. If the draft needed a rewrite, the writer got the feedback and did it themselves.

Ritual 4: Built-In Distribution

Before publication, every piece had a named distribution plan with a named owner. Which newsletters would feature it, which internal tools would link to it, which communities would share it, which customers would be emailed. If a piece could not answer “who will read this in the first 72 hours,” publication was delayed until it could.

This is where most content dies. Teams spend 20 hours writing a post and 20 minutes distributing it. Reverse the ratio and everything changes.

Ritual 5: 30-Day Retrospectives

Every piece was reviewed exactly 30 days after publishing. Traffic, conversions, positions, engagement. Three outcomes:

• Winner: expand it. Additional related posts, internal link pass, consider paid promotion.
• Dud: understand why. Bad intent match? Weak distribution? Timing?
• Slow burn: check again at 60 and 90 days before deciding.

The team learned from every piece. The tools they used were almost incidental to this loop.

Why We Keep Blaming the Stack Instead

Three reasons, in the order I have seen them.

Stacks are visible. A process lives inside people’s heads and calendars. A tool lives on a screen. When something is wrong and you are under pressure to do something, the tool is the thing you can point at and replace. Replacing the tool feels like action. Fixing the process feels like admitting the team is the problem.

Stacks have vendors. Every tool in your stack has a sales team incentivized to tell you that your problem is solved by switching. Processes have no sales team. Nobody flies out to convince you that your Monday triage meeting is what you actually need.

Stacks are approvable. “We need to buy a better tool” passes a finance review in two meetings. “We need to restructure how our team works” requires political capital you may not have. Spending money is easier than changing behavior.

All three of these are real, human reasons. They are also why teams burn six-figure budgets on migrations that change nothing.

The Questions I Ask Before Any Stack Change

When a team asks me for a tool recommendation now, I refuse to answer until they have answered four questions. If they cannot, the new tool will not help.

1. Who on your team will own the daily use of this tool? Not “the marketing team.” A specific person with a specific job title and a specific calendar block.
2. What decision will this tool help you make that you are currently making badly? If you cannot name the decision, the tool is being bought for reasons unrelated to decisions.
3. What have you changed in your process in the last 90 days? If the answer is “nothing,” a new tool is treating a symptom of organizational inertia. It will not stick.
4. What will success look like 90 days after you implement this? Vague answers here are the biggest predictor that the tool will end up unused within six months.

Roughly half the teams I talk to stop the conversation at question 3. That is not a failure of the conversation. That is the conversation working. A new tool would not have helped them and would have cost real money.

The Stack You Already Have Is Probably Fine

If you are reading this and wondering whether you need to replace your stack, here is my honest bet: probably not. Most stacks, even mediocre ones, have 3x to 5x more capability than the team using them has operationalized.

Before buying anything, run an audit of what you own. List every tool. Next to each, write the specific weekly ritual that uses it. I guarantee you will find at least three tools that have no ritual attached. Those are your real stack problems — not the absence of a shinier replacement.

Kill the unused tools. Reallocate the budget. Spend it on building the rituals that will make your remaining stack actually do work. That is the whole game. The stack is not the problem. What you do with it is.