The next era of GTM tech
Austin Hay (Reforge, Ramp, Clarify) on how to build a tech stack that lasts
👋 Hi, it’s Kyle and welcome to Growth Unhinged where I explore the unexpected behind the fastest-growing startups.
Y’all know I love talking about go-to-market (GTM) strategy. The sad reality is that our dated and bloated GTM tech stacks hold us back from executing GTM plays with confidence. GTM tech is acutely painful for modern software businesses combining PLG, sales-assist, and scaled/AI-enabled outbound motions. But I probably don’t need to tell YOU that…
Ask 10 people for an expert in modern GTM tech and probably 8 of them will tell you Austin Hay. Austin teaches THE MarTech course at Reforge. He’s led growth and GTM tech teams at scaleups like Ramp, Runway, mParticle, and Branch. And now he’s co-founder at Clarify where he’s building the future of GTM tech. Keep reading for Austin’s perspective on how to build a stage-appropriate tech stack that lasts.
Revenue teams are running up against a brick wall. As increased focus on complex outbounding motions rises, the need and desire to invest in their CRM stack as they’ve invested in their platform stack gets more acute.
But without the option-rich ecosystem of their marketing counterparts, where can they find relief? How can we, as revenue professionals, do better to get more out of our tooling without just buying more tools for basic operations and drowning in tech debt, bloat, and cost?
This is an impossible question to answer in isolation. But the first step in designing a modern, flexible stack that meets our needs is to better understand how we got here and the role of the CRM in the future of our work.
Over the last decade, the concept of the stack has solidified in martech and revtech as CDPs and CRMs have taken up this center of gravity mantle. We can break this solidification into four eras:
Sales tech (2015),
B2C martech (2017),
B2B2C GTM tech (2022), and
Decentralized GTM tech (today)
Below, I’ll share some of the hard-won lessons I’ve learned from a decade of helping dozens of tech companies create and maintain GTM tech stacks across these eras. We’ll also discuss what the current age of the revtech stack looks like and how modern PLG companies can build toward flexibility (ft. some tangible assets from my martech course with Reforge to help you get started).
What makes a “good” modern GTM stack
Modern GTM stacks are built around four core data components: inputs (where we get data about our customers from), storage (where we keep our customer data), capabilities (tools that enrich our data or endpoints like analytics tools), and federation (how data gets moved between the other components).
How “good” a given GTM stack is less about the quality of any of the individual tools within the above categories and more about how well they play together. This is what we refer to as stack flexibility, and it’s the name of the game in operating rev and martech systems today.
Why does this flexibility matter so much? There are five main reasons:
Novel marketing and revenue challenges mean moving more data. If you can’t move data because of your vendors or system complexity, you’re screwed.
GTM teams need to build audiences and segments quickly. Flexibility lets you create audiences across a variety of tools and stream audiences to many destinations (especially if you’re taking a warehouse-first approach).
Companies need to avoid creating tech debt and complexity burden. Last-minute business challenges (like finding out your DTC vendor made an API change at the last minute before a big mailer campaign) require speed and ability to handle well without causing more tech debt and system complexity.
Business needs and tool options change quickly. Having a highly-flexible stack means you can easily onboard and offboard vendors to create systems that fit your unique needs with the best tools possible without confusing/burdening the team or partners.
Building world-class software requires world-class debugging. Flexibility in your stack lets you find, assess, debug, escalate, triage, and resolve stack issues quickly.
In short, stack flexibility gives PLG and B2B2C companies the underlying flexibility they need to support complex customer journeys and gain insight into how users interact with their product and different channels.
So, how do we go about building toward flexibility (and limiting the amount of hair-pulling we’ll do over our tech a few years down the road)? This is a complex question, but–through auditing dozens of martech and sales tech stacks over the years–I’ve developed a framework that can help. This is the same framework I used to guide Ramp toward a system north star in 2022.
PSA: For this to work, the revenue motion needs to be treated like a first-class engineering discipline (i.e. more teams should be investing in engineers as part of their GTM machinery).
The framework is anchored around four core principles:
Redundancy: Multiple vendors offer similar functions.
Good: Flexibility for discrete, decentralized actions (e.g., two tools sending audiences).
Bad: Exact same capabilities causing confusion (e.g., two attribution tools).
Coupling: The amount of dependency between vendors or systems.
Good: Low dependency for easy vendor changes (e.g., analytics library around CDP).
Bad: Single tool bottleneck breaking system upon removal (e.g., random connections).
Interoperability: How well tools work together and for your needs.
Good: High data exchange capacity for business tasks (e.g., push/pull/audience integrations).
Bad: Incompatibility forcing workarounds (e.g., brittle Hubspot integration).
Focus: Tools solve specific problems with intentionality.
Good: Discrete problem-solving, driving good decisions (e.g., data diagram, permissions).
Bad: Unclear best use, tied to bad coupling (e.g., shiny-tool syndrome without pruning).
There are more options for GTM tools than ever before, with wildly ranging capabilities and quality. Below, we’ll take a look at how we got to this point in the revtech landscape, and what modern orgs can do today to future-proof their stacks as they grow.
How the GTM stack evolved (and what it means for modern orgs)
The concept of a “stack” is nothing new and, like many elements of the world of GTM, has roots in engineering.
Engineers built infra stacks all the time based on known frameworks, tools, languages, and services. These “building blocks” created a lot of variation and flexibility, but were often rooted around a center of gravity tool that fluctuated as tech changed.
This concept bled over into the GTM tech space in earnest around 2015 (with the CRM as the center of gravity) and has evolved into the decentralized GTM tech stack used by many modern orgs today.
Below is a breakdown of the four distinct eras of GTM stack evolution that I’ve seen over the last near-decade.
Era one: Sales tech (2015)
Back in 2015, I was working with Mike Molinet at Branch and we put together the first version of our revtech stack with the tools available at the time. It followed this basic outline:
A CRM (our center of gravity)
An outbounding tool
An email marketing tool
An enrichment tool
A deduplication tool
Since then, things have only gotten more complex, integrated, and automated.
Era two: B2C martech (2017)
Traditionally, I think of a martech stack as a B2C-specific stack or set of connected tools to help marketers reach, acquire, grow, retain, and monetize users. It has various capabilities, and is connected to allow ease of attribution and scale.
This definition became the norm in 2017. Rather than a center of gravity around the CRM, B2C companies aligned around the CDP. This martech playbook worked well across nearly-all B2C companies, so it was highly repeatable and anchored around two core components:
A warehouse (connected upfront or at the end of the process)
A CDP (loaded at the front of your application to stream audiences and data to downstream tools)
Once B2C companies had those two core competencies covered, you generally saw a range of capabilities added into their orbit:
Analytics and attribution (paid and organic)
Channel marketing (email, push notifications, and SMS)
Data management (data federation, schema management, and data privacy)
Marketing acquisition (SEO and SEM, affiliate marketing, and deep-linking)
Infrastructure (routing)
Depending on the size, stage, and complexity of the business, marketing teams would choose more or less tools from the menu above. Lines blurred among many companies as these capabilities became more tech heavy (and entered the realm of engineering).
Note: Martech are often engineering people in disguise.
Era three: B2B2C GTM tech (2022-now)
The last few years have ushered in a new category of business: B2B2C (or companies who serve both the individual and a team). Think crowd favorites like Notion, Figma, and Canva. The result has been an attempt at unifying data between CDPs and CRMs.
Marketing and sales teams no longer work in disconnected silos. B2B2C business models (especially in product-led orgs) require GTM teams to work closely, integrating their goals and, by extension, their tooling.
As a result, effective GTM ops requires an integrated stack that mirrors the integrated nature of the teams using the tools (sales 🤝 marketing) and users of the end product (team 🤝 individual). To make this a reality, companies must focus on creating a highly-flexible stack that focuses on redundancy, coupling, interoperability, and focus.
The maturity of your GTM stack (and what “good” looks like) varies slightly by company maturity. Below are a few examples of revtech stacks at different maturity stages, as well as a breakdown on where to focus resources at each size.
Early stage example: Thena
There is by far no better example of what a stack looks like at an early stage than by examining that of customer conversation platform Thena. Last year Growth Unhinged featured how seed-funded Thena was replicating 5-10 SDRs by using off-the-shelf tools, like Keyplay, Clay, and Clearbit.
Today, that stack has grown in size and complexity—a common theme in early growth stage companies is to acquire tools quickly in an effort to tackle the job at hand.
What made this stack great is simple: there was lots of tools to handle lots of jobs. Rather than hiring 10 people to solve basic SDR problems, 10 tools did it instead. This resulted in a steady drip of inbound leads from a variety of channels, all turnkey initiated. Similarly, there was an element of surprise and serendipity to it. If you’ve lived in the world where leads are hard-earned through manual cold outreach, it can be truly delightful to wake up to an inbox full of scheduled calls with no effort.
The flipside of this early proliferation of tools was a maintenance cost. Instead of needing 10 SDRs, they needed just as much time to setup, manage and maintain the stack. This is one of the consequences for early teams as GTM tooling has expanded. Even if you can do everything you want with 10 well-connected tools, can you continue to maintain it? What about when stuff breaks?
“One of the biggest issues we faced when build our stack was overbuilding it. We took an enterprise SaaS approach to building out most of our GTM stack, even though we didn’t have enough people to manage the tools. At first, we felt great because we were effectively able to remove people from the process by adding tools that automated that work for us. But eventually, we had too many tools and it became too hard to manage. In spring of 2024, we started to cut back on how many tools we used.” — Brendan Kazanjian, growth at Thena
As companies acquire new tools and rise on the complexity ladder with their GTM stacks, they need to be thoughtful of downstream consequences. Tools to automate the job can spur growth. But too many tools can lead to not enough manpower to manage them.
Growth example: Postmates
The Postmates tech stack was legendary for its day back in 2017. It effectively replicated a modern-day data stack long before the knowledge, tools, and capabilities existed.
In particular, Postmates did an excellent job at data collection. They had a growth product team that utilized a CDP aggressively to track users and events. Likewise, it was persistent in funneling data through this CDP and then to its downstream providers, avoiding many of the data roundtrips and duplicate SDK issues that other companies at the time faced. Last, and probably most important, it used its stack reflexively to drive growth campaigns. Anytime a new campaign came up, they asked “How might we solve this quickly and experiment with our stack?” Today, everyone takes for granted how easy it is to setup new tools and try capabilities. But back in 2017, this was novel.
The biggest challenge that arose with this stack was one of our own creation. By utilizing the CDP so extensively, long before there existed tools to manage the data in the 3rd party, it became unwieldy. In particular, we stamped experiment attributes to every profile of a user but instead of using one experiment key with rotating values, we defined a new experiment as a new key. This lead to attribute bloat on the profile record.
Similarly, there were no data governance tools like those that would emerge in 2020 such as Iteratively, Avo, Segment protocols or mParticle Data Master. As such, after four years of engineers adding events with bespoke event attributes, our data library was a mess.
Today if you start a CDP from scratch you can implement schema to control what goes into the CDP, and it's a lesson hard earned – spend the time upfront to manage your schema or pay the toll later.
Scale example: Ramp
At Ramp our acquisition funnel was primarily user-centric even though we targeted businesses for corporate credit cards. This motion demanded both a CDP-style tech stack at the top (focused on acquisition) and a CRM-focused tech stack (focused on enterprise sales engagement) at the bottom.
Ramp's GTM stack was a tale of two cities – a beacon of efficiency in some areas and a cautionary tale in others.
We did a lot of things really well with our tooling, especially when it came to optimization. We often went on a Marie Kondo-esque decluttering spree, ruthlessly auditing our tools and asking, "Does this spark joy... I mean, provide value?" If a tool couldn't find its purpose or an owner, or if it was better to swap something bespoke out for a vendor tool, we removed it. This helped us consolidate and centralize overlapping capabilities and implement SQL-based governance processes.
Example: Our marketing team was creating segments and audiences using about five different tools. We consolidated all of this into Hightouch to make the most of data from the warehouse.
However, no tech stack is perfect and our tendency to build custom, bespoke parts made it difficult to swap out tools when things broke. This created a dependency on the engineering team. We also had a bit of a two-CRM tango happening between HubSpot and Salesforce, which trapped us into synchronizing data to upstream tools (what I affectionately call debugging hell). It was a good reminder that sometimes simpler really is better, especially when it comes to data flow in complex systems. Complexity of a stack often boils down to how many connections you have and the sequencing of those connections.
No matter your maturity stage, you’ll need to make tradeoffs within your stack to balance your immediate needs against your future tech debt. Don’t try to become a master of all tooling areas from the jump. Rather, focus on a couple primary areas and get super-good-enough with the others until they’re needed.
Here’s a quick breakdown of where to focus your attention based on your stage:
As you get more mature (particularly as you enter the growth stage and do more capabilities assessment work), you’ll want to build in rituals to regularly audit your stack and understand the needs it fulfills.
Here are two resources from my Reforge course that may be helpful as you begin to tackle this work: martech spec sheet template, martech audit template
What’s next for the GTM tech stack
This explosion of options has given modern companies the ability to mix and match their stack to suit ever-complex use cases. But it’s also increased the likelihood of poor redundancy, coupling, interoperability, and focus as the number of tools in the average stack continues to climb.
On the martech side, the landscape has become noisier and noisier (see: the rise of the composable CDP ft. more tools than ever offering the core capabilities of data collection, federation, and audience creation, like Amplitude, Hightouch, Rudderstack, Snowplow, or Braze).
While innovation on the martech side has unseated legacy vendors and given users more choice, we’re only just now starting to see similar pressure put on the de facto CRM solutions (Salesforce and HubSpot, namely).
However, as modern CRM-adjacent technologies focus on more advanced use cases like automating outbounding, they risk becoming noisy and saturated, much like the martech space. CRMs will continue to serve as the center of gravity for data collection, federation, and audience management, but they must evolve to better serve revenue teams by providing forecasting and actionable insights.
Modern product-led teams deserve a better way of building relationships and growing revenue (without spending the majority of their time managing their tooling vs connecting with customers). It’s possible to build a CRM smart enough to know when (and how) it needs to adjust course to manage complexity for you and help you build better customer relationships.
This is the mission we are building toward these days at Clarify, and I’d love to hear your thoughts about it (or answer any questions you have about your rev tech). Reach out on LinkedIn if you’d like to connect.
 | A guest post by
|
🙌
I want to understand the ideal tech stack that a PLG product marketer should be using to drive monetisation?