Schema Design for Product-Led Growth: Mapping Users to Accounts

When I first started implementing CRM schemas for PLG companies, I kept trying to make the standard Contact-Account model work. It doesn't. The Contact-Account model was designed for a world where one person works for one company and that company has one relationship with your product. PLG breaks every one of those assumptions simultaneously.

A user signs up with their personal email. They create a Workspace called "My Project." They invite a colleague. The colleague invites two more people from a different company. Now your product has three users, two email domains, one Workspace, and zero clean mapping to any standard CRM schema.

PLG doesn't break CRM schemas by accident. It breaks them by design. The product is built to spread horizontally across organisations and vertically through teams. Your CRM schema has to be built to track that spread.

The Fundamental Problem: The Wrong Atomic Unit

In a traditional SaaS CRM model, the atomic unit of the business relationship is the Company (Account). In PLG, the atomic unit is the Workspace — the specific product instance where value is being created and where expansion potential lives.

A Company might have five Workspaces: one for Engineering, one for Marketing, one for their client project, one from a trial that was never converted, and one that a contractor created and forgot about. Each of these has a different health status, different expansion potential, and different renewal risk.

If all five are collapsed into a single Company record in your CRM, you can't manage any of them correctly.

The Product-Aware Schema

The Workspace Object (Custom)

Create a custom object — call it "Workspace," "Instance," or whatever reflects your product's language — that represents the actual product environment where usage happens.

Key fields on the Workspace object:

Workspace ID (from your product database, via Reverse ETL)
Workspace Name (user-defined)
Plan Tier (Free, Pro, Enterprise)
DAUs / MAUs (from product analytics)
Feature Adoption Score (composite metric from your analytics stack)
Billing Status (Active, Trial, Churned)
Workspace Owner (the admin contact)

This object is the bridge between your product database and your revenue systems. For the technical implementation of getting product data into your CRM, see our deep dive on Reverse ETL and the CRM product database mirror.

The Workspace Membership Junction Object

A single User (Contact) can belong to multiple Workspaces. A single Company can own multiple Workspaces. This is a many-to-many relationship that standard CRM objects can't represent natively.

You need a Junction Object — "Workspace Membership" — that sits between Contacts and Workspaces and tracks:

The Contact's role in the Workspace (Admin, Member, Viewer)
Their activity level (Last Active Date, Messages Sent, Features Used)
Their invitation source (how they joined the workspace)

This gives you a complete picture of how individuals use your product across multiple contexts — which is essential for both expansion identification and churn risk assessment.

Lead-to-Account Matching at Sign-Up

Every new sign-up requires an immediate L2A (Lead-to-Account) matching decision:

Extract the email domain from the sign-up.
Check the CRM for an existing Company record with that domain.
If found: Associate the new Contact with the existing Company, link to the relevant Workspace, and notify the account owner if this is a new contact from a strategic account.
If not found: Create a new Company record. Check your ICP criteria. If the domain matches your ICP, create a "Prospect Account" and alert the territory rep.

This matching logic should run in real time, in the background, without ever surfacing friction to the user. They sign up. The system does its work. By the time a rep sees the lead, it's already contextualised.

Making the Schema Serve Your Sales Motion

The test of any CRM schema is whether it gives your sales team better conversations. With the product-aware PLG schema, when a rep reaches out to convert a Workspace from free to paid, they can say:

"I can see your team has been actively using [Feature] for the past two weeks. Most teams at this scale find that [Enterprise Feature] makes that workflow significantly more efficient. Want to see it?"

That's a conversation that only happens when product data is properly connected to the CRM. That's the schema working as it should.