Lauren Buchman

Developer journeys can vary, especially based on the nature of the product, but generally the journey looks something like:Connect > Engage > Learn > Adopt > Advocate The key difference between this journey and a classic funnel is that rather than investing money from a company's budget, developers are making an investment in their time and energy to learn how to use your product. During the "engage" phase, developers are poking around - checking out documentation, looking at what ki ...Read More

Great documentation, a robust and engaged community, a high quality developer experience, and engaging demos are all important when marketing to developers. If you can only invest in one of these, great documentation rules the day. The quality of your documentation is a bellwether for the quality of the product. It makes or breaks trust with developers. So if you're evaluating what to include or invest in for product launches, content, or other motions, always pick documentation. It should be cl ...Read More

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? Wh ...Read More

Developers can be highly influential to the buying process so I wouldn't count them out just because they don't own a budget. That said, I would look at persona-driven campaigns as the best place to split out your developer-centric messaging vs. buyer-centric. Take a look at your channels with the largest following of developers and speak to them there. If you don't have channels to reach them, look at 3rd party channels and engage with developers there - Reddit, Stack Overflow, developer confer ...Read More

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: Software developer Software engineer Mobile developer App developer Web developer Data scientist D ...Read More

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 advantag ...Read More

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 the ...Read More

The skills are the same to be a great marketer for either - knowing your audience, curiosity about people's problems, and a solid understanding of your product's value proposition and differentiation points. For developer-focused PMMs, it is helpful to understand the different types of developers and how they have been changing over time. Popularity in languages, software development methods and trends over time, etc. But mostly, you need to feel comfortable diving into technical topics and stay ...Read More

Adopt a 'no surprises' North Star for your PMM team, and use visual cues to make updates easy to skim and act on. A strong PMM team charter should aim for no surprises — no one should ever be caught off guard by what PMM is doing, whether that's executives, ICs, or cross-functional departments. To support this: - Use green/yellow/red status indicators in project updates so people can orient quickly without reading everything. - Maintain decision logs and escalation pathways. - Lead with a 'botto ...Read More

Build trust, find the right executive sponsorship, and focus your energy where you're explicitly welcomed and can make an impact. In engineering-driven organizations, not every team will immediately see the value of PMM. Rather than trying to win everyone over at once: - Find the teams and individuals who want to be successful and work with them. - Make them successful and tout those wins. - Other teams will want to be part of what you're making happen — the right folks will follow. - If executi ...Read More