Lauren Buchman

At it's core: it's not different from B2B or B2C when you strip it down to the pillars of what makes for any successful marketing. Understanding your audience: * What are their drivers, their pains, their perceptions? * Where do they gather? * Who do they trust? * How do they influence the buying process in their companies? Are they highly influencial and going to drive product sales and adoption organically? Or is enabling them as a post-sales activity a critical pathway to success and a blocker? * What is the cost to acquire them? What is the lifetime value of a developer customer to your business? Understanding your product's value proposition to the audience and how to communicate that to them, authentically. Developers are humans, just like any marketing audience. We all have ramp time to understand a new segment and it's about making the same level of investment and curiosity to figure out how to connect with them. Just as great marketing takes the same work, bad marketing comes from the same problems. Lack of authenticity leads to lack of trust and people tuning you out.

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.

It depends! A common pitfall in developer marketing messaging is that the marketers spend a bunch of time trying to put things into terms they can understand as a non-developer. The trouble is, what works for you doesn't necessarily translate for them. Focus on the problem that your product is solving for them, how they would describe it, and what resonates with them. That said, the messaging is often times going to veer away from classic organizational benefits: cost, ROI, competitive advantage... towards an individual's benefits at work: reduction in friction, increased personal productivity, being freed up to do more interesting work, etc. Focus on the individual human, not the organization and the level of technicality should sort itself out. Also, don't be afraid to do deep dives into the technical to build your empathy and understanding. Any technical topic can be grokked with curiosity and dedication. Your product teams will appreciate you and you'll build trust with your developer community if you make this investment.

Developer personas are diverse! You could rename them "technical practitioners" to better describe this group of humans. High level, in the business world, they are the folks who put fingers on the keyboards, not the folks who write checks. The operators. Because of this, there are personas that will work for some products, and not others. Some of the ways developers can be grouped is by job title: 1. Software developer 2. Software engineer 3. Mobile developer 4. App developer 5. Web developer 6. Data scientist 7. Data engineer 8. Machine learnist 9. Network engineer 10. SRE 11. Security engineer 12. Cloud architect The list goes on... and there is probably someone yelling at their computer screen that I missed an emerging role right now. ;) Another way to group them is by the language community they belong to. I love the GitHub Octoverse Report for updates on these communities, and highly recommend it as a must-read. Beyond these, it's also really useful to break developers down into two key categories: influencers, and delivery teams. Influencer developers are those that work in the same teams that make product and business decisions. Marketing to influencer developers can lead to opening up deal flow, and will typically include innovators, early adopters, and early majority folks on the Innovation Adoption Lifecycle. They will tinker, hack and figure out how to use the new technologies and will often do the bleeding edge use case work with your product. Delivery developers are those that do a lot of the outsourced work for companies. These developers are the unsung heros of making stuff work for so many enterprises. They will have less influence over technical tooling, but their ability to be successful with products makes or breaks successful business engagments. Certification programs and growing this ecosystem is really helpful in building trust and confidence in later adoption curve stage customers. As you work on developing the personas for your product, I also recommend the materials as part of Clair Huntsaker's talk for Heavy Bit.