In the evolving landscape of PLG SaaS, everyone knows that marketing and selling to developers has its own set of nuances. At HyperGrowth, we’ve talked about this already in our post on the developer marketing funnel. While convincing a developer to sign up for a free or self-serve plan can already be challenging, the work to get them to upgrade to an enterprise plan is a whole different ballgame.
So when reaching out to developers to upgrade their trials, traditional SDR roles often won’t cut it because people in these roles aren’t trained to understand and cater to the unique technical needs of developers. For example, unlike marketers who might sign up for annual 5- or 6-figure contracts like Marketo or Braze without extensive product validation, developers seek clarity and specificity on the SaaS they purchase — and to fulfill that, they often demand specific technical answers to be answered before committing to an initial sales discovery call.
SDRs, who optimize to close deals and achieve their quotas, often miss the mark in addressing these technical queries, not just because their incentives are not aligned with providing in-depth (or even surface-level) product knowledge, but also because they genuinely don’t know how to answer them.
Ultimately, this approach alienates developers, pushing them towards your competitors or wasting resources building their solutions.
The crux of the issue lies in understanding when and how to engage with developers, structuring an effective enterprise sales organization for technical products, and identifying the right talent for this unique challenge. So how do you do it?
The short answer? Your first point of contact should be a Product Advocate, a new type of technical SDR. Stick around for more insights on the other questions.
Product Advocates: The Cornerstone of Your Technical Sales Team
Product Advocates (PAs) are entry-level “technical” roles that deeply understand your product and the people who use it. This training enables them to know the product like the palm of their hands, giving them the building blocks to effectively communicate with a technical audience like developers in the language they understand.
Their goal is to provide answers, resolve issues, unblock developers, and guide them toward your product’s aha moment — naturally building rapport throughout the process. And only after adding value do they bridge the connection to the sales team. This approach differs starkly from traditional sales methods which — instead of “scoring the lead” — focus on delivering valuable knowledge and building trust.
Not only that, but Product Advocates are also much more cost-effective talents compared to solution engineers, solution architects, and even traditional sales roles. Both PAs and SDRs are entry-level roles, but when looking at the full SDR quota and required training, PAs become much more cost-effective, on top of being a better first touchpoint for your prospects.
To recap, key characteristics of effective Product Advocates include:
A technical degree in CS or a coding boot camp
In-depth product training from the outset, with much of it happening in-house
Ability to confidently communicate in the technical language of the audience, and vet the prospect for BANT parameters
Providing valuable suggestions and call-to-actions during customer interactions
Fostering trustworthy relationships rather than immediately scoring leads
More cost-effective than solution engineers or architects
For the record, Product Advocates was just our preferred name when we created the program at Vercel. At companies before we’ve called the more technical SDRs “Evaluation Support Agents”. What matters is that you intentionally do not brand them as traditional sales roles like SDR or AE, but you actively align them with a language that is more palatable for developers.
Need help restructuring your sales organization to scale your devtool enterprise deal flow? Our HyperGrowth Partners can help.
Engaging Developers: The Time and Place of Product Advocates
Ok, you’ve hired and trained your PA. Now, when should they reach out to developers?
As mentioned before, the first touch is delicate — developers don’t like to be talking to people unless they need to. So your PAs should plan their first outreach in a way that adds value and is as less invasive as possible.
Intent signals. PAs should reach out only when clear “help request” from a prospect. This doesn’t have to be explicit but can be based on clear intent signals such as:
They clicked on a section on the dashboard, explored other sections of the product, and then came back to the dashboard — signaling they were somehow going in circles.
They click on the dashboard, read some technical docs, and then go back to the dashboard without performing a significant product action.
The signals can also be combined with other properties like being already active on a self-serve plan or having submitted one or more technical queries on topics like pricing, security, or plans. Replies to these intent signals are typically automated, so the PA doesn't have to do anything. However, these signals constitute those conversation starters after which they typically jump in.
In-product interactions. PA interactions with developers should occur where they spend most of their time: right in your product. This could be through email for 'set-and-forget' products (eg. Segment) or via the dedicated in-app chat for more recurring use cases (eg. Vercel).
Automating the outreach involves the following steps:
Clarify and actively track all potential intent signals.
Automate, targeted first-touch communications based on the signals.
Notify PAs that developers have initiated the interaction.
Offer developers the ability to naturally route their conversation to a PA (specify they’ll be talking to a PA vs. “Talk to Sales”).
Provide exhaustive answers and suggest valuable in-product actions that are tailored to the developer’s use case and situation. Avoid cookie-cutter FAQ-type answers that can be found in the technical docs.
Remember to avoid basic BANT qualification questions or collecting company-related information throughout this first interaction. Product Advocates must add value here — see how we did it at Vercel:
Hiring, Training, and Career Progression for Product Advocates
Great, you’re sold on the Product Advocate role and are now keen to hire one for your developer tool SaaS.
Because PAs are not your typical sales role, they can be sourced from a wider array of backgrounds. In our experience, the best Product Advocates are entry-level technical talent that can be found in places like:
Coding boot camps like Bloomtech, CodeCademy, LeWagon, etc.
Once you onboard your PAs, there are several pathways you can progress them on, based on their background and ambitions. At HyperGrowth Partners, we’ve placed PAs in:
Customer Success. If their core skillset remain helping developers become more successful with your product, it’s a no-brainer to promote your Product Advocates as CSMs, so they can nurture their passion for enabling your customers to build better product and be more successful in their careers.
Junior Engineering roles. When their technical acumen is beyond just affinity, PAs can easily join the engineering organization and start building the product for the customers they’ve supported to PAte.
Product Marketing. Because of their deep product and customer knowledge, your PAs are very well positioned to join the product marketing team, helping with product positioning, but also actively bringing customer feedback to the product team and contributing to creating technical docs, content, and events.
Struggling to find and hire the right talent for your Product Advocates?
Closing Thoughts
The challenge of selling dev tools in a PLG SaaS model requires a complete re-evaluation of traditional sales roles.
The introduction of Product Advocates — helpful experts who speak the language of developers and focus on adding value before making a sale — is a critical investment to bridge the gap between building rapport with your developer audience, collecting intent signals not and technical requirements, and scaling your enterprise sales conversion rate.
By understanding the unique needs of developers and tailoring your sales approach accordingly, you can transform the way you sell your technical products and foster sustainable enterprise growth for your developer SaaS.
Interesting! Very similar to Atlassian 🤔