A framework for building flexible, scalable RevTech stacks

Revenue teams today face a formidable challenge.

As the focus on complex outbounding motions intensifies, there's a growing need to invest in RevTech stacks that match the sophistication of platform stacks. But how do we build great rev tech stacks–and, more importantly, what do we do with the stacks we already have?

Starting from zero, we could certainly aim to build the Most Perfect Stack™️. But, for most folks reading this, you likely already have some form of stack assembled, in which case the question becomes: Does your stack need “fixing” or just deliberate attention and regrowth?

Truth be told, there isn’t a single magic bullet (or, at least, not one I’ve found yet).

But there is a secret to improve the status quo of RevTech stacks–and help you find the answers to the questions above: Building for flexibility.

After auditing dozens of martech and sales tech stacks over the years, I've developed a framework that puts flexibility at the core of successful RevTech stacks. This is the same approach that I’ve used for years to manage Martech stacks of all kinds and what served as our north star during my time at Ramp.

A brief history: The evolution of revenue stacks

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:

1. Sales tech (2015): Focused on CRM as the center of gravity.
2. B2C martech (2017): Shifted focus to CDP for B2C companies.
3. B2B2C GTM tech (2022): Attempted to unify data between CDPs and CRMs.
4. Decentralized GTM tech (today): Pushes towards "composable CDPs" and the unbundling of CRM capabilities.

This evolution has put revenue teams in a tough position. There's a ton of pressure for a flexible, dynamic tool stack to support ever-advanced data applications, but executing on this need is a precarious balancing act within the existing ecosystem.

Why flexibility matters in the era of decentralized GTM tech

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.

There are six main reasons we're flexibility matters for modern stacks: flexibility today:

1. Revenue teams play a pivotal role in integrated GTM motions: Effective revenue ops requires an integrated stack, mirroring how the teams using those tools work together (sales 🤝 marketing) and work with end users of the product (team 🤝 individual).
2. Revenue teams must integrate their tech stacks: Effective revenue ops requires mirroring the integrated nature of teams and end-users in GTM motions.
3. Revenue teams must adapt swiftly to new challenges: Responding to new ideas and evolving organizational complexity requires new tools. New tools bring with them more complexity and flexibility allows you to respond to novel complexity quickly.
4. Revenue teams must rapidly build and optimize audiences: Quick segment creation and targeting across various tools is crucial in the era of product-led growth and warehouse-first approaches.
5. Revenue teams must minimize tech debt: Agility in handling unexpected changes without increasing system complexity is crucial in today's fast-paced business environment.
6. Revenue teams must future-proof against the evolving ecosystem: Modern companies must be able respond quickly to market feedback and opportunities to innovate. Tooling that’s easy to onboard and offboard underpins their ability to do so easily and agilely.
7. Revenue teams must quickly resolve data issues: Building a world-class buyer experience requires rapid identification, assessment, triage, and resolution in increasingly complex GTM stacks.

How the FRIC to build a great RevTech stack

To live up to the modern pressures of the decentralized GTM tech era, we must focus on creating a highly-flexible stack centered on focus, redundancy, interoperability, and coupling (FRIC).

1. Focus

Focus is when a tool solves a specific discrete problem with high intentionality.

Good focus example: At Ramp, we built a data diagram to explain each tool's use case and used permissions to control the use of each tool. We regularly pruned the stack of unused or duplicate tools, which helped us focus the stack on solving specific needs from other teams and avoid tool spread.

Bad focus example: We initially used both Hubspot and Salesforce as the source of truth in parallel. This created confusion and inefficiency. We resolved this by decoupling the two and using each for a specific purpose: Hubspot for email marketing and Salesforce as the primary CRM.

2. Redundancy

Redundancy refers to multiple vendors offering similar functions within your stack.

Good redundancy example: Using multiple tools for lead management, each with a distinct purpose within the lead lifecycle. This might look like MadKudu for lead scoring, Salesforce as the CRM, and Marketo for marketing automation. This setup gives flexibility without confusion and coverage in case one tool experiences an outage.

Bad redundancy example: A company pays for both HubSpot sales & marketing hubs and Outreach. The marketing team uses HubSpot for email marketing while sales uses Outreach for similar campaigns that could be managed in HubSpot instead. This leads to data silos, inconsistent messaging, and increased tool costs.

3. Interoperability

Interoperability refers to how well your tools work with one another and, as a result, work with you and your needs.

Good interoperability example: At Ramp, after decoupling Salesforce and HubSpot, we connected both to Redshift. This made it easy to keep our source of truth (Salesforce) up to date and let each tool push and pull data as needed. Tools had push, pull, and audience integrations, allowing us to move data efficiently between the ETL, CDP, and other tools into our warehouse.

Bad interoperability example: We initially integrated Voice Storm data into our stack using a brittle connection with HubSpot, even though our source of truth was the warehouse. This led to manual updates in HubSpot and forced workarounds that caused data inconsistencies.

4. Coupling

Coupling refers to the amount of dependency between vendors or systems within your stack.

Good coupling example: At Clarify, we maintain a minimum viable tech stack where each tool has a distinct purpose. We use our own product as our CRM, customer.io for email marketing, Sendgrid for notifications, and PostHog for analytics. Each tool can be easily replaced or upgraded without majorly impacting others, which helps us evolve the stack as we grow without constraint from our original choices.

Bad coupling example: At Ramp, we initially ran bi-directional syncs between HubSpot and Salesforce. The tight coupling because of these bi-directional syncs caused data consistency issues and made it difficult to make changes without impacting the other, which bottlenecked revenue ops. We had to spend a significant amount of time decoupling the pair to fix the issue.

