Improving PLG playbooks for B2B SaaS through relationship properties

In modern SaaS platforms, a single user can be a part of different accounts through one single login. Once signed in, he/she can simply switch from one account to another. Some other platforms even combine user-based and account-based subscriptions, allowing users to be a part of 0, 1, or multiple accounts. GitHub would be a perfect example of such multi-account-multi-user (MAMU) environment.

To run a product-led growth (PLG) strategy in a MAMU environment, it is imperative that conversion, expansion, and retention playbooks support any possible scenario, thereby needing to act on what users are doing individually in certain cases, as well as in function of one specific account in others.

While most (better) PLG platforms nowadays allow you to collect events, screen and page views that are associated with 1 user, or 1 account, or a unique combination of 1 user and 1 account, there is often a problem residing on the data scheme level. Indeed, most data schemes are created to only support properties for users and for accounts (and sometimes also for workspaces and organizations)… but very rarely for unique specific relationships between users and accounts. Yet, this is exactly what aforementioned PLG playbooks require.

Why are relationship properties so important for a B2B PLG motion?

To better understand the importance of relationship properties, let's take a step back and summarize what it takes for B2B companies to run a PLG motion:

1. Vendors need to collect all user activities, potentially also mapped to the account they were in when performing these activities.
2. For both users and accounts, a machine learning process identifies PLG signals based on properties, events, screens and pages. These signals contribute to identifying product-qualified-users/-leads (PQLs) and -accounts (PQAs), as well as expansion and churn candidates.
3. For the sake of our reasoning, let's focus on PQAs in a B2B context. Once PQA signals are defined, each account will receive a PQA score reflecting its likelihood to convert... as an account!
4. Now that we know which account is most likely to convert, we need to determine which user (account-PQL) within the account we should engage with:
   a. We will look at each user's activity within that specific PQA. At this point, we only care about what users did in the given PQA, not in any other account they may be part of.
   b. Equally important, we need to know each user's specific relation to the given PQA. To start, what 'Role' does each user have within the given PQA? Do other important relationship property values match given account-PQL signals?

To further illustrate the importance of relationship properties, let's examine above property named 'Role'. Suppose you have a multi-account-multi-user platform where Elon Musk is creating three accounts: Twitter, Tesla, and SpaceX... (and soon X.AI ;-) However, since he has limited time to manage everything, he designates himself as the owner of the Twitter account, as one of many admins of the Tesla account, and a mere user in the SpaceX account. It is clear that if all 3 accounts were PQAs, you would reach out to Elon only in case of Twitter and maybe Tesla where he is owner and admin, but not for SpaceX where he’s merely a user. (At least, purely in terms of Role. He might still be a power-user ;-).

Now, where should we store Elon’s roles?

• On user level? No, since unlike his name or date of birth, Elon’s role differs from account to account he is part of.
• On account level? Well, since each of Elon’s accounts has several users, that's obviously not possible neither.
• On unique relationship level between one user and one account? Absolutely!

...And that's why today, journy.io is introducing Relationship Properties!

Which impact do Relationship Properties have on the journy.io PLG platform?

Changing a platform’s base data scheme have quite significant consequences to the entire platform. But as previously explained, for very good reasons. The introduction of relationship properties provides following improvements:

Data intake

The first step in introducing relationship properties, is to collect them. Our data intake is achieved through either implementing our native SDKs, either by connecting the Segment customer data platform, either by connecting your data warehouses, yet also through Segment.

We have changed our native APIs/SDKs to support these changes.

When using Segment, developers should add the following to their group call.

Other intake connections, such as CRMs and marketing automation platform, won’t add any relationship properties, unless specifically supported. To date, unfortunately, none provides support for such properties. That’s why we’ve build our own playbooks, so we can trigger engagement sequences from within journy.io.

Presentation

The relationship property definitions are presented in journy.io’s data catalogue, in between user and account properties. We support all types of properties, with a default text property ‘Role’ being populated at creation.

Next to the relationship property definitions, you can obviously see its values when browsing users and accounts. Each user and account has respectively a list of related accounts and users where relationship properties can be shown.

Engagement

Reflecting above use case (with Elon Musk in a multi-account-multi-user environment), we created ‘User Actions’ in Account-based playbooks.

The principle is that account conditions are created to define which accounts are to enter a playbook, to then define actions that will be performed for specific users. To select which users to engage with, you can specify conditions on both general user properties ...AND: relationship properties against the current account in the playbook.

Above screenshots illustrates a playbook in which account ’The Beatles’ will enter, where only users with ‘Role = User’ (being John Lennon in previous chapter) will be added to a HubSpot list to start receiving emails.

Personalization

While it's now possible to trigger engagement sequences in third-party software, a problem remains: these platforms cannot process relationship properties on their own. To address this, we have built a Personal Messages editor that can include relationship properties alongside native user and account properties.

For example, imagine you want to send a HubSpot task to an Account Executive to reach out to Elon within the context of Twitter. HubSpot already holds all relevant information on the user (contact) and account (company) levels through real-time syncing with HubSpot. But what about Elon's "Role" or other relationship properties? To solve this, we allow including relevant properties in the task being created.

Conclusion

To conduct a correct B2B PLG motion, you need to act on both accounts and users. First, proper product-qualified accounts (PQAs) must be identified, to then engage with the best possible users (PQLs) from within these specific PQAs.

To determine which account users best to engage with, you need context of each user within their each account, namely knowing what events they triggered, which screens and pages they’ve looked at... and what specific relationship data they hold.

In our journey to market a best possible PLG platform for B2B SaaS, and seeing this as the only remaining missing piece to conduct a proper PLG motion, we are now introducing Relationship Properties. Feel free to try it out here.