AMA: Google Product Marketing Lead, Varun Krovvidi on Developer Product Marketing

Ah, the perennial question. Before we dive into "how to", let us look at the primary characteristics of an "active and engaged" developer community; and then work our way backwards. - Being part of any "community" is primarily to serve a deeply human need. There are a ton of communities I can be part of as a developer, but why should I choose to engage with a specific one? typically this boils down to 4 reasons 1/ Identity and meaning: We derive a sense of identity and purpose from our affiliations. A developer community provides a space to connect with like-minded individuals. It reinforces my identity as a developer and gives my work a sense of collective purpose. But this tenet generally works well if it is the developer community of an "established" brand. Identity is something that is automatically provided 2/ Knowledge and growth: I want to be seen as someone who is getting things done at work. But i am also incredibly curious as a developer to learn and create. Spaces like communities provide a lot of knowledge that I can go through. But there is also a chicken and egg problem here. How do you solve for knowledge if there is no participation. 3/ Reciprocal altruism: We are hardwired to the act of helping others with the expectation of receiving help in return. Developer communities thrive on this principle, where we readily share their knowledge and expertise, knowing that we can rely on others for support when needed. This creates a positive feedback loop of mutual benefit and collaboration. In short engagement/person >>> volume of people 4/ Desire to create: Developers love to make things. They want to contribute to the world. A community provides a platform for them to share their creations, receive feedback, and collaborate on projects. This satisfies a fundamental human need to build, to make, and to have their creations recognized. Now to build a thriving community from scratch, you need to be creative in building these 4 tenets. Some key principles I would follow * Be unique: Don't try to be everything to everyone. Identify a specific niche within the developer ecosystem where your brand can become a recognized authority. By focusing on a niche, you create a sense of exclusivity and attract developers who are deeply passionate about that area. Never focus on volume of developers from the scratch. Always focus on quality of engagement as a trade off. A strong visual identity helps to create a sense of belonging and reinforces the community's identity. Create a brand identity that reflects the values and personality of your community. * Be authentic: Any community at its core is made up of people, not numbers. Imagine yourself being a part of it. You would want to be valued. Get to know the people who are part of the community. Understand them as individuals, while reinforcing the need to be a collective. You'll be amazed at the magic of being vulnerable and authentic, in building a community. * Be helpful: Solve the cold start problem by creating an initial knowledge hub of resources. This could include tutorials, code samples, documentation, and best practices. Invite experienced developers to contribute their expertise, and highlight their contributions. Encourage developers to share their knowledge and expertise with others. Create opportunities for developers to mentor and support each other. Recognize and reward developers who contribute to the community. The reward should be authentic and not something generic. * Listen, don't tell: Actively solicit feedback from developers about your product and the community. Show that you value their input by responding to their feedback and implementing their suggestions. Create a sense of co-creation and shared ownership. Feature them on your blog. Maybe give them credit for a product idea. Make them "invested" in your success

If you've spent time in the world of individual developer marketing, you know it's about passion, about the thrill of building something new. But when you step into the enterprise, things shift dramatically.You're not selling a dream anymore; you're selling stability, reliability, and a solution to a very real problem. It's not just about the code anymore. It's about how that code fits into a massive, intricate machine. Enterprise developers aren't just building siloed projects; they're solving intricate and complex web of business challenges. They're dealing with systems that have been around for decades, and they need to make sure that whatever new tool they bring in doesn't break everything else. What changes? It's all about "context". It's not enough to know your product inside and out. You need to understand their world. What are the specific challenges they face when deploying in their environment? What tools and platforms do they rely on? It’s not just about "can your product work here?" but "how seamlessly does it work here, and how can we make it even better?" You've got to solve problems in their specific context, not just in a generic demo environment. It's like a doctor diagnosing a patient; you need to understand their medical history, not just their current symptoms. What needs to change in the narrative? Flashy demos showcasing the latest, coolest feature are cool. but not enough. Enterprises aren't looking for fireworks; they're looking for reliability and simplicity. The story you tell needs to be about making their lives easier, about helping them succeed within their organizations. Think of it like a seasoned architect presenting a blueprint; it's about the structural integrity and the functionality. And here's where certifications and expert recognition come into play. They're not just badges; they're proof of competence, a way for developers to elevate their standing within their teams and organizations. It's about empowering them to be heroes in their own right. Are there new opportunities? Here's where things get interesting. The funnels you're building aren't isolated; they're interconnected. Partner with other marketing teams, explore how your developer community can amplify their efforts, and vice versa. Imagine creating a trusted network of elite developers, a council of experts who can speak on your behalf, provide feedback on new functionalities to PMs, and even become thought leaders in their own right. Look at the entire system like an orchestra, where each instrument plays its part to create a harmonious whole. I've seen many places where developer marketing exists in a silo. That's a recipe for a mediocre engagement or value. See how it fits into the broader puzzle Avoid the "Cool thing" trap. Yes, the latest, most cutting-edge features are exciting. But they're the cherry on top, not the main course. The real value lies in being helpful, in providing practical solutions to real-world problems. Don't get me wrong, the "cool factor" can be a great hook, but it's the helpfulness that builds lasting relationships and drives long-term success. It's the difference between a fleeting trend and a timeless classic.

