Your GTM Motion Has a Version Number. Do You Know What It Is?

Every product ships with a version number. Your GTM motion doesn't. That's worth thinking about.

When engineering pushes a major release, there's a changelog. A deprecation plan. A deliberate decision about what gets retired, what gets rebuilt, and what gets carried forward. When the GTM motion shifts — and it always shifts — it usually happens through a combination of organisational pressure, quarterly targets, and accumulated improvisation. Nobody writes the changelog. Nobody owns the transition.

The companies that grow consistently don't just iterate their product. They version their GTM. Deliberately. With the same intentionality that good engineering teams bring to a major release. What's interesting is that the ones doing this best almost never talk about it publicly. The evidence is in the outcomes, not the announcements.

The Quiet Versioning at Stripe

Stripe is the canonical case of developer-led growth — the seven lines of code, the API-first philosophy, the word-of-mouth spread through engineering teams at startups. What's less discussed is that this was version one of a GTM that has since evolved through at least two more distinct iterations.

Stripe was surprisingly far along before they had a meaningful marketing or sales team. The reason they eventually built those functions out was simply this: they wanted to expand into the enterprise channel, and the product-driven approach doesn't work particularly well there. Enterprise buyers expect significant human involvement in the sales process, hang out in very different places than developers, and expect a structured contracting process. Lethain

What followed wasn't a single pivot — it was a layered transition. As Stripe moved upmarket, they had to build out more products and features to support the needs of enterprise, shifting from focusing solely on engineers via a self-serve product to building out a sales-assisted function, simply because larger companies have more complex needs and purchasing decisions. Howtheygrow

The version logic here is worth sitting with. V1 opened startups and developers — a specific ICP with a specific SAM. V2 added a commercial layer that unlocked SMBs and growth-stage companies whose buying process was more structured. V3 entered enterprise, with a completely different buyer — CFOs and procurement teams at large organisations — requiring dedicated AEs, compliance certifications, and SLA frameworks. Stripe now counts more than 50 category leaders processing over a billion dollars annually as customers, with enterprise revenue now both its largest and fastest-growing segment. The Strategy Story

None of these versions happened by accident. And none of them made the previous version obsolete — Stripe continued investing in the developer and startup motion throughout. But each version was a deliberate answer to the same question: who can we now reach that we couldn't before, and does our current motion know how to find them?

When the Version Change Happens to You

The Stripe story is one of deliberate evolution. There's a less comfortable version of this that plays out regularly in enterprise software — where the GTM version change isn't chosen, it's imposed.

Enterprise ERP vendors like SAP and Oracle built their businesses on large, complex organisations that could absorb the cost and pain of extended implementations. Their entire ecosystem — the vendor, the systems integrators, the consulting firms, the training companies — is optimised for large engagements with large customers who generate large fees. Serving the mid-market doesn't fit that model. Bizowie

This is the structural reality that makes internal reorganisations so consequential for GTM. When a large enterprise vendor restructures its coverage model — consolidating sales territories, shifting mid-market accounts from dedicated AEs to digital-first self-serve channels, or redirecting customer success resources toward higher-value segments — the GTM motion doesn't evolve. It fractures.

From inside the organisation, it looks like a cost efficiency exercise. From the mid-market customer's perspective, something much more disruptive happens: the account manager disappears, the quarterly review cadence stops, and a self-serve portal arrives in their inbox with a welcome email and a help centre link.

For decades, if you sold SAP or Oracle, the brand did the heavy lifting. Enterprise buyers trusted the global name. The job as an implementation partner was mostly operational — develop well, deploy without issues, stay compliant. Growth happened because the logo itself created the trust. I-MidasTouch When that trust infrastructure gets quietly dismantled through a coverage model change, the customers who navigate it successfully are the ones who were self-sufficient to begin with. The ones who churn are the ones who needed the relationship.

The difference between a deliberate GTM version bump and an org-driven GTM fracture comes down to one thing: whether someone with a strategic view was holding the pen when the motion changed, or whether the change was a byproduct of something else entirely.

Three Things That Tend to Precede a Version Bump

Looking across companies that have navigated these transitions well, a few patterns emerge in what triggers a deliberate versioning rather than a reactive one.

The first is ICP drift. The customer that's actually buying starts to look noticeably different from the customer the GTM was designed for. The deal sizes are shifting, the buying committee is changing, the objections in late-stage conversations aren't the ones the playbook was written to handle. This tends to show up in win/loss data before it shows up in revenue — which means companies that track it closely get an earlier signal.

The second is product expansion into a new use case or segment. When a product grows to serve a customer it wasn't originally built for, the GTM rarely grows with it at the same pace. The new use case gets sold using the old motion — wrong channel, wrong message, wrong entry point — until someone notices that win rates in the new segment are significantly lower than they should be given the product's actual capabilities.

The third is channel saturation. The original motion — whether PLG, outbound, partner-led, or event-driven — starts to show diminishing returns. Not because the channel is broken, but because it has reached the natural boundary of the ICP it was designed to find. The next customer exists, but not in the same place.

Any one of these is worth a structured review. The interesting thing is that most companies experience all three simultaneously and address none of them systematically, because the question of GTM version ownership tends to fall in the gap between sales, marketing, and product.

The SAM Expansion Reframe

There's a tendency to think about GTM versioning as an efficiency exercise — cleaning up the motion, improving conversion, reducing CAC. That framing undersells it.

Each version of a GTM motion is fundamentally an expansion of the serviceable addressable market. The developer motion at Stripe reached startups. The self-serve commercial motion reached SMBs. The enterprise motion reached the Fortune 500. The SAM didn't expand because the product got better, though it did. It expanded because the GTM was rebuilt to find a customer it previously couldn't reach.

This matters even more as AI compresses product development cycles. If new use cases can be shipped in weeks rather than quarters, the product's potential SAM is growing faster than any go-to-market team can organically adapt to. The gap between what the product can do and who the GTM is designed to reach gets wider quietly — and tends to announce itself at the worst possible moment.

The question worth asking regularly isn't "is our GTM working?" It's something closer to: your product just shipped v4.2 — what version is your GTM, and which customer is it still pretending doesn't exist?