2 min lesson
The data model & sources of truth
Rebuild the parts of "The data model & sources of truth", then say why each one matters.
Step 1 of 2
Every enrichment formula, scoring rule and routing decision sits on top of one thing: a data model that knows what a person and a company are. Get the objects wrong and every downstream system inherits the mess.
At Cursor the model is unusually leaky, because the strongest buying signal isn't a form fill. It's a developer who signed up, opened the editor and ran the agent forty times this week. A GTM Engineer who treats product usage as a second-class input next to marketing leads has already lost the plot for a developer-led, PLG-to-enterprise motion.
Start the interview answer by naming the objects and how they relate, not by jumping to a tool.
- Lead
- An unqualified person, often a form fill or a list import, that hasn't been matched to a known account yet. A holding pen, not a permanent home.
- Contact
- A person resolved to a known account. The identity you actually act on - email, role, seniority, the signals you scored.
- Account
- The company. The grain most GTM logic runs at: domain, firmographics, technographics, aggregate product usage across all its users.
- Opportunity
- An active deal tied to an account. Where revenue lives and the won/lost outcome you feed back into scoring.
The hard part is identity resolution: stitching a lead that arrived as a personal Gmail to the account it actually belongs to and recognizing that the same human shows up as a product sign-up, a webinar registrant and a partner referral.
Learn more
References
Source of truth: CRM, warehouse or both
Source of truth: CRM, warehouse or bothname the boundary
A common interview trap is declaring "the CRM is the source of truth" and stopping. The honest answer splits responsibility by what each system is good at.
- System
- Warehouse (Snowflake/BigQuery)
- Source of truth for
- Product usage, computed scores, modeled accounts
- Why
- Joins billions of events; cheap to recompute; where modeling and SQL live
- System
- CRM (Salesforce/HubSpot)
- Source of truth for
- Deals, owner, activity, pipeline stage
- Why
- Where reps work; system of action and record for revenue
- System
- Orchestration (Clay)
- Source of truth for
- In-flight enrichment, transient working state
- Why
- Stages a record mid-pipeline; not a system of record
| System | Source of truth for | Why |
|---|---|---|
| Warehouse (Snowflake/BigQuery) | Product usage, computed scores, modeled accounts | Joins billions of events; cheap to recompute; where modeling and SQL live |
| CRM (Salesforce/HubSpot) | Deals, owner, activity, pipeline stage | Where reps work; system of action and record for revenue |
| Orchestration (Clay) | In-flight enrichment, transient working state | Stages a record mid-pipeline; not a system of record |
Pick one writer per field. Two systems both claiming to own a contact's title is how you get silent overwrites.
The durable rule isn't "one source of truth for everything," it's one writer per field. The warehouse owns the ICP score, the CRM owns the deal stage and a sync that respects those boundaries keeps both honest. When you say this in a panel, you sound like someone who has cleaned up a bidirectional-sync disaster, because the rule exists precisely to prevent one.