ℹ️ In practice, there will always be some tools that act as bottlenecks (CRM or CDP), but if all your tools are like this, you’re in trouble.

Growing up: Flexibility across growth stages

While the FRIC framework provides a guide for building flexibility into your stack, it's important to recognize that the optimal approach can vary based on your company's stage of growth.

1. Pre-product fit stage

Here’s how your stack likely scores across the FRIC framework:

• Focus: Medium to poor - You're acquiring tools without a defined process to solve immediate challenges.
• Redundancy: Low - You haven't bought many tools yet.
• Interoperability: Poor - You're moving fast and just looking to get the job done.
• Coupling: Poor - You're moving fast, not documenting much, and often the people managing the stack aren't educated in tool operations.

Primary focus: Generalized system understanding Secondary focus: Tool management, capability assessment, and tool procurement

Good example: Choose a lightweight CRM (likely a free tier) and a basic email marketing tool. Use a shared document to log all your tool decisions and basic processes. Integrate all your tools with native connections to avoid complex custom work.

Bad example: Prematurely investing in Salesforce and adding multiple sales enablement tools without clear use cases.

2. Post-product fit stage

Here’s how your stack likely scores across the FRIC framework:

• Focus: Medium to poor - Individual tooling is still a bit choose-your-own-adventure.
• Redundancy: Medium - You may have started to see overlapping competitive capabilities in your stack.
• Interoperability: Medium - You're still moving fast to solve discrete challenges.
• Coupling: Medium - Your stack hasn't grown too much from early pre-product fit.

Primary focus: Tool management and capability assessment Secondary focus: Generalized system understanding and tool procurement

Good example: Using off-the-shelf tools like Keyplay, Clay, and Clearbit to replicate the functions of 5-10 SDRs–which is what our friends at Thena did during this stage.

Bad example: Prematurely implementing an enterprise-level marketing automation platform like Marketo, along with a complex CRM system, without having the team capacity to fully utilize or manage these tools.

3. Growth/hyper growth stage

Here’s how your stack likely scores across the FRIC framework:

• Focus: Poor - Until you design a specific function for each tool in your stack and create rituals for periodically pruning them, focus will remain poor as the stack scales.
• Redundancy: High - You likely have overlapping competitive tools.
• Interoperability: Decent - The newer tools you've brought on have likely improved interoperability.
• Coupling: Poor - You've spent a few years building a frankenstack and things are connected based on however you set them up.

Primary focus: Tool procurement, architecture vision, and org management Secondary focus: Maintain proficiency in earlier stage competencies

Good example: Effectively using a CDP for user tracking and event collection–like Postmates did during their growth phase in 2020–and funneling data to downstream providers.

Bad example: Rapidly acquiring multiple tools for different aspects of your revenue ops without a clear integration strategy, leading to data silos and inconsistent reporting across departments.

4. Scale stage

Here’s how your stack likely scores across the FRIC framework:

• Focus: Poor - Same reasons as in the maturity stage, but dialed up.
• Redundancy: High - You have overlapping competitive tools and need to focus on good redundancy.
• Interoperability: Decent - You're continuing to buy newer and more advanced tooling.
• Coupling: Poor - Your frankenstack has grown up and connections are running wild.

Focus: All six competencies need to remain strong

Good example: Integrating a CDP-style tech stack for acquisition with a CRM-focused stack for enterprise sales. Regular auditing and optimization of tools maintained efficiency, showing good focus. Consolidating audience segmentation tools into something like Hightouch improves interoperability and reduces redundancy.

Bad example: Maintaining separate tech stacks for your self-serve and enterprise sales motions, with little integration between the two.

Practical revenue magic: Steps for building flexibility

We've covered a lot of ground on the challenges facing modern revenue professionals, but I want to take a beat to reassure you that I genuinely believe this is one of the most exciting times to be in this profession.

We've never had better, more comprehensive data available to us about our customers, products, or teams. As companies like Clarify push the RevTech ecosystem further in the coming years, revenue professionals will only become more integral to the success of their organizations.

But for today, here are a few concrete steps you can start to undertake to improve the flexibility of your RevTech stacks:

1. Document your current stack and its interconnections by creating a comprehensive map of your GTM tech stack, including all tools and their connections.
2. Regularly audit your tools and their purposes to prevent tool sprawl and maintain focus.
3. Implement a data governance strategy early to maintain data quality and consistency across your stack.
4. Prioritize tools with robust APIs and integration capabilities to enhance interoperability and reduce the risk of creating data silos.
5. Invest in a central data warehouse as your source of truth to enable easier data movement between tools.
6. Create clear ownership and permission structures for each tool to maintain focus and prevent unauthorized usage.
7. Develop a standardized process for evaluating and onboarding new tools to ensure alignment with your flexibility goals.
8. Regularly prune unused or redundant tools to reduce complexity and improve overall stack flexibility.

‍Flexibility isn't about having the most tools or the latest technology. It's about creating a system that can adapt to your changing needs, scale with your growth, and empower your team to focus on revenue generation rather than tool management.

As we see more momentum behind the "unbundling" of the CRM and the rise of composable CDPs, the importance of stack flexibility will only grow. Companies that can build and maintain flexible RevTech stacks will be better positioned to adapt to new challenges, seize opportunities, and drive revenue growth in an increasingly complex and competitive landscape.

If you'd like to learn more about how the team at Clarify is building to make the future of RevTech a brighter, more flexible reality, check out our CRM Manifesto write up.