AI Won’t Fix Broken GTM Systems

Its 2014, and this is a canned demo: (stay with me)I am on a Tableau sales call with a Director of IT (ICP). He has flown into Seattle with a problem. Manufacturing tables, the actual product, dining tables are down. Not slightly. Meaningfully. He is about to walk into a board meeting and recommend the company slow production.

We open Tableau. Drag in the sales data. Plot it over time. There it is. A clean downward slope, exactly the way the spreadsheet had told him.

Then I add one column. Region. Now what do you see.

The drop is entirely in the East.

Midwest, South, West? They were flat or up. The crisis is not a tables crisis. It is an East crisis. A regional supply issue, maybe a competitor promo, maybe a single underperforming team. Whatever it is, it is not a reason to slow production for the entire country.

At Tableau we called this the moment of going from the known unknown. The question you walked in curious about to the unknown unknown which is the answer you did not know you were looking for. It was the magic. The Tableau rep with a laptop looked like a magician. That moment, candidly, is what built Tableau.

It was also entirely predicated on a beautifully manicured, perfectly columnar dataset. Clearly labeled. Cleaned. Poised for proper ingestion.

#notreality.

You already know what happened.

Companies grow. Data multiplied across systems that did not talk to each other. The clean dining-tables-by-region dataset became thirty datasources in six tools captured by forty-three different humans with different naming conventions, half of whom were no longer at the company. The signal we sold so beautifully: here is the answer, you just needed one more dimension buried itself under operational entropy.

ETL became the golden child. Data engineers became the bottleneck. The dashboard request queue stretched out for months. And (ugh) this is the part nobody loves admitting, most of what ETL was working on had nothing to do with making GTM data actionable. It was about getting the data to exist in a place where, in theory, someone could ask it a question. The asking was somebody else’s problem.

Then came the connectors. Zapier, MuleSoft, Tray, the whole API-as-glue economy. We (operations) hacked together approximations of tables in the east — workflows that mostly worked, broke quietly when an API rate limit hit, and required some poor operator to babysit them through every quarterly system update. The GTM org could feel the answer was almost reachable. The infrastructure underneath kept reminding them it was not.

So we hired an analyst. Of course we did. We need someone to own reporting. The analyst arrived, knew nothing about the business, took dashboard orders the way a short-order cook takes breakfast orders, and produced thirty-seven dashboards in their first year. Roughly four of them got used. The other thirty-three lived as bookmarks in someone’s browser, refreshing automatically into the void.

This was the state of play for about a decade (up until 2024). Operators kept up by working harder. Data created itself faster than anyone could organize it. The tables in the east magic still happened occasionally, but it happened in spite of the systems, not because of them.

Not just for the engineers this time.

For everyone.

A non-technical founder spins up an enrichment waterfall in a weekend with Claude as a copilot. An SDR who has been doing manual account research for six months learns Clay in a week and 10x’s her output. An AE who used to spend a full day prepping for an enterprise call now runs three prompts in fifteen minutes and walks in with a better deck than her marketing team would have built her. Marketers map intent signals and lead scoring with an LLM that does not need a six-month BI project to render. CS teams ship chatbots for the questions nobody on the team wants to answer for the hundredth time. Sales managers run their reps through AI role-play sessions on demand.

All of it works. Most of it works really well. And every single function in the GTM org just got handed the keys to the workshop.

This is the genuinely amazing part. The democratization of the build is real, the productivity gains are real, the operator-magic that used to require a six-figure analyst and a six-month BI roadmap is now available to a curious SDR with a Claude tab open. The 205% year-over-year growth in “GTM Engineer” job postings everyone is talking about is partly a labor market reaction to this, companies want more of it, faster, applied to more of the funnel.

But here is the part the LinkedIn posts are not saying out loud.

If every function in the GTM org is now building its own automations, who is collecting the unified insight that turns those automations into action?

The honest answer in most companies is: nobody.

The SDR has her enrichment waterfall. The AE has their account research prompt. Marketing has its intent scoring model. CS has its chatbot. The sales manager has his role-play tool. Each of those is locally efficient. Each of them is also producing signal about prospects, about objections, about which messages land and which die. That lives inside one tool, owned by one person, readable to nobody else.

We have not removed the silos. We have democratized them.

This is the failure mode that the “GTM Engineer is the new RevOps” narrative completely misses. The role exists, we all know that. The point is that the broader shift underneath the role is not just labor market rearrangement. It is the fragmentation of GTM signal across an entire org of newly empowered builders. Each one building locally optimal workflows. None of them connected to a unified picture of what the company is actually learning about the market.

This is tables in the east in reverse. We have all the regions. We have all the time series. We have more data than we have ever had, generated faster than we have ever generated it. And nobody is dragging Region into the visualization, because nobody is responsible for the visualization anymore.

If you are a seed-stage founder reading this and feeling slightly defensive, I hope so. That is the right reaction. This is the part of the conversation aimed directly at you.

You have heard the pitch. Probably more than once, in some variation. You can vibe-code your entire GTM org with four tools and Claude. Here is my playbook. Sign up for my newsletter. The pitch is not entirely wrong. You absolutely can build more of your GTM motion yourself than founders could three years ago. AI has collapsed the cost of the build. The technical floor is now a weekend, not a quarter.

But the pitch leaves out two things, and skipping either one will hurt you more than the build will help you.

1. You must have a documented foundation underneath the build.

