Sr. Marketing Operations Manager, Lead and Global Demand Generation and Marketing Operations Leader at Atlassian
A PQL motion can be a hard sell for some sales teams. Sheila Head and Jonah Cooperman reveal how the sales team at Atlassian was so open to PQLs, what it takes to successfully launch a Product-Led Growth motion, lessons learned through the process, and whether it’s better to build or buy to create a tech stack to support PQL.
Sheila Head is the Sr. Marketing Operations Manager, Lead at Atlassian. Sheila came up from the customer lifecycle marketing team at Atlassian before overseeing a team of marketing operations managers as part of the global marketing ops umbrella. She has a traditional background in digital demand generation.
Jonah Cooperman is the Global Demand Generation and Marketing Operations Leader at Atlassian. Jonah runs a sub team, lifecycle marketing operations, under Global Operations. He’s a seasoned marketing leader with expertise in lead generation on the B2C side, B2B enterprise, demand generation marketing operations.
What does it take to successfully launch a PQL motion?
(Sheila) Some recent examples where we had some learnings that we're going to probably apply to the next couple iterations is having a team or business driver that is responsible for the strategy of what that PQL actually means. And then what the handoff and follow up strategy is going to look like, including simple things. Like what is the goal of handing off this PQL to the sales team?
What do we want them to do? Can we start putting some benchmark metrics to what that conversion rate is going to look like? Things like that might get lost in the shuffle, especially when you're starting to plan out PQLs, because it does take different systems and different alignment in order to launch a PQL, then say an MQL.
The reason is, you're likely going to have to work with your product team, your data engineering team, an analytics team, and get those teams talking to each other so that you have the data in a place that's easily consumable. You've got whatever mechanism is actually going to define that PQL set. Then you have a strategy from your product team, your product marketing team, and your growth marketing or your demand gen function need to align on the threshold that actually means that this is significant enough to pass off to sales and then follow that all the way through with sales enablement. Once you get these PQLs, what does that mean? What's the correct kind of customer experience or the lead experience from there? You need to have all those teams talking, which traditionally doesn't happen in an MQL model. Have all of that documented, because when you start solutioning for these things, it is really easy to get in the weeds and then forget what the whole point of the PQL is.
(Jonah) Like Sheila said, it’s very easy to overlook and sometimes even want to avoid, trying to bring all those groups together. It is not easy under any circumstances. Sometimes those circumstances can be challenging, but that's necessary.
I’ll add that the definition of a PQL is really important. You need to come up with that definition and go through the rigor in your mind to separate what's a product intent signal and what's a qualified lead. You can come up with a vast number of what those intent signals can be, but maybe not all of them should be an actual qualified lead that will be handed off. There's going to be some further follow up or significant event as a result of that.
The only other thing that I'll add there is that when going through that process, especially if there's a sales handoff, try to keep in mind the way in which that information is surfaced to sales, like the definitions and the data around it. If you happen to be a Salesforce shop and you're entering those into Salesforce campaigns, then it's gonna be a campaign member, that's that PQL. You need to think through that in such a way that's very specific so that the sales team can really understand what it is that they're looking at. It’s already a fairly opaque process.
Thinking in terms of what an MQL is, why do some things MQL? What's the data point that's helping a sales team understand why a person's been passed over and know exactly what to do to follow up. That's challenging enough, but it's actually even more challenging when it comes from a product signal, because it's just one more layer removed from what it is that the sales team member is experiencing and looking at day to day about the person. They're normally not looking at that type of data. They're looking at other types of data. They're more thinking about a person's fit within an organization. Finding ways to make it really clear what the expected follow up should be and how to decipher what that PQL is, and then tagging those campaigns and those campaign members with names and descriptions and other data points is really important. It’s something that we're still very much in the process of figuring out how to do.
What would you do differently if you were to launch a PQL motion again?
(Sheila) We had a challenge recently where there was a defined threshold for a PQL and we weren’t aware of how many PQLs that signal was going to generate. We ended up doing all of this work and generating something that worked with our sales handoff strategy in Salesforce, but we didn't predict how many qualified leads that would actually create. We ended up overburdening the team, and it was a small team. It was a team that was just testing out this functionality. That’s something that you can easily kind of predict, especially if you're working really closely with your analytics partners.
That is one thing I would do a little differently. If you overload your team then motion doesn't have a fair chance because the team members are just spread too thin. If you get buy-in from your sales leadership or your SDR function to understand what their capacity is, then you can try and marry that with the threshold that you're seeking with your product and your product marketing team. That’s something that you should do upfront rather than after the fact. Otherwise it ends up being tricky to prioritize amongst all of those leads.
(Jonah) I would've preferred that we conducted a test with a single product, paused afterwards, done a standard Atlassian-style blameless retro, and then taken some of those learnings and incorporated those into some of the other products that are generating those PQLs.
One of the challenges that we have is that the product infrastructure itself is different depending on which product line that we're talking about. Many of the teams started requesting PQL-like functionality. Sometimes it was something close to it, sometimes it was a PQL itself. A lot of those efforts spun up in parallel. Some of the learnings that we then had to derive were sort of all happening at the same time. I would've preferred to have really conducted a much more limited test, and then built some sort of process and template for it, and then tried to roll it out one by one.
In our case there's a lot of excitement around the idea of a PQL and as one team heard about it, then other teams wanted it and now it's it's the next hottest thing.
How did you drive sales adoption of the product-led motion?
(Jonah) We've had some advantages. So much of our sales team is trained on following up and further upselling, cross-selling, and deepening relationships with existing customers that the idea of having a conversation around an existing customer’s product usage and experience was already familiar. Even though we didn’t have a PQL, we were working with so many customers who had reached a certain stage of their existing product journey that we took to another stage in that journey. There was actually quite a bit of momentum and learnings built into the sales organization already from that. The learning around that enablement has more about how we get the volume for people coming in, which Sheila alluded to.
The other element for us has been more around exactly how we're going to derive stories and journeys that the sales team can then speak to in such a way that one is a compelling sales message and speaks to the need that the customers are having. Then we have to train them to look across a couple of different data points. Ideally we would supply those data points to make that a little bit easier. It’s been a challenge where we’ve had to show when the customer is a good fit by looking at the following campaign data, with certain fields in one place but also looking at another internal system that shows some of their usage. That’s more of an issue where there needs to be more work done on the marketing ops and sales op side to curate a real sales console that combines all that information. However, getting sales teams to look across different systems and think about customer data holistically has been fairly challenging.
Even when we've found ways to get the information directly into Salesforce, through a visual force page, it's still actually tough to get that page curated in such a way that it's coherent and clear and makes it feel like it's worth prospecting, even within Salesforce.
(Sheila) I agree with Jonah. We might not have had the same challenges that others are facing with convincing sales of this new type of lead, mostly just because our reps have welcomed it because it made their job slightly easier when we did a little pre-vetting of product signals for them. It helped that we presented it to them in a way they were used to, like a kind of MQL motion. Something that really helped in our case is that the PQLs and the PQL definition for whatever product motion we went after was really vetted quite extensively with our product analytics and our marketing analytics team. They came up with those signals because they looked at other customers who completed whatever motion we were going after and figured out what they did in the product or what kind of intent was showing and coming up with a definition in that way.
That alone convinced the sales team that we're using actual usage and user data to find people that have done the same things before providing the data in a familiar way. When we worked with sales ops and sales enablement, we needed to have that automated piece where a sequence in Outreach was automatically being triggered if the PQL was met. Taking care of things like that meant they weren’t trying to cold call. We just gave them more targeted content based on behavior and then provided a way for them to raise their hand and talk to somebody when they needed to.
What to consider when building or buying your MarTech?
(Jonah) Obviously you have to be in a position where build is even an option. At Atlassian, we’re more on the opposite end of the spectrum, where the question is whether buying is even an option. For the sake of the audience, I’m going to presume your organization is at some sort of point where there's a choice. Maybe you're seeing that you're getting towards that point really soon because you're bringing on more engineering resources and IT resources into your stack and into your sphere.
On the build side, it’s quite difficult to realistically come up with an estimate in which building is going to be faster and more efficient than buying, even when it's necessary. That being said, despite the fact that it may be more complex and more time consuming, going the build route is when the nature of your data itself is becoming a blocker for any kind of buy options. What that actually means is that you're going to have a data model.
The data model is going to be based on the way in which your database is structured. The database is going to be structured based on the way in which your product consumes initial data from customers and then structures it in such a way that it's propagated throughout the business. Once you get to a certain point, both the volume and the complexity of that model is then going to actually become a constraint for any kind of technology that you're going to buy. That's one thing.
The other thing is related, but you're going to find yourself thinking a lot about the types of transformations you need to do to your internal data in order to make them usable to any kind of third party system. There's a lot of options out there. There are a lot of great vendors that are doing really cool things that let you do ETLs with little or minimal data engineering in order to get that data in the place where you want it to be. You’ll start to get to a point where you're spending more time and effort just wrangling the data to make it fit the data models the way that those consuming systems need to see them. That limits your thinking in what you can actually do with it.
Finally, you need to have a deep, honest conversation about what your core competence currently is and what you want your core competencies to be in the future. That’s the most interesting and difficult conversation to have. Think about what does your organization really want to be really good at producing yourselves and where you’re going to martial your resources? What should those things be? Very few companies are going to be able to answer unless you're in this business directly.
For example, if you want to have a real core competence around building a CRM, that's not likely to be an answer. Most people are still going to turn to something like Salesforce as their enterprise CRM solution. Having a marketing and product analytics model or data pipeline(s) that extract data and can do things with them that helps come up with a PLG model is an area where you may actually want to have a core competence. It's more important for you to have that as a core competency as you understand more about what your customers are doing. Thinking in that long term way is going to help you figure out which things you should still consider to be a build, which should be considered a buy, and where you feel like your core sort of engineering practice is ultimately leading.
(Sheila) I definitely agree with everything Jonah said. He's a lot closer to those decisions that were and are still being made on our team. One way to satisfy those within the company who want to pursue building it is to invest solutions in our tech stack that are customizable or extensible to our first party data, which is super important to us. We definitely look for tools that are not all or nothing, but something where we could take a couple of features and then layer on our own or some other point solutions that we've either built ourselves or already invested in. That's sort of how we get around those conversations if they're really preventing us from moving forward with an initiative. We've got quite a healthy mix of homegrown things mixed in with third party vendors. It's probably gonna be like that for as long as Jonah and I are here.
(Jonah) If you're gonna consider a third party option, it should have at least a medium term outlook, if not more, because the effort that has to go into really making that a success. It can become a whole lot of sunk-cost very quickly. If you're going to then pivot off that, that's a lot of time and effort you probably would've spent doing something different.
It's good to think at least four to five years down the road of whether a vendor or solution is going to be a really good fit for what it is that you're trying to do. Sometimes it's very difficult to actually predict where that’s going to go. In terms of should this turn into something that we are going to build ultimately? it comes back to more of the constraints around it, rather than asking, is this something that we should build?
Ultimately, I think the question is more is our internal data structure and our process going to be such that that is going to transform and grow so radically that there will be no other way to work with it other than to work with it our ourselves? if you find something that's a really good fit, it's so much better to apply all your energy towards then taking in other projects or working with that data rather than to think through how can we replicate all this internally?
I'd rather just use the third party stack in that case and put my attention on other things.