Any developer community is about building something that resonates, something that developers genuinely want to be a part of. But, before we dive into the "how," let's really question the "why." Why are we after this exponential scale? are we looking at developer communities like a top of the funnel tactic? If that's the only reason, we're already on the wrong track. Because here's the truth: a massive, disengaged community is worse than a small, passionate one. It's like having a room full of people who are all on their phones, not talking to each other. The key is engagement, not just eyeballs. We want this to be an amplifier, not just a megaphone. So, why do we want to grow? We want to create a network effect, where the community itself attracts more developers, creating a virtuous cycle. At its core we have to understand: this kind of growth doesn't only come from us. It comes from the community itself. They should be the ones talking about it, "remarking" on it, and sharing it with their peers. that means the core value a developer gets from the community is genuinely high (technically in such cases this question wouldn't even arise). You provide the fertile ground, but the community SHOULD do the rest. So how do you go from hundreds to thousands? In the early days, those first few hundred, it's about intimacy. It's about getting to know your developers, understanding their needs, and making them feel like they're part of something special. It's like hosting a small dinner party; you can give everyone individual attention. You can learn their stories, their preferences. You can make them feel seen. But this is the point where you figure out the CORE of your community as well. what does it stand for? What core mission or need this community is driving, that it is creating a sense of belonging. then you look to scale and make thousands of developers feel like they matter? I would focus on the following * Reciprocity: Devs are more likely to engage when they feel like they're getting something in return. Recognize and reward contributions, not just with swag, but with meaningful recognition. Give them a platform to share their expertise. * Social proof: People are more likely to join a community that they see is active and vibrant. Showcase success stories, highlight active discussions, and celebrate milestones. Salesforce does this really well. They award a golden jacket and a title on stage at Dreamforce for a developer that hit a milestone on certifications. This is during their keynote. * Belonging: People want to be part of something bigger than themselves. This is where strong community identity, a shared sense of purpose is crucial. What do you stand for? * “Remarkability”: we talk about things that are remarkable. Create experiences that are worth sharing, that make developers say, "Wow, this community is amazing." Make it unique. Maybe even quirky. Empower them to become advocates, to spread the word organically.

Ah, the graveyard of developer marketing. I've seen some scars, lessons etched in the memory of many a marketing team. Developers have a finely tuned BS detector. They can smell inauthenticity a mile away. So, when strategies fail, it's often a matter of violating some fundamental principles. There are infinite ways this can go wrong, but here are few: Feature dumps: One classic blunder is the "feature dump." You know the drill: You share a barrage of tech specs, a laundry list of capabilities, all presented without context or relevance. Developers don't care about the minutiae; they care about what the product does for them. In reality, this happens if we treat devs in the community as numbers and treat our interactions wiht them as a "job to do". Genuinely care about their problem and you'll immediately the see the fallacy of treating this as a megaphone activity. It's a failure to understand that developers are problem solvers, not just feature collectors. I hate to say this, but "marketing speak" trap: Then there's the "marketing speak" trap. Buzzword-filled blog posts, and generic testimonials. Developers see right through it. Be human. We all crave authenticity, transparency, and genuine expertise. It's like trying to convince a seasoned chef that your pre-packaged meal is "gourmet." Not just dev communities, but we all know the difference between substance and fluff. More than anyone, devs value honesty, and they will punish a company that is not honest. Ignoring the "community" aspect: Dev communities are as the name says -- communities -- not your audience. Perhaps the most egregious failure is ignoring the community. Developers are a collaborative bunch. They thrive on sharing knowledge, providing feedback, and contributing to the ecosystem. When we treat our developer community as an afterthought, a mere marketing channel, we are missing a golden opportunity. It's like having a room full of brilliant minds and refusing to listen to them. This creates resentment, and developers will leave, and take their voice with them. Push-only marketing: The golden rule: Listen more. Developers are fiercely independent. Rightfully so. Every person's context of work is different. Push marketing tactics, like aggressive pitches and intrusive ads, are a surefire way to alienate them. It's like trying to force-feed someone a meal they don't want. Devs want to discover solutions on their own terms. They value autonomy and control. Empty promises: Overpromising and underdelivering is a cardinal sin in developer marketing. It erodes trust and damages credibility. It's like promising a rocket ship and delivering a bicycle. Developers are pragmatic; they value honesty and reliability. Not just them, but think about it. Will we forget a broken promise?