This is the second section in a four-part series walking you through how to build out your own product-led growth (PLG) customer relationship management (CRM) tool. Check out part one here.
Part 2: Prepare your new CRM
Choosing a CRM tool
There is no shortage of CRMs available to choose from. With hundreds of options ranging in price and specialization, it can feel daunting to pick just one. It's no surprise that many teams opt for the tried-and-tested options like Salesforce and Hubspot.
However, to get the most out of the hard work you completed in part 1, you may want to choose a product that supports custom object types (beyond things like "Company" and "Contact").
Additionally, any CRM should have some form of:
Workflow management. Whether they’re called “deals,” “opportunities,” or “projects,” your CRM should support the concept of tracking an initiative through distinct phases or stages.
Reporting and data visualization. A big reason for building a PLG CRM is to make it easier for a wider range of people within your company to dive into product data.
Automation. In any PLG motion, it’s important to be able to update the status of your customers without manual, human intervention. Additionally, automation capabilities allow you to trigger alerts and customer touchpoints when your users meet certain criteria.
Setting up your data model
To prepare your chosen CRM for your product data, create objects that map 1:1 to the entities you modeled in part 1. You will likely rely on a combination of both off-the-shelf objects and custom objects to establish this hierarchy.
Let's look at a simple example.
Most B2B SaaS products have users who belong to a ProductOrganization (this is probably called something like Team, or Workspace, etc.). There may be more than one Product Organization created by employees of the same company. This is where the assumptions of traditional CRMs start to break down. For example, traditional CRMs assume that someone can belong to exactly one company.
In our PLG CRM, we need to create a model that follows 2 simple rules:
Every product entity should map 1:1 to an object in your CRM
The objects in your CRM should have the same relationships to each other as their corresponding product entities. For example, if a user can belong to more than one workspace in your product, your CRM should allow for a 1:many relationship too.
In this example, we've created a custom child object in our CRM called Workspace. Each Account can have as many Workspaces as we need. Similarly, a Contact may have user accounts in multiple Organizations. To establish a 1:1 relationship, we create a custom child object of Contact that represents that person's user entity for a single ProductOrganization.
Here's what our model looks like with example data for a fictional company, Acme, Inc, that has 2 Product Organizations within our product. The Organizations have a user in common: Gail Harrison.
Notice that, even though Gail Harrison is a user in more than one Product Organization, we still have a 1:1 relationship between product entities and CRM objects. (This will be important in part 3 so that we can keep information about Gail's usage within Acme-US separate from data about her activity within Acme-EU.) However, because both users are Gail Harrison, each user record is tied back to a single Contact.
Mapping out these relationships for the first time can be tricky, but this model ensures that you retain granularity about what is actually happening in your product.
Organizing your CRM
The fields you add to each object will depend on:
The properties, metrics, and events you defined in part 1. For example, what are the relevant bits of information for an Organization versus an individual User?
Additional data from non-product sources you may want to track. This might include firmographic information about your customers, information about marketing campaigns your users have engaged with, and custom inputs to be populated by your team.
Next, consider the different phases of your customer journey. For example, you might have distinct phases like:
Acquired: a user has signed up but has not (yet) reached your pre-determined activation milestone.
Activated: one or more users have reached the activation milestone but have not yet passed the retention/habit phase.
Expanding: the account is healthy and showing signs of growth.
At Risk: the account is stagnant, stalled, or showing other signs of contraction or churn.
Churned: the account is no longer active.
Each of these stages should be mutually exclusive (i.e. you cannot be in 2 stages at the same time) and must be defined using the events, metrics, and properties you modeled in part 1 (along with any other information already in the CRM). Now, when a user/account meets the criteria, their stage will automatically be updated in your CRM.
Keep in mind, you may have different funnels for users that are different from the journey of the Company or Organization as a whole. The model we defined in the previous section allows you to consider each layer of the hierarchy separately when necessary.
In the next sections, we'll look into how to load your modeled data into your CRM and how to drive actions based on the data. Check out parts 3 and 4 here.
Throughout this series, we'll show you how to build a basic "PLG CRM" using free or low-cost tooling. Whether you choose to build your own or work with a dedicated platform like Pace, there are many new and interesting workflows you can enable by enhancing your existing CRM with data from your SaaS product.
Have you built your own PLG CRM or used similar tools to add product usage data to your CRM? Send us a note! We’d love to hear about your experience and feature you in a future post.