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.
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:
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?
...And that's why today, journy.io is introducing Relationship Properties!
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:
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.
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.
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.
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.
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.
While product-led growth (PLG) and sales-led growth (SLG) may seem like they are at odds with each other, they can actually work together to capture full business' potential.
Connect journy.io to Segment to collect product traits and events, and send product-led growth (PLG) scores, signals, events and other metrics back to 400+ Segment destinations. In real-time.
Following about two years of research and model testing, we're proud to finally release Smart Signals ✨, small logical indocators that reflect the state of each account/user within a PLG motion. Leveraging Machine Learning 🤖, yet flexible enough to be altered by customers, they eventually shape the foundation for **automatically** detecting signups that are most likely to buy, to expand, or the churn.
Changing the way you do business, case by case.
Detect which signups are most likely to buy. Sell more with less effort.
Automatically surface product qualified leads.
Prioritize PQLs call lists and engage with quick actions.
Add tasks and full PQL context to existing CRM and other engagement tools.
Automated sales playbooks and collaborative inbox.
Onboard. Monitor. Get expansion signals. Reduce churn, proactively.
Automatically detect churn & expansion candidates.
Accelerate onboarding and product adoption.
Align activities around 360° customer view, with health and onboarding scores.
Automated CS playbooks and collaborative inbox.
Build revenue workflows, based on how people use your product.
Use machine learning to uncover new sales opps.
Add slow accounts to nurturing campaigns.
Optimize engagement playbooks for maximum conversion.
Leverage any data without needing engineering.
See which impact your product features have on revenue and churn.
Analyse feature importance, usage and impact.
Build key product metrics without SQL, nor coding.
Easily create customer segments based on any product interaction.
Comply to GDPR and CCPA.
Create your free account and start driving a product-led growth strategy with the tools you're already using.