Short answer: in a product-led company your warmest expansion signal is a power user changing jobs, and you are almost certainly blind to it, because the people who drive your adoption live in your product database rather than your CRM. Sales-led teams track closed-won buyers. You need to track active users: the admin who configured the workspace, the engineer who wired the integration, the analyst who built the dashboard everyone else now depends on. When one of them lands somewhere new, two things happen on the same day. They arrive at a company where they already know your product and have no procurement history with you, and the workspace they left loses the person who kept it alive. One is a land. One is a leak. Most PLG teams catch neither, because the signal never enters a system that is watching.
This post is the motion, end to end: who to track, how to get them into a tracked list when they are not CRM records, what comes back, and how to route both halves.
Why are PLG teams blind to job changes?
Because every job change tracking setup starts by asking which CRM to sync, and in a product-led company the CRM is the wrong source of truth about who matters.
Think about who is actually in your CRM. Contacts who talked to a rep. Buyers on closed-won deals. Maybe a handful of enterprise expansion contacts. Now think about who drives your product adoption: a free-tier user who invited nine colleagues, the staff engineer who shipped your SDK into production, the ops lead who owns the billing seat. In a self-serve motion those people may never have had a sales conversation at all. They signed up with a work email, hit a credit card form or never hit one, and became your most important relationship without ever becoming a CRM contact.
So when a sales-led company syncs its CRM into a job change tracker, it gets its champions. When a product-led company does the same, it gets whichever fraction of its users happened to meet a rep, and it systematically misses the highest-intent people in its base.
The volume you are missing is not marginal. 2 to 3% of B2B contacts change jobs every month, and only about 6% of them tell a vendor they used to use, which means 94% of these moves reach you as silence. Apply that rate to your active user list rather than your CRM and the number gets uncomfortable fast. On a 10,000-contact list, roughly 20% surface as hot leads on day one, about 2,000 relationships that have already moved and that you are still modelling as if nothing happened, then 200 to 300 new warm leads every month after that.
A sales-led team losing a buyer loses one line in a pipeline report. A PLG team losing a power user loses the only person who knew why the workspace existed.
What two events does one move create?
Always two. Write them down separately, because they get owned by different teams and both get dropped if you only build one.
The land. Your power user is now at a new company, and your product is the one they already know how to use. Nothing about the enterprise sales cycle applies here: there is no evaluation to run, no bake-off, no internal champion to recruit, because the champion is the person who just started on Monday. This is the cheapest land your funnel will ever see. Champion-sourced deals close with 2.7x higher probability than cold pipeline, in roughly half the sales cycle, and the mechanism is exactly the same one at work here. Trust is pre-built. The person has already done the hardest part of your sales process, which is learning that your product solves their problem.
The leak. The workspace they left is now running without its owner. In a seat-based or usage-based model this is where revenue quietly disappears: nobody cancels, they just stop expanding, then stop renewing seats, then churn at the annual boundary with no warning signal because usage decayed gradually. The person who evangelised your tool internally is gone, their replacement inherits a tool they did not choose, and there is now an opening for a competitor the new person used at their last job. The full version of this motion is in champion departure as a churn signal, and what Customer Success owns in it is on the use cases page.
The leak is usually worth more than the land, and it is the one PLG teams ignore, because expansion dashboards show usage trending down weeks after the cause and never show the cause itself.
Who counts as a power user worth tracking?
This is the PLG-specific hard part. A sales-led team has an obvious tracked list: closed-won contacts. You have a user table with a lot of rows and no opinion about which ones matter.
Rank by what the person did, not by their title. Four signals, roughly in order of how predictive they are:
- Admin or owner on the workspace. They chose you, configured you and probably pay you. Track all of them, always.
- Technical implementers. Whoever created the API key, installed the integration, authored the webhook. These people carry your product in their heads and reach for it on day one at a new job, because the alternative is learning something else while already onboarding.
- Depth of use, not frequency of login. The user who built the thing other people use. Sustained weekly active over a quarter beats a high login count in one week.
- Inviters. Anyone who brought three or more colleagues in. They have already demonstrated they will sell your product internally without being asked, which is literally the behaviour you want at the new company.
Then exclude aggressively. Tracking everyone who ever signed up is the mistake that makes a PLG job change program look expensive and noisy at the same time. Free-tier tyre-kickers with one session, personal-email signups, and anyone whose entire usage happened more than two years ago can all wait. Start with admins and implementers from accounts that have ever been active, and grow from there once the routing works.
One more thing worth noticing: your power users are frequently individual contributors. Engineers, analysts, ops people. That matters later, when you configure fit rules, and it is where most PLG implementations quietly break themselves.
How do you get product users into a tracked list?
Through the API, because there is no CRM sync that will do this for you. This is the step that makes the PLG motion different from everything else on this blog, so it is worth being concrete.
POST /v1/contacts upserts up to 1,000 contacts per call, and the dedupe order is documented as crm_id then LinkedIn URL then email then name plus company (Champions API reference). The important consequence: crm_id does not have to be a CRM id. Send your own internal user id. It is described in the contract as “your CRM record id, best dedupe key”, and what it actually does is give you a stable key you control, so re-running your export tomorrow updates the same people instead of creating a second copy of your user base. Pick one id, your product’s user primary key, and never change it.
A minimal row from a product database looks like this:
{
"contacts": [
{
"full_name": "Dana Reyes",
"company": "Northwind Ltd",
"title": "Staff Data Engineer",
"email": "[email protected]",
"linkedin_url": "https://linkedin.com/in/danareyes",
"crm_id": "usr_8841",
"segment": "customer",
"account_domain": "northwind.com",
"relationship_start": "2024-03-11",
"last_activity": "2026-10-09",
"custom": {
"plan": "team",
"workspace_role": "admin",
"seats_owned": 14,
"created_api_key": true,
"weekly_active_weeks": 37
}
}
]
}Four decisions are hiding in that payload, and they are the ones to get right before you send 10,000 rows.
linkedin_url is required for tracking. This is the real constraint on a PLG list, and you should plan for it rather than be surprised by it. Contacts without one land in a Needs LinkedIn state until you supply one with PATCH /contacts/{id}. Your user table has emails, not profile URLs, so expect a resolution step. Start with the subset you can resolve, ship the routing, then widen.
Map your lifecycle onto segment deliberately. The field takes customer, churned, closed_lost or open_pipeline and normalises free text. Paying workspace members are customer. Lapsed or downgraded accounts are churned, and those are interesting rather than dead, because a user who liked you at a company that stopped paying is a clean land somewhere else. Active free-tier users map most honestly to open_pipeline. Decide this once and encode it in your export, because segment is what later lets you ask the plays endpoint for one motion at a time.
Use custom for the product facts. Keys up to 60 characters, values string, number or boolean. This is where plan, workspace role, seats owned and activity depth live, and it is what turns a raw move into a prioritised one. A move by an admin holding fourteen seats is not the same work item as a move by a solo free user, and without these fields nothing downstream can tell them apart.
Batch and poll. Up to 200 rows commit inline and come back with status: committed. Larger batches are queued: you get status: queued and a poll path, and you call GET /imports/{id} until it reports committed or failed. Write limits are 120 requests per minute per workspace, reads 600, so a backfill of a large user base is a loop with a sleep in it and not a thundering herd. Backfill once from your warehouse, then push incrementally as users cross your power-user threshold. The field reference and delivery modes are summarised on the API page.
What comes back, and how should you route it?
GET /v1/changes lists detected events typed moved, promoted, title_changed, left or profile_not_found, each with from and to company and title, and a since parameter for “what changed this week”. GET /v1/plays is the recommended action layer on top of it, with types direct, referral, watch, promotion, churn_risk and archive, filterable by segment, owner, account_fit, contact_fit and since. Webhooks deliver play.created, contact.changed, run.completed and run.paused, signed with X-Champions-Signature and carrying an event_key for deduplication. The idempotency and retry patterns are in job change webhooks.
Three routing rules are worth setting up on day one.
Route churn_risk to CS before anything else. A contact at a customer account who moved away produces both a sales play and a churn risk play. The churn one is an internal note, not an outreach draft, and in a seat-based model it is your earliest possible warning that the workspace is about to decay. If you only wire one webhook, wire this one.
Do not route the land to a territory owner by default. A new-logo router will hand your warmest signal to whoever owns the new company, which is a person with no history with the user. The product relationship is the asset. Route on the prior relationship first and let territory rules apply afterwards. The record-level version of this argument, including why dedupe rules go blind on exactly this event, is in when a contact changes jobs, don’t overwrite the record.
Prioritise by to_started_on and by your own custom fields. Mandate and budget concentrate in a new hire’s first ninety days, and someone who owned fourteen seats at their last company is a different work item than someone who owned one. Both inputs are already in the payload. Use them.
Why does your ICP configuration break this?
Because of the individual contributor problem, and it is the single most common way a PLG implementation ends up producing nothing.
Fit rules come in two halves. Account rules cover industry, employee range, HQ, keywords, funding stage and exclusions. Contact rules cover title include and exclude lists, seniority from c_level through vp, director, manager and ic, plus functions such as engineering, product, revops and customer_success. A play is typed direct when account and contact both fit, referral on account fit alone, and watch on contact fit alone.
Now consider the default instinct, which is to copy the enterprise ICP: VP and above, revenue functions. Apply that to a PLG base and you have just filtered out your staff engineers, your analysts and your ops leads, which is to say the people who actually adopt your product. Your power users are ICs. Include ic seniority and the technical functions, or the motion returns an empty list and you conclude the signal does not work.
Two secondary points, now that fit types matter to you. First, watch plays are more valuable in PLG than in sales-led selling. A watch means the person fits but the new company does not match your account rules, and in a self-serve motion that is still a real outcome: they can sign up on a card at a company you would never have prospected, with no seller involved. Do not suppress watch. Second, promotion plays deserve their own treatment. A power user promoted inside an existing account is budget authority arriving at an account that already uses you, which is the cleanest expansion conversation in your book.
What does the outreach actually say?
The claim is different from the sales-led one, and the difference is the whole advantage.
A sales-led champion play opens on a purchase: you bought this, it worked, here is the same thing here. Your opening is stronger, because it opens on use. This person did not approve a budget line; they used your product daily and chose to keep using it. That is a more credible endorsement and a much easier internal story for them to repeat, because they are not defending a prior decision, they are recommending a tool they like.
So lead with the artefact, not the relationship. What they built, what they shipped, what they will have to rebuild from scratch in whatever they are using now. Make reinstating your product the path of least resistance in their first month, when they are visibly rebuilding their stack anyway and nobody questions it. Offer the migration, the setup, the import. Then get out of the way.
And keep one person per move. The old account needs a conversation too, but it is a different conversation with a different owner: find the new internal sponsor, confirm who inherited the workspace, make sure nothing breaks. Broader framing on the outbound half is in warm outbound, and the sales motion is on the use cases page.
How do you measure it?
Report two numbers, not one, because a PLG job change program that only counts new logos will understate itself by the larger half.
Expansion sourced from moves: new workspaces, signups and paid conversions traceable to a tracked user arriving somewhere new. This is the number that gets the program funded. It only works if a lineage field survives the move, which is the point of a stable crm_id.
Retention defended: workspaces where a departure was caught early enough to identify a new sponsor before renewal. Harder to attribute and worth attributing anyway, because 65% of a company’s business comes from existing customers, the odds of selling to an existing relationship are 60 to 70% against 5 to 20% for a new prospect, and acquiring is 6x more costly than retaining. In a product-led model where nobody has to talk to you before leaving, that asymmetry is sharper, not softer.
The six metrics worth standing up for this channel are in champion-sourced pipeline metrics.
Quick answers
- Why do PLG teams miss job changes? Their champions are product users, not CRM contacts, so a CRM-synced tracker never sees them.
- Where does the tracked list come from? Your product database, pushed with
POST /v1/contacts. Use your internal user id ascrm_idfor a stable dedupe key. - Which users should I track first? Workspace admins and technical implementers, then deep sustained users and anyone who invited three or more colleagues.
- Do I need LinkedIn URLs? Yes, tracking requires one. Contacts without one wait in Needs LinkedIn, so plan a resolution step before you backfill.
- What breaks most PLG setups? Copying the enterprise ICP. Excluding
icseniority filters out the exact people who drive product adoption. - Which event matters more, the land or the leak? Usually the leak. A departed power user is the earliest warning that a seat-based workspace is about to decay.
- Should I ignore moves to companies outside my ICP? No. In self-serve, a
watchplay can still convert without a seller touching it.
Where to start
Do not build the whole thing. Run one query against your product database: workspace admins at accounts with any activity in the last twelve months, where the account is not currently in an active sales cycle. Resolve LinkedIn URLs for as many as you can, push them, and look at how many have already moved. That day-one list is the entire business case, and on a list of any size it will be bigger than you expect, because roughly 20% of a contact list surfaces as already moved on the first pass.
Then decide the two routes before the second batch: churn_risk to whoever owns retention, everything else to whoever owned the product relationship. Programs that fail here fail at routing, not detection.
Champions watches the people you send, detects moves and promotions, scores the new company and role against your rules, and hands back a play with the best known email and a suggested opener, with Slack routing and write-back across Salesforce, HubSpot, Pipedrive, Zoho and others. There is no app to install and no logins for your team. The platform page covers the monitoring loop, how it works covers the sequence, the API page has the endpoints and delivery modes if you would rather consume the feed and build your own routing, and the job change tracking comparison puts the detection approaches in the category side by side. If you are weighing this against writing it yourself, build versus buy has the honest version of that cost.
We also back the signal contractually. If champion-sourced revenue does not reach 2x your annual service fee, you are covered under section 9.6 of our terms. Among the tools in that comparison, only Champions offers that.
Want to know how many of your power users have already left the company you think they work at? Book a demo and we will run detection against your list so you can see the moves against your own accounts. If you would rather start with the integration questions, email [email protected] and we will walk through the export shape before you write any code.
Your product-led motion already proved the hardest thing: these people like your software enough to use it without being sold. Following them is the cheapest growth you are not doing.