A clear problem-to-solution hypothesis. A real ICP: not the vague “B2B SaaS founders” version, but the specific company profile, the specific person in that company, the specific job they are trying to do, and the specific reason they would pay you to do it. A unique value message that is actually unique. A competitor and market landscape view that you have actually done the work to understand. Market sizing that holds up to scrutiny.

With this as the foundation, your AI experiments have something to learn from. Without it, you are generating signal against noise. The prompts return answers, but the answers are not anchored to a coherent thesis about who you are selling to and why they would buy. You will mistake activity for traction. You will scale the wrong thing. You will eventually find yourself, eighteen months in, holding a beautifully automated outbound machine that is talking to the wrong people about the wrong problem in the wrong language.

2. You “the founder” must stay close to sales.

I know you do not know how to sell. You will learn.

I know you do not like talking to strangers. You will, once those strangers get excited about what you are building.

I know you have a million other things on your plate. You do, and this is one of them.

Founders who outsource the sales motion to AI before they have done it themselves end up with companies that cannot read their own market. The LLM is happy to do the account research, write the sequences, even run the role-plays. It cannot tell you what a prospect’s face does when you say “twelve thousand dollars per month” instead of “eight.” It cannot pick up the half-second pause that means the buyer does not actually have budget authority but is too proud to admit it. It cannot feel the room shift when you accidentally use a phrase that lands.

You have to feel that yourself. You have to feel it enough times that your intuition becomes a model. Then you can teach the model to your AI and to your eventual sales team.

Founders who do this build companies that scale. Founders who skip it build companies that have to be rebuilt from scratch at Series A by someone who does it for them.

Here is how to think about it, mapped against the four foundational phases of how a company actually grows.

Every stage is a build-and-maintain. You do not graduate from one stage and abandon it. The build compounds. The maintenance is the work. The formula at every stage is the same four moves: Build, Capture, Analyze, Action.

Idea Market Fit. Build your LLM foundation from your researched hypothesis and your product build. This is where the documentation matters most: the ICP, the problem statement, the value message, the competitive view. Your LLM is not magic. It is reading what you give it. If you give it a vague thesis, it will return vague answers polished to a high shine, which is worse than a vague thesis on its own because it feels like progress.

Product Market Fit. Capture signal. From prospects, from clients, from sales calls, from product usage, from support tickets, from cancelled meetings, from anything that maps to whether you are delivering value. Use AI to extract structure from that signal to turn unstructured conversation into pattern. This is the stage where most founders fail by trying to scale before they have captured enough signal to know what they are scaling.

GTM Fit. Use AI to identify resource efficiency. Now that you have signal and you have foundation, you can start automating the parts of the motion that do not require judgment. Enrichment, scheduling, routine outreach, account research, meeting prep, follow-up sequences. The build is cheap now. Build it.

Scale. Use AI to hypothesize action. Pour gas, baby. You have foundation, you have captured signal, you have efficient operations. Now you can use AI not just to execute but to suggest what to surface anomalies, to propose experiments, to model outcomes. Now you are doing tables in the east again, except the data underneath is yours, the signal is unified, and the answer is actionable.

Skip any of these phases and the next one breaks. Skip the foundation, the signal becomes noise. Skip the signal capture, the efficiency optimizes the wrong thing. Skip the efficiency, the scale runs into a wall. The formula is in the order. The order matters.

The magic of Tableau was never the visualization. The visualization was the delivery of the magic. The magic was the data underneath. Manicured, columnar, clean and THAT made the answer possible to surface in the first place.

The magic now is not the automation.

It is the foundation underneath.

The GTM Engineer is here to stay. So is the SDR with a Claude tab open, the AE running prompts before every call, the CS lead shipping chatbots, the marketer mapping intent. None of that is going back. That part of the shift is real, and the productivity gains are real, and founders who refuse to engage with it will lose to founders who embrace it.

But founders who embrace it without foundation are not democratizing their go-to-market. They are decentralizing their confusion. They are building beautifully automated machines on top of unanchored hypotheses, and they will find themselves at Series A holding a system that runs efficiently in the wrong direction.

Tables in the east only worked because someone had labeled the columns.

“Label the columns” first.

If this article hits because you are recognizing yourself in it building fast (and maybe not, you are too busy building?), watching your team build faster, and not entirely sure whether the foundation underneath is holding the first move is not to slow the build. It is to figure out where you actually are.

The RVNU GTM Debt Assessment maps your company across the 16 foundational stages of go-to-market. In 5 minutes, it tells you which stages are solid, which are leaking, and which you have not built yet and which stage you are operating in right now.

That is the answer to the question you are actually trying to ask, which is where, when, and how safely can I build automations without losing signal.

The answer is stage-dependent. In Idea Market Fit, the answer is “not yet, slow the build and document the hypothesis.” In Product Market Fit, “yes, but only the parts that capture signal.” In GTM Fit, “now, aggressively, you have earned it.” In Scale, “yes, and use AI to hypothesize where to pour gas next.”

The assessment is not there to slow you down. It is there to tell you where the build will compound and where it will just multiply confusion you have not yet resolved.

Take it. Find your stage. Then build like you mean it.

Take the GTM Debt Assessment →

Laura Wheeler is Co-Founder and COO of RVNU, a B2B SaaS go-to-market advisory firm. RVNU helps founders measure and pay down GTM Debt, the accumulated misalignments between go-to-market strategy and execution that quietly throttle growth.