Introducing the Revenue Data Graph

In case you missed it, we announced our biggest launch to date here.

‍The evolution from a Product-Led Sales Platform to a Revenue Data Platform feels natural - we’ve always been focused on data. 

We took a potentially controversial approach in the early days of building Pocus. Instead of building sexy features for demos for sales reps, we focused on the nitty-gritty of the data infrastructure. This was foundational for the Pocus Platform and what we now call the Revenue Data Graph. 

In this update, I will dive into the Revenue Data Graph, why it’s essential for the modern go-to-market tech stack, and how it works to power the entire Pocus Platform.   

The Big Data Problem

Accessing and actioning data shouldn’t be such hard work.

Unfortunately, for go-to-market teams, it can feel like pulling teeth. Despite how important data is for powering go-to-market workflows, that data is out of reach and structured in a format that is difficult to consume for most non-technical folks.

In a product-led world, data about customers lives in a data warehouse like Snowflake and is organized around domains, workspaces, teams and users. Valuable data about customers also lives in a CRM, like Salesforce, where the data model is organized around leads, opportunities, and accounts. Reconciling these two models can be challenging and cause a ton of headaches for teams who need access to a holistic view of prospects and customers.

To solve this problem, we’ve seen teams take a few different approaches:

1. Custom build: Data teams build custom data models and dashboards for go-to-market teams.
2. Pipe data into CRM: RevOps teams pipe product usage data from the data warehouse into the CRM. 
3. Do Nothing: Go-to-market teams continue manually working across silos because they lack the internal resources to build a solution. 

This creates a number of problems for modern go-to-market teams: 

1. Custom build → Slow feedback loops. Having a data team build dashboards is great, but getting on their backlog isn’t always easy. Go-to-market teams constantly evolve and need new data, but they can’t immediately access a data engineer’s time. 
2. Pipe data into CRM → Not seeing the full picture. You'll miss insights if you try to push your product usage data into Salesforce’s prescribed model. Salesforce is built for point-in-time data and makes it difficult to see data trends across a time horizon. Because of the rigid data model, you won’t have the same level of granularity as the data warehouse, just aggregations. 
3. Do nothing → Wasted time. Reps waste hours per week manually reconciling two sources of truth. By choosing not to make product usage data available, your sales reps will be flipping between various data sources, doing mental gymnastics to identify their ideal targets.

The end result is frustration for go-to-market, data, and operations teams. Go-to-market can’t get what they need, while data and ops are inundated with requests on their backlog. 

Introducing our Revenue Data Graph

Democratizing access to data in an actionable format for go-to-market teams is not an easy task. This is why we built the Revenue Data Graph.

Pocus’ Revenue Data Graph brings product usage and customer data together into a flexible, unified model that fits your unique business. The graph makes it easy to:

• Democratize data for everyone on the go-to-market team. Unlock product usage data from the data warehouse and make data actionable for the go-to-market team.
• Represent your revenue data ‘as it is’. Spend less time transforming and fitting data into a predefined schema. Instead of aggregated insights, get granular insights about users, workspaces, domains or any other custom object you care about in your business.
• Unify data from multiple sources. Integrate your data warehouse, CRM, and other sources of revenue data into a single model without code. 

The result? Data teams can put go-to-market in the driver's seat and worry less about data silos, governance issues, and data quality concerns. 

Connect the dots between data and GTM

The Revenue Data Graph brings data and go-to-market teams closer together, so there are no ‘language’ barriers between the two teams.

Below are the three capabilities of the Revenue Data Graph.  

Flexible data model 

Many SaaS products require you to contort your data into a rigid predefined schema that looks nothing like your business. It’s especially difficult for product-led companies to fit the typical lead to account hierarchies imposed by most vendors because their world looks nothing like that structure. 

This is why flexibility is key to our underlying data model. 

In Pocus, you can create a Flexible Data Model that matters to your business. No rigid schemas or restrictions. Support any custom object (teams, workspaces, line of business, domains), define associations between those objects, and deliver granular insights for go-to-market use cases.

The Flexible Data Model brings together all of your various data sources. To get started, add your data sources to Pocus (data warehouse, CRM, etc.), then define the objects you care about in your business, and finally create associations between those objects. All in an easy-to-use visual editor. 

Database nerds will understand how important this is - support for your data as it is lowers the barrier to implement. This makes it easier to maintain Pocus as a destination for go-to-market data going forward. 

What does it mean for go-to-market teams? You’ll have the ability to roll up all users by domain, workspace, account, team or any other way you describe your business. In Pocus, your AE might find a high potential account and then quickly drill into domains, workspaces, teams, and users associated with that account. Other tools may only show you that account and associated users but miss the other layers of granularity. 

Last mile modeling

Once you have your unified data model in Pocus, teams may need additional metrics or transformations to satisfy the go-to-market team’s use cases.

Let’s walk through an example. A sales rep wants access to a new metric like ‘invites accepted’ that they don’t currently see in their dashboard. Before Pocus, RevOps would likely have to go and ask the data team to create this new metric (if they have time). 

It’s a relatively simple calculation of ‘invites sent’ minus ‘invites accepted’ but still would require getting on a data engineers backlog. This type of last mile modeling happens often as go-to-market teams have access to this data for the first time and begin experimenting.

‍

The graph includes support for Custom Traits/Last Mile Modeling for this reason. With our no-code editor, RevOps users can calculate new metrics from data that already exists in Pocus, without engineering support. 

Data dictionary 

As part of the Revenue Data Graph, we’ve also built a way for data and go-to-market teams to stay aligned on a standardized set of data definitions. 

How many times have you been in your CRM or marketing automation platform and seen a data point like ‘active users’ and wondered:“How is this calculated? How is it defined? Where is the data coming from?”. 

‍

The Data Dictionary is exactly what it sounds like a list of all the data you have access to in Pocus with clear definitions. Go-to-market teams can easily access the details behind any data point from how it’s being defined to what category it falls within. With the Data Dictionary, you can eliminate the confusion and miscommunication between data and go-to-market teams. In the no-code editor, you can assign categories, add definitions, define data formats, and even assign color codes. 

Partnering with data teams

Data teams are often nervous about the tools the go-to-market team brings to the table. Rightfully so, often, these tools create an additional burden for the data team to set up and maintain while also creating yet another silo of data. 

Data and GTM teams love Pocus because it’s a collaborative platform where data and GTM can get alignment that benefits both teams - the Revenue Data Graph brings this alignment to life. 

Why do data teams love Pocus? Learn more from Aaron Bannin, Analytics Engineer at Miro in this case study. 

🪄Ready to see it in action?

{{widget-demo}}