The emergence of Product Qualified Leads (PQLs) offers B2B freemium teams an arresting possibility: “Selling the product to folks who understand the offering and are potentially already happy,” as HubSpot’s Chris O’Donnell writes.
Whether the sale takes place through an automated, in-app experience or with a salesperson, the idea is that a PQL is qualified by better markers than MQLs, and therefore more likely to convert.
They can be more than a conversion tool, Wes Bush argues.
“PQLs align teams to focus on helping users become successful in the product...if you embrace the PQL model, you'll have more successful users and more upgrades as a result.”
Conversion tool or retention lever, the key question with PQLs is: Are they a safe proxy for a user’s progress?
Which, with a little unpacking, becomes: How do in-app conversions and user abilities work together? And what happens when we prioritize, or worse, conflate, one with the other?
In this post, our hope is to answer these questions and illustrate a hard truth: PQLs, as they’re defined today, overlook or neglect crucial user contexts, mindsets, and motivations. And, as a result, fail as both a conversion tool and a retention lever.
The key to PQLs is behaviour
The argument to replace MQLs with PQLs is compelling: Users that understand the product, use it, and are (potentially) happy with it will eventually bump into functional feature limits/locks and signal their qualification. Someone who has taken steps to start using the product is more likely to convert than someone who has merely downloaded an ebook.
"How qualified is someone just because they filled out a form or opened a few emails?” Stan Massueras asks. “MQLs and SQLs are remnants of the early days of SaaS when the needs of the customer took a backseat to the internal priorities and processes of the company."
But consider PQLs alone—without MQLs to compare against—and Stan’s objections to qualifying people based on perfunctory behavior don’t disappear. How qualified is someone just because they signed in four times in a row or bumped into a data limit?
The key to identifying a PQL, Wes Bush writes, “is to find behaviours that correlate with people upgrading. For Slack, a PQL is when an account reaches its 10,000 message limit; for Facebook, it’s when someone adds 7 friends; for Drift—once someone has 100 conversations on their website.”
But is it possible for a user to display all the appropriate usage behaviour without actually gaining new abilities or skills? If someone hits Drift’s limit of 100 conversations on the website, is it a given that they’re skilled enough to start using an advanced feature?
The problem at play here is that activity doesn’t always mean progress.
Progress is bigger than a usage metric. “Progress is the process of making changes in a positive direction,” Alan Klement, one of the foremost thinkers of the Jobs To Be Done movement, writes. It is new abilities make those changes possible.
The difference between ability and behaviour
The key to PQLs is working backward from user behaviour, and that’s precisely their failing—they ignore everything you have to do besides using the product to make progress.
The problem in a nutshell: PQLs track users who eat the flower. But you don’t need to know who ate the flower. You need to know if it worked. You need to know which of your users are now able to throw fireballs.
There’s a difference between someone knowing a skill and someone simply displaying a behavior.
Dr. Tom Tomkin, Senior Principal at Cornerstone OnDemand, illustrates: “I had an actor friend who needed to learn the guitar for a play. Someone taught him the mechanics for the particular song [he needed to play]. They showed him where to place his fingers and how to strum. He picked up the behavior quickly and did a marvelous job. Yet, if he had needed to play another song, in a different key, with different lyrics, or even the same song in a different key, he certainly would not have been able to do so.”
“To distinguish between somebody knowing a skill versus just displaying the behavior,” Tomkin says, “simply change the context. The skills will be transferable, the behavior will not.”
By focusing on behaviour alone, PQLs can’t tell product teams what skills users are developing and can bring to new features. Most PQLs trigger a CTA for more activity rather than meaningful activity.
PQLs might be a step up from MQLs and SQLs but they’re a long way from ideal indicators that a user is finding success. As long as product activity is prioritized over progress, customers will always take a backseat to the “internal priorities and processes of the company.”
Two holes in the PQL logic
PQLs take in-app behaviour as a qualifier for a user’s potential success with a new feature set. But the difference between a key behaviour and real skill reveals two big problems with this approach:
1. Behavior is not a proxy for ability
It’s possible to go through the motions with a feature, especially if an app is intuitive or directs your behavior, without understanding the ‘why’ of it all.
Mailchimp
Two months into using Mailchimp we bumped into the 2000-subscriber-only email limit. We didn’t hit that milestone because we were making the most of Mailchimp as an email marketing tool. We hit it because of a modestly viral post and the number of emails we had to send out tripled overnight.
From Mailchimp’s perspective, we qualified as ideal users for their advanced insights and optimization features. But they were pitching us reports that we didn’t know how to read.
Is it fair to infer that we were bringing better skills to the 2000th email than we did to the first 100 or 500?
2. Past benefits don’t imply future ones
A customer’s good understanding of current features doesn’t imply success with new ones. It’s possible for a user to find success with an app’s core features and still fail with secondary ones because she hasn’t built the right abilities as yet.
Webflow
We used Webflow to launch the first version of the Airbase website. We hit a paywall quickly but couldn’t choose an effective plan without help. Using Webflow’s hosting services didn’t prepare us for the unrelated developer API and CMS options, and the complicated Editor/Developer user roles.
We were logging in every day to monitor and work on our site, but we didn’t have the readiness to expand our use to an unfamiliar set of features. Our internal workflow, even our team structure, needed to be a little different to make use of those new features. There were too many unknowns. PQLs, based on past behavior, wouldn’t have been able to fill Webflow in on what we needed to create added value.
WaveApps
If you sign up for WaveApps to make an invoice, you’ll learn how in a matter of minutes. Their invoice-based onboarding takes you through the process from piece of paper to tax-inclusive invoice in four simple steps. Onboarding ends with a simple question: Now that you can send invoices, are you ready to customize checkout pages? Or set up transactional emails and payment methods?
The problem is that to set up critical invoice-adjacent pieces, users need to understand how they’re connected to the invoices. You need to know how invoicing all your customers on the same day every month affects credit card declines to write an effective dunning schedule. Going through the motions of creating an invoice doesn’t tell you why an effective invoice works better.
Teardown: Hubspot’s PQLs
Hubspot is a PQL pioneer, and uses three kinds of PQLs to qualify users:
- Usage PQLs: Users who trigger a call to action based on product usage.
- Upgrade PQLs: Users who run into a locked feature.
- Hand Raise PQLs: Users who request assistance when they’re stuck using a high-conversion feature.
Hubspot users are redirected to a modal when they trigger a PQL
A good way to illustrate our point, we thought, would be to take a look at Hubspot’s PQL logic and see if it holds up in light of the skill/behavior distinction.
It doesn’t.
You can see fault lines appear in all three kinds, indicating that these PQLs must fail a certain number of users:
Usage PQLs conflate behavior and ability. A user exhausting her 10 free out-of-the-box marketing reports is too weak an indicator that she’s able to switch to a paid plan and start customising her own.
Upgrade and Handraise PQLs assume past success guarantees future success. Can Hubspot safely assume that using the chatbot qualifies users to take full advantage of the content suite?
The current PQL shares too much in common with the MQL in approach—“product activity” as a qualification for a sales call is too close to website activity.
Ability is the key to retention
Activity, by itself, doesn’t tell you everything you need to know to make users awesome. You need to know more than the fact that a user tried a feature. Which feature? Did using it help? And what specifically should they be doing next?
Without answers to these questions, the most you’ll be able to do is give users who are figuring the product out for themselves Upgrade buttons. When, instead, you should be offering them a clear path to the next goal.
Image credit: Progress: The Core Of JTBD by Alan Klement
Without a clear path, this happens:
If users don’t grow in ability over time, they eventually churn out.
As Kathy Sierra says in her book, Badass: Making Users Awesome: “If [users are] no longer moving up and to the right, they aren’t increasing resolution, gaining new skills, or becoming more powerful. Their enthusiasm for their new abilities and results will slowly fade.”
What’s at stake
The consequences of conflating behavior with ability are obvious. And they aren’t just a PQL thing. With no grounding in a user’s context, both upgrades and upsells, become ineffective CTAs for adoption.
Some users run through the motions but only the most self-motivated succeed. For everyone else, each product update attains a ‘spray and pray’ makeup, the product’s promise becomes a lofty marketing statement; the product itself, a commodity. Aside from operational and data-housing concerns, what reasons, after all, do users have to stick around?
If HubSpot promises a platform for launching “effective marketing campaigns that make people interested in your business and happy to be your customer,” how can they ever deliver without accounting for bettering abilities?
“When we create software,” Samuel Hulick wrote, “we’re not creating a tool, we’re creating an environment for accomplishment.”
PQLs, at least the way they’re structured today, help perpetuate the opposite.
Do you agree?