Go to market strategy for SaaS.
Product-led, and still forecastable. Self-serve and sales-led motions run over the same accounts in different systems. The go-to-market problem in SaaS is almost always making the product, the CRM and the billing platform agree on what a customer is.
Two motions, one account, no shared view.
Usage sits in the warehouse, pipeline sits in the CRM, subscriptions sit in the billing platform. Asking which accounts expanded last quarter and why becomes an export, a spreadsheet and an afternoon, every quarter.
The product knows. The CRM says nothing.
SaaS — the usage gapThe system under both motions.
Product events on the account
Signup, activation, seat added, limit reached and invite sent piped into the CRM as behavioural events on the company, not pasted into a note.
A PQL you can defend
Written at account level from activation depth, seat growth and workspace age, with the threshold documented and the false positive rate watched.
Separate pipelines for separate motions
Self-serve conversion and sales-assisted trials as different pipelines, so a rep working a trial is not forecast against a checkout that closed itself.
Billing as a first-class object
Plan, seats, MRR, term dates and discount against the company, so the renewal date lives on the account rather than in the billing console.
Retention from primary data
Expansion, contraction and churn as dated events, so net revenue retention is a report rather than a quarterly spreadsheet rebuild.
Expansion worked deliberately
Renewal deals from term dates, usage decline and support volume attached as health signals, and a named owner accountable for the stage.
Strategy that ships as a system.
Diagnose
Where revenue actually comes from today, read from the systems rather than from the deck — sources, cycle times, win rates and the segments that quietly carry the number.
Decide
Segment, offer, motion and pricing written as decisions with owners and dates attached, not as a framework with boxes to fill in later.
Instrument
The CRM, the routing, the definitions and the dashboards rebuilt so the plan is measurable the week it launches rather than the quarter after.
Run it with you
We operate the motion alongside your team until the number repeats, then hand it over with the documentation to keep it repeating.
Every repackaging rewrites history.
A new tier, seat-based pricing, a usage add-on, and last year's cohorts stop comparing to this year. The fix is a subscription model that stores plan changes as dated events, so pricing can move without the retention chart resetting to zero.
What people ask before they commit.
Do we need a warehouse for PLG?
Eventually, usually. Product event volume outgrows a CRM quickly. Early on, aggregated events into HubSpot are enough and much cheaper to run.
How do we define a PQL?
From what actually preceded closed-won and expansion in your own data, at account level rather than per user. Then review it quarterly, because the product changes and the definition ages.
Can HubSpot handle a PLG motion?
Yes, with product events, custom properties and the billing integration done properly. The constraint is event volume, which is what a warehouse solves.
How do we measure net revenue retention properly?
From dated subscription events, not from a point-in-time snapshot. If a repackaging can break your retention chart, it is being computed the wrong way.
How long does it take?
Eight to sixteen weeks for the full system. Instrumenting product events and joining billing are the two longest pieces.
Where people go from here.
Read retention off the system.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.