Why your PLG motion is leaking revenue — And how to fix it
Most PLG companies don’t have a product-led growth problem. They have a data orchestration problem.
That was the key takeaway from our recent webinar, Plugging the PLG Leak and Unlocking Enterprise Revenue, featuring Josh Hill — a 25-year GTM operations veteran and one of the most recognized voices in the Marketo community — alongside Ryan Nelson, Senior Director of Solution Engineering at Openprise.
The conversation cut through the hype around product-led growth strategy and got into the messy operational reality that most teams are actually living in. Here’s what you need to know.
What is a PLG motion (and how is it different from enterprise sales)?
A product-led growth motion is a go-to-market model where the product itself drives user acquisition, expansion, and retention — typically through a freemium or free trial offer. In a PLG model, users self-serve, conversion happens without heavy sales involvement, and success metrics center on sign-ups, daily active users, and free-to-paid conversion rates.
This is fundamentally different from a traditional enterprise sales motion, where MQLs and SQLs flow through a human-heavy process, deals involve buying committees, and the sales cycle is measured in weeks or months — not credit card swipes.
The challenge for most B2B SaaS companies is that they’re trying to run both motions simultaneously — and the seams show. As Josh Hill put it: “Technology does not solve misaligned GTM workflows. Going upmarket from your PLG flow is the biggest way to break the system.”
The 3 most common PLG misalignments (and why they stall revenue)
When PLG initiatives underdeliver, it’s rarely because the product isn’t good enough. According to Josh and Ryan, the failures almost always trace back to one of three root causes:
- Strategy misalignment across teams: Product, growth, marketing ops, and sales leadership are all moving at different speeds. Executives push for PLG-to-enterprise conversion before the process is defined. Teams equate free users with MQLs — or worse, product qualified leads — without having built any model to distinguish high-propensity users from people who are just poking around.
- Process gaps no one mapped: Most teams have never walked through their entire customer journey from pre-signup to offboarding in one room, across all teams. Handoff points are undefined. Swim lanes overlap. The result: experiences that feel enterprise-y to free users, or PLG-y to high-value accounts — neither of which converts well.
- Data that exists but can’t be acted on: This is the big one. “PLG is rarely failing due to a lack of data,” Nelson noted. “It’s frequently failing because the data’s not in an actionable format, getting to the places it needs to be.”
User event data lives in the product and never makes it to your MAP. Or it floods into Marketo and Salesforce indiscriminately, clogging queues and driving up database costs. Either way, the signals that should be triggering journeys — usage spikes, feature adoption, expansion indicators — aren’t reaching the systems that need them.
How to define product qualified leads (PQLs) — and why most teams get it wrong
Product qualified leads are users who have demonstrated, through their in-product behavior, a readiness to buy or expand. They’re distinct from MQLs (which are based on marketing engagement like form fills and webinar attendance) and from simple free-trial signups.
The problem Josh sees repeatedly: teams under pressure to show pipeline will equate any free user activity with a PQL — or skip the definition process entirely. A salesperson reaches out to someone who was just browsing a feature. The user gets annoyed. The rep wastes time. Neither outcome builds toward revenue.
How to define PQLs correctly:
- Identify the specific in-product behaviors that correlate with conversion in your existing customer base (feature usage depth, frequency, team expansion, etc.)
- Build a scoring model that weights those signals — not just recency of login
- Separate single-user activity from account-level signals, especially if you’re targeting enterprise expansion
- Feed those signals into a decision layer that can distinguish between “curious free user,” “likely upgrader,” and “ready for sales contact”
The difference between a PQL and an MQL isn’t just the data source — it’s the intent signal behind it.
A PLG framework that actually scales: The 4-layer stack
Josh walked through a four-layer architecture for B2B teams looking to build a durable, scalable PLG model:
Layer 1 — Data Layer: A data warehouse that draws from all relevant sources: product usage, CRM, MAP, third-party enrichment. The goal isn’t a single source of truth — it’s a structured foundation that can support journey decisions. No amount of tooling above this layer compensates for a broken foundation.
Layer 2 — Data Orchestration: This layer ingests, transforms, throttles, and syncs data to the right systems at the right time. Throttling matters more than most teams realize — flooding Marketo or Salesforce with uncontrolled data volumes triggers API limits and processing backlogs, which breaks the journeys you’re trying to run.
Layer 3 — Decision Engine The model layer: predictive scoring, regression models, AI/ML-assisted propensity signals. This is what separates reactive campaigns from proactive journeys. Who is more likely to convert? Who is a churn risk? Who is ready for a sales conversation vs. a self-serve upgrade nudge? This layer decides.
Layer 4 — Action / Journey Layer Where Marketo, HubSpot, and other MAPs live. This is the execution layer — email, in-app, ads, sales triggers. This layer works best when it’s receiving clean, pre-qualified signals from the layers below it, rather than trying to make sense of raw product data on its own.
PLG metrics: What to track at each stage
A strong PLG playbook requires different metrics than a traditional funnel. Here’s a practical view:
| Stage | Key metrics |
|---|---|
| Acquisition | Sign-up volume, source attribution, activation rate |
| Activation | Time-to-first-value, onboarding completion rate |
| Engagement | Daily/weekly active users, feature adoption depth |
| Expansion | Free-to-paid conversion rate, seat expansion, upgrade velocity |
| Retention | Churn rate, NPS, reactivation rate |
| PQL Conversion | PQL-to-opportunity rate, sales-accepted PQL rate |
The mistake most ops teams make is tracking acquisition and activation well but having blind spots around expansion and PQL quality — which is exactly where PLG-to-enterprise revenue is won or lost.
Before you build anything: Run a cross-functional workshop
Both Josh and Ryan were emphatic on this point: do not skip the workshop.
Before standing up new tools, new journeys, or new PLG infrastructure, bring together every department that touches the customer lifecycle — product, growth, marketing ops, sales ops, CS, data — and map the entire journey from pre-signup to offboarding, including every handoff point, every swim lane, and every place where a customer might get confused or drop off.
“MarTech is almost always broken because the process hasn’t matched what the business asked for,” Josh said. “Not because the tool can’t do it.”
The workshop doesn’t need to be a month-long project. One or two focused days of cross-functional alignment can surface the disconnects that have been silently killing conversion — and give your team the shared understanding needed to build toward the right outcome, not just the fastest one.
Start with a proof-of-concept, not a full rollout
One of the most practical pieces of advice from the session: don’t try to orchestrate 10 journeys at once.
Josh’s recommendation is to identify one high-value journey — onboarding is often the right starting point — connect the data sources relevant to that journey, and run a proof of concept. Get one journey working cleanly before expanding. Teams that try to stand up everything simultaneously rarely finish anything, and they lose executive support in the process.
“Connect what you have and start there,” Josh said. “The best situations I’ve had are where we pick one journey, prove it out, and build from there.”
Ensure your data is structured, deduplicated, and ready to drive action
Openprise sits at the heart of that second “data orchestration” layer — aggregating signals from across your GTM stack, normalizing and enriching them, and routing the right data to the right systems without flooding your MAP or CRM. Whether you’re sending leads to Marketo, HubSpot, or Salesforce, Openprise ensures the data is structured, deduplicated, and ready to drive action.
For PLG specifically, that means:
- Identity resolution that correctly associates a free-trial user to an existing account — so you don’t accidentally trigger a clunky enterprise sales motion for someone just exploring the product
- AI-powered segmentation that goes beyond job title keywords to build accurate buyer personas and buying group roles
- No-code workflow automation for list loading, routing, scoring, and attribution — across multiple systems, without dependency on IT
- Throttling and data governance that keeps your MAP and CRM running cleanly, even as product usage data scales
As Ryan notes in the webinar, PLG rarely fails due to a lack of data. It fails because that data isn’t structured, connected, or delivered in a way that makes it actionable. Openprise is built to close that gap.
Watch the full PLG webinar on demand
The session goes deeper on the technical architecture, Marketo-specific considerations, and the specific ways PLG motions break when layered onto enterprise stacks. Watch the full recording to see the framework slides and Q&A.
How companies use Openprise to unlock PLG growth
- See how Vimeo built a composable MAP to unlock PLG and enterprise growth and cut speed-to-lead by 90% (30 min video)
- Check out our Mechanized PLG Funnel solution brief
Frequently Asked Questions
Q: What is a PLG motion in B2B SaaS?
A product-led growth (PLG) motion is a go-to-market strategy where the product drives user acquisition and expansion, rather than a traditional sales-led approach. Users typically start with a free or freemium version, experience value on their own, and convert or expand through self-service or a light sales touch. It’s common in B2B SaaS where the product is intuitive enough to sell itself.
Q: How do you define product qualified leads (PQLs)?
A product qualified lead is a user who has demonstrated buying intent through their in-product behavior — such as reaching a usage threshold, adopting high-value features, or expanding team usage within an account. PQLs are more predictive of revenue than MQLs because they’re based on actual product engagement, not just marketing touch activity. Defining them requires analyzing what behaviors your converted customers exhibited before they bought.
Q: Why do PLG strategies fail?
Most PLG failures aren’t product failures — they’re data and process failures. Common causes include: user event data not reaching the MAP or CRM, free users being treated as MQLs without behavioral scoring, lack of cross-functional alignment on the customer journey, and data flowing into systems in formats that can’t trigger journeys. The fix is usually a combination of better data orchestration and a cross-functional process workshop before new tools are added.
Q: What PLG metrics should marketing ops teams track?
Beyond top-of-funnel sign-up volume, high-impact PLG metrics include: activation rate, time-to-first-value, feature adoption depth, free-to-paid conversion rate, PQL-to-opportunity rate, and expansion revenue from existing free users. Most teams track acquisition well but lack visibility into the expansion and PQL conversion metrics that actually drive enterprise revenue.
Q: Do you need a CDP or data warehouse to run a PLG motion?
Not to get started. A proof-of-concept PLG journey can be built with existing tools by connecting your product database to your MAP using an orchestration layer. A full data warehouse and CDP become important as you scale journeys, run predictive models, and need to support multiple segments simultaneously. Start with one well-connected journey and build toward the full architecture over time.