Building a Revenue Architecture on Top of a Modern Data Stack

This is a blog post based on a talk I gave titled “Building a Revenue Architecture on Top of a Modern Data Stack”, at ProductLed.Marketing’s Blastoff conference in October 2021. This conference focuses on product led growth topics and is targeted to go to market roles. If you’d rather watch the video, please check out the link here, or see it embedded below.

In the session, I covered a few topics, starting with what is revenue architecture, what is a modern data stack, then talking through what current challenges and pain points are for implementing revenue architecture on top of a modern data stack. Finally, I walk through a short example of how a business may activate data for a product-led growth motion. You’ll see the sections here split up into these 4 subheadings.

Revenue Architecture

Starting off with revenue architecture — what is it, and why is it important?

For context here, we’ve all seen the growing trend that go-to-market (GTM) for all SaaS is becoming increasingly complex. Traditionally, GTM consists of marketing and sales. Now, marketing and sales is getting combined with education, product and community, all of which are key components of product led growth. Buyers want to buy in different ways, like self-serve, on demand purchasing, or free trials, instead of traditional enterprise sales motions where you’re assigned a rep to take you through qualification, discovery, presentation, demo, etc. In response to changes in the market, the way businesses sell needs to change too.

Keeping this context of a market shift in mind, then what is revenue architecture and how does it relate? All stakeholders need a cohesive go-to-market plan to organize business systems around. Revenue Architecture sets up your organization to achieve this vision. The 3 pillars of strategy, systems, and programs give organizations the structure to scale the business towards growth goals.

To break it down further, the pillars of systems and programs support the strategy. If the strategy is “we’re going product-led”, then programs like “marketing campaigns”, “sales territories”, and “sales compensation” need to support that. In the same vein, product-led strategy needs to be a key consideration when setting up systems like “storing and utilizing product data”, “campaign automations”, and “reporting and metrics”. Popular revenue architecture strategies are of course not limited to product-led growth, you might also want to pursue strategies like account based marketing or tech touch customer success. Keep in mind that implementing any these strategies for your organization requires adaptation and context. Also, because systems and programs are so important to executing the strategy, the modern data stack and therefore operations and data teams have an increasingly active role in managing GTM along with traditional C suite leaders.

Modern Data Stack

With that basic understanding, let’s get into more detail on the modern data stack, and how it fits into supporting the revenue architecture. Currently, there’s a huge trend in which companies are starting to centralize data, however overall, things are mostly still relatively scattered and unorganized. This makes it really difficult to build a cohesive revenue architecture, because things are owned by different departments and hard to find. It’s difficult to build and deploy off a messy foundation. By default, most companies have started to build these really big sales and marketing stacks, but just having a lot of tools that all do niche things doesn’t mean you have good revenue architecture. Often, excess software purchasing causes teams to end up with various systems that don’t talk to each other well, and this lack of cohesion means that any single point of failure could cause the system to break. Every piece that you’re adding makes the entire system more complex and difficult to maintain, so building a big tech stack isn’t likely to be the best solution for a stable revenue architecture.

The goal is not to just collect more cross-functional data, but to leverage cross-functional data for operational decision making. In light of that, good architecture should follow a few principles of being scalable, robust, flexible, and easy to manage, and the data stack has to be the simple but sturdy foundation that supports this. In the next section, we’ll talk about our recommendations for how to build such a modern data stack.

1. Collect the relevant data sources. This can include usage data, website traffic logs, marketing data, and data from external and internal apps.
2. Store everything in one place, using a data warehouse. Popular choices here are Snowflake, Redshift, or Bigquery.
3. Finally, you can analyze and operationalize the data. This is again, very dependent on the goals of the organization that you’re at, what strategy you’ve set, and what systems are already in place. There’s one thing that may be common across organizations, which is that there will be an experiment and trial period while the team learns and figures out what works and doesn’t work. In this stage, some of these processes may need to be manual, but eventually automating into end systems will be the biggest driver of go-to-market efficiency.

Now, when you have this modern data stack, what can you accomplish with it? This is the stable base in which your organization can now achieve complex goals. For example, orchestrating engaging customer journeys, improving customer acquisition efficiency, and generally shifting from being ‘reactive’ to ‘proactive’, which can help get ahead of future issues like a churning customer before they even happen. Projects like this are only realistically possible to accomplish by having the ability to combine disparate data sources easily and an architecture that is robust and scalable. Additionally, built-in feedback loops in this type of system can help your team address issues before they become big.

Current challenges and pain points

