“We should have built this by now.” How often have GTM operators had this guilt-inducing thought?
For years, the diagnosis for not building quickly pointed squarely at GTM teams. RevOps maturity-model ladders staged teams from ‘crawl’ to ‘walk’ to ‘run’. Vendor content argued the missing input was more intent data. ‘Speed-to-lead’ think-pieces treated SLA enforcement as the fix.
Each of these was plausible on its own terms, and each one located the failure inside the team. I argue there was never a maturity gap. Instead, it was a cost ceiling that prevented GTM teams from realizing their potential.
The ceiling has now lifted, thanks to AI. But, what replaced it is less comfortable to talk about.
Teams were never the problem. Cost was
Nobody in this audience needed the “better GTM system” explained to them. Real-time signal capture instead of a nightly sync. More statistically significant scoring inputs vs. less. Dynamic ICP criteria adjusting to the current product suite and market as opposed to the list of accounts generated when prepping for the last round of funding.
Most operators I’ve worked with could sketch the whole thing on a whiteboard in 10 minutes. The constraint showed up the moment you tried to build it, and in every company I sat inside it came down to two options.
- Patch it together with no-code tools and human effort. This produced a model oversimplified by design, not by judgment. Four inputs and a static threshold was the ceiling of what we could build without an engineer, and the constraint set that shape.
- Ask engineering for the real version, then wait one to two quarters. Usually more.
The second option almost never worked. Priorities shifted, the ticket aged, and we let the project die on the roadmap without ever reopening it.
After all, if you put a lead scoring rebuild next to a checkout bug or an enterprise integration in the same sprint planning, the scoring work loses on expected value every single time. It should have lost because the cost was too high.
Cost, here, means three things.
- Money (fell post AI)
- Time (fell post AI)
- Talent required (remained the same)
Engineering bandwidth is not meaningfully different from where it was two years ago, and on the teams I’ve seen, it’s a little better. Data quality hasn’t moved much either. What changed is how much of each you have to spend to get to the same output, thanks to AI.
That changes the approval math.
A project that needs two quarters of engineering plus a vendor contract requires several people signing their names to a forecast nobody can verify. A project that needs a week and a small spend requires one person willing to be wrong.
Tooling maturity didn’t disappear. Neither did vendor lock-in. Neither did internal politics. They just stopped being decisive.
Theoretically, this means GTM teams should be building faster than ever before.
The bottleneck has moved
“If it’s that cheap now, why isn’t everyone already doing it?” I argue the blocker is now the tooling market itself, because keeping current on what exists, what works, and what it costs, has become a full-time job.
Read it as one operator’s read on a market that now ships new entrants faster than any single person can assess (impractical / impossible depending on how thin your week already is).
After all, the initial cost isn’t a blocker. It isn’t engineering bandwidth either. It isn’t data quality, which is unchanged in every stack I’ve touched. And it isn’t reversion cost. Ripping out a two-week build costs almost nothing.
Ramp time on a new tool is short now, so the trial cost is low, which means the number of tools worth trialing has exploded. But decision confidence hasn’t gotten cheaper.
It still takes the same three weeks of real usage on real data to know whether a scoring layer is doing anything, and three weeks times 15 candidates is not a quarter anyone has.
There is no ‘silver bullet’ in the current market, and the absence of a ‘silver bullet’ is precisely what makes evaluation expensive: you have to compose the answer yourself from parts, and composing requires knowing the parts.
Which is where your time goes and blocks the projects you urgently need.
Cheaper to build doesn’t mean easier to get right
This was never a maturity problem. But calling it solved would be its own error, because the ceiling moved from initial cost to discernment and strategic clarity, and no budget line buys those.
What the numbers are forcing on us is writing down, honestly, whether our strategy and our team survive what cheap and fast demands. Not “pick a vendor.”
And then comes the task of evaluating the tool landscape.
You could spend time doing this or you could lean on Krossings. Book a free revenue diagnostic with us and get an outside, embedded read on whether your team can make this jump alone.