How does sales enablement change when your company is b2d (business to developer) vs traditional enterprise?
Selling to developers can be difficult, often because they have a ton of say over the decision but not explicitly the budget, but marketing to developers is simpler than people think. Quickly and concretely explain what your product does and how it works/fits in with other stacks (as much as developers love to claim that they're immune to marketing/branding - just look at the stickers on their laptops. C'mon - that's brand loyalty/affinity on par with pre-teen pop music fans) then get them into some demo/free trial/"doing the thing with your product" as quickly as possible with resources (docs, tooling, code samples) they can self-service on and then get out of their way (and watch). If your product can't convince them of it's awesomeness through hands-on experience you have a tough road ahead of you. But if it's got the goods, and you have visibility via a modern SaaS offering so you know who's doing what, then sales enablement becomes all about:
- Reading the signals from inside the product of who's getting value and ripe for value capture becuase your product has already created value for them - developer marketing / advocacy gets them into the trials/usage - not tradtional SDRs/AEs generally. Devs don't want to talk to those folks.
- Navigating the org to find budget. If the decision lives in dev, budget could live in IT. So arming reps with the information they need to show who's already using the product a ton and finding out who can pay the bill. That's classic BANT stuff.
- Ensuring they're ongoing nurture/always on signals to the devs about what's coming, integrations, more tools/code samples, etc so that the fly wheel can continue on it's own. Dev advocacy / evangelism is critical here.
It's super important to not make Sales folks feel like they need to cram on all the technical knowledge to somehow pass as credible. Often when the decision maker is dev but an AE is most comfortable talking to IT (because IT has all the budget and buying experience), AE's will shy away here thinking they have to do the heavy lift to kick things off. They don't (or shouldn't) - devs getting value out of your stuff kicks things off. Good luck!
I love this question, <3 Developers! The fundamentals of sales enablement dont change, it's more the way you communicate the needs of your audience to your sales team that changes. If we unpack developers and what they want, then it makes it really easy to figure out how to approach sales enablement.
1) Developers will question to the end. They will question every word on every slide and understand it as a direction or intention. So make sure that any presentation or pitch you build for your sales team is fully accurate and defensible. A developer will ask about every permutation of the concept you lay out so you need to educate and prepare your sales team to handle any random question that might come at them during a pitch.
2) Developers are the architects of ideas. Developers are often the masterminds of a new innovation or invention in a company. So you need to take them most of the way there. Can you make it super easy for them to find the information they need to start working with your APIs? Do you have an easy to clone github repo? Do you have a step-by-step tutorial for them? Do you have a demo video ready to go? Even if a developer does sit through a sales pitch, you need to give them a carrot so make sure that there is always an actionable CTA at the end of a presentation AND that the sales team knows how to answer any questions on the set up or even do the demo themselves.
3) Developers want to dive in - yesterday. If you announce something, assume it is 1000% ready to go because developers want to get their hands on it right away. If you are doing enablement around a product launch, you should make sure that you have a tight workback schedule and that your enablement happens well BEFORE your launch so that your sales team is empowered and educated to answer any questions that come up from developers.
When selling to developers your enablement activities are likely to take on a different focus so that the team understands how to engage in a discussion and build a community while keeping their sales pitches locked in a drawer.
It will also require in-depth technical enablement and understanding of technical use cases as well as how to answer questions without trying to sell them something.
The biggest shift might be the mindset, where the sales team needs to focus on what is the best answer to my customer/prospect vs what I want to sell them. It is a very different motion and requires people to be OK telling someone that your product/solution is not the best fit for their use case or even recommending a different vendor.
On top of all of that, enablement should also help sellers navigate the differences in the org structure, their roles and responsibilities, and how to reach to high-level decision makers.
Great question, something I think about a lot. I’m a huge proponent of specialization with technical products. I wouldn’t expect every member of our enterprise field organization (which is in the thousands) to be able to carry a highly technical conversation from end-to-end, nor would I want them to! But I am responsible for dev and ops-centric products, so it can't be ignored.
What I try to do is zoom out of the customer lifecycle, pinpoint who on the team is having the conversation, and what they need to do to get to the next phase effectively – then I craft enablement for that, and that only!
A lot of that is just asking the right questions – SDRs should be asking the questions to make sure they’re talking to the right person, AEs that there is a budgeted project to attach to, SEs that there is technical fit. But where rubber meets the road, the best case scenario is to have the practitioner persona matched directly with a technical specialists on the first go around – you lose folks when it takes 2-3 meetings to get to that point, or you lose folks when you try to pitch something you don’t understand in the first meeting.
So my recommendation for sales enablement is to be very prescriptive by role – what they need most is a conversation guide that tells them what questions to ask and how to interpret them, and then how to move the conversation forward and with whom. While some reps have the natural tendency to want to carry it all the way through, they should be incentivized to bring in specialists where applicable – make it a win-win, and you avoid any objections to enablement guard rails.
One area where I’m placing a lot of my focus is connecting the dots between product-led growth and enterprise sales. I have some thoughts, but still forming a clear hypothesis. Here’s a great post I read on the subject from A16Z (https://a16z.com/2020/07/29/growthsales-the-new-era-of-enterprise-go-to-market/)
B2d follows a whole different motion. A developer is not eager to talk to Sales (and they don't want to be sold to). Developers want to try out the product themselves, tinker with it, and only if they enjoy the experience (or get to the aha moment) will they evangelize the solution up the company's ranks. Developer motion strongly aligns with the product-led-growth (PLG) motion. The trial experience from onboarding to docs, inviting team members, and getting to the aha moments can play a pivotal role in converting them to customers. Growth marketing also plays a significant role because this team can run various experiments to remove the barriers to conversion and get to the aha moments faster.
One tactic that works well with developers is the concept of "playgrounds". Playgrounds are places where developers get educational value on specific topics, and there is limited to zero selling motion. Check out jwt.io as an example. This playground is created solely for educational value around JSON web tokens. It provides a cool debugger, tutorials, and libraries for developers to engage and learn (and yes, also buy some cool sway along the way!!).
When it comes to sales enablement, just like you have a typical training motion for the sales rep, it is equally important to have a technical track for your sales engineers. SEs, in the end, will make inroads in a sales call and build that relationship with the developer audience.
I love this question.
First, I would say to save your company's BDR/SDRs time and avoid trying to set up calls with developers. You'll avoid a lot of frustration on both ends. Gating content content from developers and forcing them to fill in forms might give you a short term bump in leads, but the quality will be low.
Instead, think of the sales funnel as living side by side with the individual developer journey and look for ways to compliment the activities with the key decision makers and their technical practitioner teams.
The developer journey can be sliced and diced a few ways. I like the Orbit Model and the way it looks at community growth, but if we have to make it work for the sales cycle, it gets a little bit tricky to integrate directly.
Instead, I like to reference a journey outline that we came up with at Google Cloud:
Connect > Engage > Learn > Adopt > Advocate
Compare this to
Awareness > Consideration > Preference > Purchase > Loyalty
You can see the parallels.
You can look for opportunities to do complimentary sessions between your Developer Relations team and your sales engagements. If you're doing executive briefings, compliment it with demos or hackathon with the dev teams.
Remember that the pre-sales activities and post-sales enablement will involve the developer teams along the way. Do everything you can to make it friction-free for the developers - make materials self-serve when possible and do what you can to reduce meetings.
It's important to keep in mind that developer learning is a bigger investment by an individual than a purchase decision made for an organization. That developer is giving up precious time to invest in learning how to use your product, and in doing so, making a bet on their career and skill set. Respect this investment as part of the sales cycle and you'll earn that loyalty.
This is a classical problem for many developer-first companies. Without mentioning names, many have successfully figured out the working model with both strong developer engagement alongside a thriving enterprise revenue stream. Learning from these companies, they always focus on the developer success by doing things such as corporate hackathons, architect support, engineering blogs, etc. that helps to build advocacy for their products. It will be hugely beneficial if the sales enablement programs can incorporate a developer-first mindset by acknowledging that developers are the key influencers in the sales cycle. That will then navigate the sales conversation away from selling towards minimizing the friction in the sales process.
Developers use your tools for speed and scale to solve their problems but as the company/usage of the product grows, enterprise buyers ask for justification/business value for these products. As a developer product marketer, in addition to educating developers, you have to enable the sales enablement teams to engage in value discussions to justify the premium compared to DIY from the open-source distribution / low-cost providers.
It depends a bit on how your sales team is organized today. But in any event, your product value pillars should always translate to both individual and company-wide gain, so your core message is always consistent, even if the language changes a bit to accomodate the audience. You might consider a mapping exercise that lets you chart that narrative. For example, "velocity" is one of our core product value pillars.
For the individual: Code portability, modularity, and packages helps each developer code faster, to focus on higher value work.
For the company: More developers coding faster means faster time to market, which means greater market expansion and revenue uplift.
In both cases we're talking about how the product enables velocity, but we shift the message a bit depending on the audience. Your bottom-up materials should focus on the former example, while your sales enablement materials (assuming the target audience is an enterprise buyer, or team manager), should focus on things like revenue impact, quality, security, or other things that a manager is incentivized to consider.
I'd say the mindset shift in B2D is that it's no longer "sales enablement", but just "enablement". And that should be a shared goal across your organization, whether it's the marketing team, sales team, product or support team who are dealing with your developer.
You are correct in saying that developers do not want to be sold to, but they'll still want good support if they need it. That comes in different forms and the good news is that your organization can divide and conquer across this.
- First of all your docs gotta be like butter. Most developers will try and figure out a solution for themselves and if your docs are not up to par, their patience will wear thin.
- The second thing you'll want to do is make sure they can find answers where they expect them. Many of the companies I've been at have their own forums, but also know they need to be present in the Stackoverflows of the world.
- Finallly investing early in community/dev real will be key. This is where real enablement comes from. You can tout fancy logos, ROI case studies, sales demos all day to the enterprise buyer persona (and by all means have that at the ready) but it falls flats with devs. Developers trust content for developers by developers, and having a great DA/DE team will be key.
Your sales team needs a higher level of technical proficiency when you're a B2D company. It's important to hire sales reps that can form their own mental model of how your product works and integrates with the rest of a customers tech stack for them to be successful. They don't need to know how to code, but they do need to be able to develop a strong functional understanding of the product their selling.
Assuming you've hired sales reps that fit this criteria, enablement should focus on use cases and technical vocabulary. You should train reps on the types of implementation patterns or use cases they can expect. Technical vocabulary involves helping them understand the terms developers are likely to use and how your products performance in those areas will impact success.
For companies targeting developers, it's a good habit to build up a culture of developer empathy. Practical exmaples include:
- Provide them 101 sessions, enough for them to be dangerous and speak the lingo. What is an API? What is in a JSON payload? What is an SDK - and why does it matter if you support the customer's language or framework vs. your competitor doesn't? What is CI/CD or infrastructure-as-code, and if your product supports Terraform or GitHub Actions, why is that valuable to DevOps teams?
- Make your sales people go thorugh (at least once) the introductory hands-on workshop you host for customers. Help them understand the typical developer pain points of: poor documentation, lack of transparency (product is black box / provides no error codes or troubleshooting assistance), lack of extensibility (can't inject custom code / lambdas).
- Host internal hackathons and invite your PMMs, SEs and professional service teams to participate, alongside PMs and engineers.
- Bring actual developers and let your sales people "ask them anything" to understand their careabouts and pain points.
I think at the core of it the goal of the PMM team still remains the same: enabling sales by understanding the target audience deeply, speaking their language, and meeting the customer's specific needs. Sales enablement tactics in a B2D environment will likely differ by focusing on collateral which is heavily tech focused and tailored developer-centric messaging. Ensure that comprehensive technical documentation, API references, SDKs and quick, smooth onboarding tools and other developer resources are easily accessible. Developers often rely on such resources to evaluate products and make informed decisions. I have also found direct engagement with and within the developer communities - online (e.g. online communities where developers can ask or answer questions), and physical events (e.g. developer conference like Google I/O or re:aws etc) very helpful.
Great question. The main differences between these two audiences are their motivations - which impacts deliverability and construction of enablement materials.
B2D (Business to Developer) Audience: Cares about technical details, documentation, APIs, directionality of data, etc.
B2B (Enterprise) Audience: Cares about usability, implementation, time to value, outcomes.
Keep this in mind when creating materials to enable sales for a B2D audience so you show things like:
the flow of information (a good before and after visual could work well here)
API economy: available information and field type
Data directionality
Roadmap
These artifacts are critical to cover when enabling a sales team to sell to a developer audience versus enterprise.
Here are some tips on what you could do differently:
Highlight technical value propositions more in your sales enablement collateral
Invest time in technical training for your salesforce
Ensure your salesforce has easy access to technical information, kudos if you can leverage an internal GPT for this!
Think about how you can create self-service demos and sandbox experiences that your sales team also has visibility into
Encourage your salesforce to share technical content and resources with customers
Background: Worked as a Community Manager and Product Marketer for an open source database software company DataStax; we sold a proprietary version of the open source database Apache Cassandra, targeting the developer and administrator personas.
Developers are experts at searching for information; they're most likely to make buying moves after doing their own research and product comparisons. By the time a developer is actively engaged with sales, you can almost guarantee that they've made up their mind about what they want.
One way to enable your sales team in selling to developers, while getting developers into earlier stages of your funnel, is to position your sales team during enablement sessions as educators and central sources of knowledge.
By no means do they have to be—or should they be—experts on the nitty gritty of a technical and developer focused product, but they should be armed with proprietary and educational information to pass along. The more useful and hard-to-find this information is, the more your sales team will be viewed as a valuable source of information, rather than a nuisance.
Also, make sure they don't bullshit (easier said than done); sometimes the product just isn't the right tool for the job. Knowing when you're barking up the wrong tree, and conceding, is super important.
Sales enablement changes when your company is "business to developer" to point at a different stage in the funnel: the charismatic, knowledgeable developer who probably already has a solution.
When you are pitching to developers it helps to build a scientific, clearly logical and reasoned case for them to abandon their current solution and adopt yours based on a productivity or efficiency gain, or because you enable them to do something they simply couldn't do before.
Keep it simple, explain yourself in plain english, and err on the side of less bs and more details and developers will respect your approach more.
Top Product Marketing Mentors
