How to Build Your Own "PLG CRM" (Part 1)

May 3, 2022
Rez Khan

This is the first section in a four-part series walking you through how to build out your own product-led growth (PLG) customer relationship management (CRM) tool.

0. Before you begin

It is possible to build a workable customer relationship management (CRM) tool for a product-led motion without first developing a model for how your users interact with and adopt your product. However, spending the time upfront to observe and measure user behavior will allow you to organize your CRM around key milestones and metrics, making the system as valuable as possible for your internal teams.

Additionally, you'll need a central repository (typically a data warehouse like Snowflake, Redshift, or BigQuery) for product usage information collected via standalone customer data infrastructure like Snowplow or a complete customer data platform like Rudderstack, Segment, or mParticle.

Let's begin by discussing the typical product adoption journey for a B2B SaaS application.

Aha! moments occur when users first experience a product's primary value proposition.
Defining your activation and habit milestones will help you set up your PLG CRM to more closely map to your customer journey.

Here are some questions to consider as you define the important elements of your customer journey:

  • What steps does a user need to take to start getting value from your product? These are typically things like connecting data sources, importing contacts, or setting up workspaces. Without completing these steps, your users cannot fully start to use your product.
  • What is the primary way you measure usage of your product? This metric should align with how customers experience your core value proposition. For a collaboration tool, it may be the number of users added to the workspace. For design software, maybe it’s the number of artboards. Independent of what your product does, understanding this core usage metric (sometimes referred to as your “North Star metric”) will help you segment your users into actionable buckets.
  • What is your “activation” milestone? Closely related to the previous question, understanding the point at which users begin to use your product will inform the structure of your PLG CRM. Note that, in some cases, your activation milestone (sometimes called the “aha moment” may correspond to a series of actions. For example, the aha moment for video conferencing software provider, Zoom, might be configuring, scheduling, and completing your first video meeting. (If you haven’t defined these milestones, check out this blog post from Whatfix for a primer.)
  • What are your “habit” milestones? It is important to understand when users have begun to incorporate their usage of your product into their regular workflows. Habit milestones are a series of events (or repeated completion of a single event) that indicates this level of consistent engagement. Using the same example as above, Zoom’s habit milestone may be scheduling and completing 5 video meetings in the first month. It’s important to consider the natural usage frequency of your product. Compare a tool like Slack where typical users interact with the software multiple times a day versus TurboTax where even the most loyal users are likely to use the product seasonally.

1. Ingest and model your customer data

Once you’ve decided on the important metrics and milestones that are most important for understanding how users are interacting with your product, you will need to define these based on the information you collect. 

First-party data that you collect via analytics and customer data tools will always be an event, a metric, or a property.

Important data can always be described as an event, a metric, or a property.

Events are, in many ways, the building blocks of product usage data. Each event represents a specific action taken in the product at a given time. Powerful on their own, events can also be aggregated into metrics (ex: number of logins in the last 30 days) or be parsed into properties (ex: an “Invited user” event that contains the email address of the person added can be transformed into the “Last user added” property). 

Metrics, as the term implies, are numerical measurements against a specific dimension. Unlike events, metrics are typically pulled directly from the back-end database of your product rather than passed to an SDK associated with a tool like Segment.

Properties are non-numerical data that describe users, their actions, and the context in which they occurred. Properties may originate from the back-end of your application or from attributes passed via event-based tracking.

Events, metrics, and properties can all describe an individual session, a specific user, or an entire account within your product. Once this data is stored in the data warehouse, we must model it to tie each piece back to the right object to make use of it in our CRM.

Over the past year or so, dbt has emerged as the de-facto tool for modelling this type of data. In fact, their documentation includes an in-depth tutorial for building a dbt model for a typical B2B SaaS application.

This tutorial walks through some of the most important steps for transforming data into a model that can be used by most CRM tools:

  1. Identify and define your entities (the objects that are most important to independently keep track of). For most B2B products, your list of entities will include users, accounts or workspaces, and the company they work for. However, there may be more.
  2. Establish the hierarchy for your entities. Do all users belong to a workspace? Can users create multiple workspaces at a single company? Can a user exist in more than one workspace? Mapping your entities together in a hierarchy will help you understand the relationships between them and define the data model that will ultimately be used in your CRM.
  3. Model your entities, starting with the child-most entity. At this step, we decide which data should belong to which entities. That is, what events, metrics, and properties describe each one. It is helpful to start with the “child-most” entitle (the most deeply-nested entity in your hierarchy) to avoid redundancy.

In the next sections, we'll look into how to prepare your CRM, how to load your modeled data into your CRM, and how to drive actions based on the data. Check out part 2 here.

Wrapping up

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.