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.
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.
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:
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:
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.
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.