After discussing the benefits and methods of building the modern data stack, it sounds like something worth pursuing. Why haven’t most organizations done this yet? Building and supporting a good revenue architecture isn’t as easy as it sounds. We’ve talked with dozens of companies that are working towards this vision, and in this section, I’ll go over 3 of the biggest issues that are coming up often, which are integration, customization, and activation.

Integration

Every system has their own data model. Even when there is a surface-level integration available, combining data in a coherent, usable way is incredibly hard without custom coding. For instance, let’s say your team wants to connect your product data to Salesforce and Marketo. It sounds simple, but in reality, it will require a series of data aggregations, joins, and look-ups across several objects, such as transactions, accounts, leads, and contacts. It’s not as simple as pushing two tables together.

Customization

Depending on the goals of the company-wide strategy, you’ll need to analyze and customize specific metrics. For example, a very common use case we hear for product qualified leads is looking at usage growth. However, the definition of growth can be quite specific to a single campaign. It can be over different time horizons, and for different metrics like log-ins or transactions or views. You’ll need a place to define this custom logic for each use case, as storing in Salesforce or the data warehouse each time you need something different will quickly get unwieldy and costly.

Activation

Activating data refers to how it actually impacts the organization at the department and employee levels. Activation can be manual or automated, and teams should experiment and test manually what types of data activations are relevant and helpful before building out automations.

One example would be an account manager who needs to understand the full context and behaviors of an account before engaging for an upsell. At first, they may be getting this account information by logging into a few different systems, like a BI dashboard, support ticket system, and Salesforce opportunity history. Eventually, once the AMs know what data points are most useful in these upsell conversations, you may want to pump top-of-funnel accounts into a Google Adwords campaign, create another segment for re-engagement in Marketo, and then send the leads that are actively looking to buy into Salesforce as a new lead. These are all automations that can be powered by the modern data stack.

Activating data for PLG: example in action

To set up the scenario, let’s say we’re working at a company where business is slowly shifting from sales-led to product-led. The chief revenue officer wants to slowly trim down the amount of reps, and give more high quality leads to each rep to increase sales efficiency. We also know that the “magic moment” in their product is when a new team member is added, so they’d like to use that with some other data to tell their sales team what accounts to focus on.

With this information, let’s say the lead scoring formula is composed of new team members added, number of logins, demographic data, and interest signals. This isn’t just a simple lead score you can build in Marketo. It requires pulling multiple data domains together and running calculations that are more complex than adding points together.

From here, to do the last step of operationalizing the data, the CRO also wants to assign top tier leads to any AE with capacity right away with the aim to reach out to the contact on the same day of lead assignment.

We’ll walk through 2 ways to accomplish this workflow, data engineering-centric and Salesforce-centric.

Data Engineering-centric

Accomplishing this workflow through data engineering is very reliant on a data engineer. They’ll need to create a custom table just for this use case. First, they’ll need to run a lot of custom SQL queries and complex joins to create this master table of leads. Then, for customization, they may need to break convention and define the parameters of the use case directly in the data warehouse itself. After that, they’ll use a reverse ETL tool to pump this data into an engagement tool. Finally, an analyst or ops person can actually build out the automations and filters in the engagement tool. Of course, the details here will depend on the organization’s existing setup.

Salesforce-centric

Doing this through Salesforce will require a lot of custom objects and fields, and requires a knowledgeable Salesforce admin. ​After creating these custom objects and fields within Salesforce, then a rollup tool like DLRS is needed to calculate the customized metrics. Finally, you somehow have to get these formulas to trigger complex flows in batch, or send it to downstream tools like Marketo, which isn’t easy to do without custom code.

There are pros and cons to each method. The pros are that with custom work, you can create the exact workflow that’s needed. Cons are that teams may not always have internal resources available, and requires further internal selling to prioritize over other projects. Recreating infrastructure in Salesforce is a huge pain, and it can get redundant as it’s essentially storing the same copy of data across many different systems. Finally, it’s hard for the business team to update business logic. If they wanted to quickly run an experiment or push an update, it’s possible that it will need to wait several months until the Data Eng roadmap clears up.

Conclusion

Even though the modern data stack shows a lot of promise, it has created a lot of dependencies for business teams. To accomplish some of these workflows that can really accelerate go-to-market, teams may need to rely on a data engineer, a Salesforce developer, an analyst, etc. Since buyers are increasingly demanding these changes for preferred purchasing methods, the industry is working on making enablement a lot easier. As the space evolves, new solutions that make executing these product-led growth motions easier will be more and more common.

Companies like Workbase are working on these types of issues with product led growth, revenue architecture, and the data stack. I hope this was helpful, and please feel free to comment or reach out to alicia@getworkbase.io with questions!