Playbook
GTM Playbooks
How GitGuardian Leverages Data and GitHub to Fuel Its Growth
Read more
.png)
We are excited to publish our first piece in a new content series focused on “Product Led Growth” Playbooks, an emerging field that pushes the boundaries of conventional sales, marketing, and customer success. In this series, we’ll be sharing insights and advice from practitioners who have built successful PLG businesses and offer specific playbooks for founders running high-growth software startups today.
Software engineers traditionally do not like sales people - so how do you build an organization that sells software to developers? We asked Casey Clegg, my colleague from Twilio and now COO at PubNub, to demystify the process for building a sales organization that targets highly technical buyers. Casey shares his learnings on how to serve distinct stakeholders (e.g. developers and business personas), and how to create a "Technical Sales Development" playbook:
When selling an API to a Product & Development team, people get tripped up: they know there’s more than one buyer persona, yet they tend to focus too much on one motion. You should not sell to a developer as you sell to a business persona. Different personas require different content but also different motions.
Developers prioritize getting their hands on and building with your product. They want to be able to get it up and running in a fully self-serve experience, with the confidence that you’ll have quality documentation and a vibrant community of developers to back them up if they get stuck. They also want pricing transparency. Playing with the product and prototyping should be affordable and predictable.
Developers have a tremendous influence on the process and can block a whole Sales initiative if they feel that something’s not up to their quality level. Conversely, they can become advocates for your product if it rises to that level.
A more business-oriented, non-technical persona might respond well to a traditional content and sales cycle. They want to know how your product can get them closer to their organization's goals. When assessing your company, they’ll look for a clear tie to ROI as well as their own internal KPIs.
Let’s say you’re offering an API product with a self-serve model. After developers sign-up, you can be sure that they do NOT want Sales to call them.
Instead of grading a sales motion by the number of times you tried to contact a developer lead, place more value on how you pushed that developer closer to production. That’s best done by reaching out to offer technical help and guidance, starting with a simple question: “what are you trying to build? I’m here to help”.
“What a developer values most is getting closer to completing what (s)he’s trying to build. ”
Casey created a technical BDR team that supports the right new sign-ups at scale pro-actively. It is different from Customer Support, which is reactive.
He staffed his teams with avid learners with a service mindset. Casey doesn’t think every BDR or SDR selling APIs needs a computer science degree. But, solid knowledge of foundational concepts like how the internet works, how databases function, the difference between frontend programming and backend programming, how API calls work, and more can go a long way.
Technical SDRs and BDRs can speak a developer’s programming language, provide them with contextually relevant resources like quickstarts and links to specific docs, and be more helpful to a developer than a non-technical SDR or BDR, solely focused on doing a qualification call, could.
When a prospect contacts your Sales team or signs up to your service, they likely have a particular problem they’re trying to solve or a particular area of their business they want to improve using your product.
The best thing you can do to convert those inbound leads is to equip them with the relevant information about the problem they are trying to solve. Very often that means that they need information about the use case they are trying to build. Let’s say you’re a security solutions company and an events marketing agency needs to verify hundreds of user’s identities as they register. It’d be best to have a blog post or tutorial at the ready detailing the best practices for user authentication whether that’s 2FA, OTP, or TOTP. Chances are that the developer may have missed it, so the BDR should surface that guidance.
For your outbound motion, the key is to get your prospect’s attention. Casey’s teams at Twilio and PubNub have found success by offering guidance, best practices, benchmarks, or case studies specific to that prospect’s vertical. Get your Product Marketing and or Customer Marketing teams to develop content and best practices for your top verticals and create outbound sequences featuring that content.
Casey has seen first-hand how Technical Sales Development Associates climb the ranks in organizations. And not just in Sales. He has seen some of them become leaders in Product Marketing, Growth Marketing, Operations, and even Finance. Obviously, their training arms them well to be your future Account Executives, Account Managers, Customer Success Managers, and Sales Leaders.
Why? Being on the frontlines of your business and constantly in contact with your customers gives them invaluable insight into how to serve customers.
They learn how customers use the product, as a result, they understand what customers care about, need, and don't need. They develop deep empathy, they learn how to use your products and how to problem solve, based on problems that customers actually face. That’s one of the best leadership schools for your business.
Your Sales team’s time is precious. If your developer content, community and paid channels work well together, you should have many more daily sign-ups than your BDRs can handle.
You need to separate the casual from the serious, use the right processes, provide value with every conversation, and have clear guidelines about next steps. And, of course, you need to track the right KPIs in order to iterate successfully.
Which developers are doing more than casually sign-up? Which ones are likely to have a tangible use case and convert into paying customers? Who will need more than a self-serve experience?
You need to provide paths in your onboarding flow so developers can dive further. You should instrument and track their behavior in the product portal to determine how successful they are.
Here are the signals that you should look out for to turn a sign-up into a Product Qualified Lead (PQL). Once you see a combo of these signals, have a Technical BDR follow-up.
Beyond these behavioral signals, you can apply firmographics to augment the signup emails with tools such as Clearbit or DemandBase. Make sure you identify which signups come from your target accounts. Pay special attention to whether multiple people from the same company are signing up.
Then, tie together the info from the product and admin portal into a marketing source like Salesforce, Hubspot, Marketo, or a DWH. Track user behavior, usage, and spend.
Make sure you define and set up clear routing rules for your BDRs. Then, define precisely how BDRs should handle and qualify a PQL from product sign-ups and MQLs, demo requests or non-product scored leads. Define an SLA to determine how long a BDR should take to reach out to the prospect. Hand raisers should be their first priority. Then, track metrics around this statistic, especially the misses. Provide and review weekly dashboards at the BDR and team level to dig in on what’s working and not working.
You need to provide value to win over developers. Hard-charging tactics won’t work.
Developers are trying to solve a specific problem and/or buy a specific use case with your API. So try and understand what that is, and find out how to help them with that specific use-case.
“Remember: You are not selling the product. You are selling the value of the next discussion with your team.”
You should be trying to get information about what that developer is building, why they’re building it, and when they’ll complete it. That’s in return for valuable information from you and your AE or SE.
Your qualification questions and criteria should be consistent across your funnels, both inbound and outbound. That way your AE has the right information across all Sales Qualified Leads, meaning the PQLs and MQLs that BDRs and SDRs have handled. That’s regardless of if they came from a sign-up, a demo request, or referral. These consistent criteria will help you analyze, compare, and discover what’s happening in your funnels.
Be clear with your BDRs about what should happen when a PQL is not qualified. You need a playbook around what happens when a BDR disqualifies a lead. If you ignore a lead too abruptly, you risk creating a bad experience that could damage your reputation. But, continue a conversation with a lead without potential for too long and you end up burning critical time.
Define and document the right path for a lead you disqualify and point them to your support team and your docs. You need to make this process incredibly clear to your BDRs.
You will likely measure and compensate your BDR team based on the total number of opportunities they identify and nurture with AEs, as you should. Casey strongly recommends that you also track conversions rates by source — from sign-ups, from demo requests, and other sources. Use time-to-contact as a key performance indicator of a BDR’s activity as well.
Casey has different conversion rate expectations by source. For example, a Request Demo / Contact Sales form should convert at a much higher clip than other channels. Comparing that form’s performance against a PQL does not make sense. You need to optimize each funnel while recognizing their differences.
“The biggest question with BDRs is: where and how do you use your time?”
The time-to-contact target also depends on the source. BDRs need to hit SLAs that you define. So, you might set a clock for a four-hour response time after someone reaches out to sales via the Contact Us form.
Casey almost never looks at averages but still finds the outliers, the misses especially insightful. By examining what percentage of time someone operated outside of the SLA, you can understand what areas you need to improve.
.png)
