Alexa, CEO of Pocus, hosts PLS AMAs with product-led sales experts to share best practices, frameworks, and insights on this emerging category. These AMAs are an opportunity to ask PLS leaders any question - ranging from hiring to sales compensation to tech stack - in a low-key, casual environment.
The PLS AMAs are for members of the product-led sales community, the go-to-place to learn, discuss, and connect with GTM leaders at product-led companies. The goal of the community is to bring together the most thoughtful and innovative GTM leaders to build the next generation of sales together.
Interested in joining? Request an invite here.
This week’s PLS AMA was with Giancarlo 'GC’ Lionetti and the discussion was jam-packed with golden nuggets of wisdom.
GC has worn many GTM hats across organizations like Atlassian, Dropbox and Confluent. Product-led, human-led, hybrid GTM have been part of his experiences - from product marketing (Atlassian) to running a $1B high-velocity business (Dropbox) to being a “kinda” CMO running Marketing and Business Operations (Confluent).
In this discussion with GC, we cover:
Our product-led sales community got a chance to ask GC about building product-led sales team and more. Here are some of the questions and primary takeaways from that conversation.
When a community member first asked this question, GC smiled and said “I’m smiling because it was tough… I made it up along the way”. Given GC built some of the first product-led sales organizations from scratch, he truly needed to innovate and find inspiration from non-traditional sources.
The first place he looked for help might surprise you.
He studied the business models of consumer companies - think Spotify. GC mentioned that Spotify was the only company he could find that had a “conversion team” that was responsible for monetizing their free users. He studied how they incentivized the team and how the org structure worked.
GC also credits Atlassian for a lot of his product-led sales knowledge in terms of setting up efficient organizational design and using human intervention as a learning element (i.e. creating feedback loops). Zendesk also did it very well in the early days as they had a velocity sales motion and added humans early in the process.
But, GC adds (and talks about this a bunch throughout the AMA), that everything needs to be experimented and figured out along the way.
“If someone has figured out a product-led sales motion, I kind of think that it is unique to that specific business -- I couldn’t plug and play everything from business X to business Y -- it won’t work”.
You need an experimental mindset to test out new things to see what works for your specific business and product.
At Dropbox, there was the scenario where a lot of users would be on the free version and ultimately a salesperson would target a senior buyer in IT to sell the paid version -- this was a pretty straightforward sale.
GC calls this “outbound inbound”, where a product-led sales team needs to do some outbound to accounts that already have users that have signed up via inbound channels. It’s really important to connect the dots between these two.
In his opinion, MongoDB does this really well. Many developers will use MongoDB for free and then they will initiate an outbound campaign based on where the penetration happened. Confluent did the same thing. This motion requires you to be very data-driven and thoughtful in your outreach. As GC put it, “you can’t hit up every one or it will dilute the value of the product.”
GC admits that he did not put too much thought into the name early on (but it definitely stuck!). There are many names for this role, including self-serve assist, sales assist, advocates, onboarding specialists, inbound sales, and SDRs. Regardless of the name, they all have largely the same scope. He mentions that “sales-assist” and “advocates” have resonated the most with customers.
The sales-assist role was born out of the early days of Dropbox when they had an inbound sales motion and an outbound motion, but no one to serve the vast chasm in between. GC was told to “figure it out” this unhappy middle ground.
So, he outlined 4 components of the sales-assist team:
"If you can bottle up these insights and share it across relevant teams, it can become the secret sauce to your business."
A great example of driving revenue from a sales-assist team is from Dropbox. The team received feedback from customers that the users were dropping off because of the “what is your team name” question before starting the free trial. The users were afraid that if they added their team name, they would be connected with someone else in the company, which they did not want to happen during the trial experience.
So, the sales-assist team funneled this feedback to the business and Dropbox decided to move the “what is your team name” question from the trial form to a question in the onboarding flow for paid enterprise customers. They were able to capture the same data on the customer and reduce significant drop-offs, leading to millions of dollars in new ARR.
Back when GC was at Dropbox, the sales-assist team lived on the growth team. The growth & monetization team owned the self-serve revenue number.
The sales-assist team is measured based on 3 components:
There is an 80/20 rule for compensating sales-assist teams: 80% base salary + 20% “ a thank you bonus” if the rep offered customers a great experience.
GC mentioned that his team was very thoughtful about the incentives and structure of how they were paying the self-serve assist team. For example, he did not want to compensate solely based on quota, because then the self-serve assist teams would try to aggressively sell, rather than help the users. Incentives must be aligned with compensation.
GC experimented with a ton of profiles for the sales-assist role, ranging from sales to customer success to operations to generalists. Sometimes the sales-assist persona looked like sales, other times customer success, sometimes program management. It really depended on the product and company.
At Confluent, the sales-assist team was part of SDRs because they resembled salespeople. The product was so complex that they needed a human to get in and do some hand-holding early. GC looked for people with technical sales/customer success backgrounds. Whereas at Dropbox, he looked for program management/operational backgrounds to manage the outsourced sales-assist team.
It’s important that each company experiments with different types of sales-assist backgrounds.
The school of thought for many is that junior folks can start in an SDR / sales-assist role and then graduate to sales. This is limited thinking in GC’s opinion. There are many different career paths for sales-assist - folks can go into solutions engineering, marketing, sales, customer success, etc. Many people that GC has managed have gone on to roles in sales, whereas many have gone into other fields like product or marketing
Short answer: not pushing, guiding.
Sales-assist is always about using data to figure out the optimal experience for the customer. Sales-assist teams should never be pushing to sales, instead, they should identify the right flow that could ultimately end up in sales.
Sales-assist team should understand who the right accounts are to send to sales and ask the right 5-7 questions to qualify before sending to sales. The team should figure out the best interaction and experience for the customers and intelligently route leads to the right teams.
Thanks GC for all the amazing insights and to our community for asking great questions! Our community would not be the same without experts like you and the awesome folks who join the AMAs to ask questions and learn.
Join us for more upcoming AMAs with Marie Gassée (Former VP Growth @ Confluent) on November 2nd at 11 am PST/2 pm EST and James Underhill (Sales Strategy & Operations @ MongoDB) on November 10 at 10 am PST/1 pm EST.
Want to join the next AMA with a PLG sales leader? Request to join our community.