Vishal Naik

I think there are two areas to start with: where the user is working from and what use cases you can create. From a user experience POV, if you need to embed your tool into another system of record, that’s a good starting point. If your software is where your users are going to be working in, then the question I’d ask is if you have the resources to build all of the use cases that your customers may want. If you going to prescribe to an 80/20 rule where you’re able to build those use cases that appeal to the masses, then a developer platform where customers or external developers can solve for those last mile use cases, would also add value. 

In terms of building the marketing program, Id start with that top level goal as that will help you drive your value prop and also help define why developers are coming to your platform. 

From there I’d get into the details by uncovering what customer value developer offerings would bring, as you’d want to figure out how to market to developers while also planning for how to market what developers create. (Tip: keep these functions aligned, splitting up marketing to and marketing of developers is one of the biggest reasons where I’ve seen developer marketing fail)

As you build out your developer marketing team and function, keep a healthy mix of technical people that can speak to the API details and coding work but don't forget about core marketers who can speak to decision maker personas and can layer in the business value of the developer platform. Over-indexing on one or another will yield an underwhelming program.

And while being scrappy is great, its easier and faster to bring in an agency to do market research to find the answer to that hard question than it is to hire a candidate who has done the specific thing you do in the specific way you want to do it. Gravitate to speed towards the answer you need rather than needle-in-a-haystack domain expertise. 

Build great relationships with DevRel, re-evaluate your perception of what channels work or don't work from your previous experience (because developers do act differently than other personas), and pay a lot of attention to the end user. Yes you're focused on developers, and yes developers have unique needs and actions, but they are driven by users. So think about the user because that's where the developer wants to go, and if you can meet the developer where they are going, you can focus on the areas that will drive sustained health in your platform and yield usage and monetization impact for your developer audience. Oh and be prepared that internally you are often on an island and it's an uphill battle to win internal stakeholders, especially if you're in B2B, but the reward is worth it in the end. 

First off, I don't think there is a template on building out the marketing function, it depends on what makes the most sense for your organization. If I were in your shoes, I’d take the Moneyball/Strengthsfinder approach. You’re already on board as a self described non-technical PMM. If you bring in DevRel earlier, you may be able to cover other non-technical marketing needs by yourself and leverage your DevRel counterpart to help carry developers through the funnel with more technical conversations and how-to. But if your lead funnel is both business customers and developers, DevRel may not help you with your business customers. So if your big gap is top of funnel across both personas and getting leads routed appropriately, you may need Demand Gen. Also, what does your customer journey look like? Do customers start with developer tools from day 1, or do they onboard use your existing software and then graduate to the developer platform after a time/usage threshold has been met? That may also guide what makes sense for you. I’d suggest you start with your present state, think about your goals and your ideal customer journey, address your current gaps, and then decide if the best next role is a more technical person on the team or someone who can help you build demand. Personally, I tend to view storytelling as a key part of product marketing, so I’d probably not lean to a dedicated content resource above those other two as I tend to think PMM could own that function pretty well, especially in a smaller org. 

Newsletters are great--to a developer or not, email marketing has a ton of value. At my last company, email was the #1 driver of actions–that was consistent with web and mobile customers as well. But there are a handful of other mediums you can lean on as well. YouTube, Stack Overflow, Twitch, Reddit, Twitter, and LinkedIn all have done pretty well. Also at my last company, someone on my team had the idea to run Google Display ads, and they performed really well. Depending on the size of your organization you may also have a Developer Relations team. Hosting events or webinars/livestreams also tend to perform well. And don't forget your website and your blog, because your developer content is often one of the first places a developer will go to find out information. So think of it like marketing to any customer base: consider where they are in the funnel, think about what actions they need to take to get to the next step, and then leverage the mediums you have at your disposal to push them through the funnel. 

The best sales people that I’ve worked with “know enough to be dangerous” meaning they dont try to know everything, but they know enough to have a basic conversation and then know the right resources to bring in to continue the conversation. So I try to arm Sales with 101 level content so that if an API conversation comes up, they can handle the first couple of questions and use it as a reason to schedule a follow up call with an engineer or developer advocate. But if you’re expecting a sales team to carry the full conversation with a developer, it's probably not going to be a successful outcome as it's too specialized (persona style, talk track, questions, etc.) versus your sales team's normal buyer. 

How I described developer marketing in new hire onboarding at a previous company is that a developer platform gives someone the ability to customize their needs in a particular software product. And there’s both a business and consumer opportunity to this.

For example, at a previous company we were buying email delivery software and I met with two market leaders. Both did about 80% of what I wanted, because they were built for common use cases, but my organization had our own way of doing things. So neither product completely solved our needs. A developer platform on top of either would have given my company the ability to make some customizations to solve 100% of our needs. 

Another example is when you as a consumer use Facebook to log in to a website. With this functionality, the website owner doesn't need to create a login experience and also doesn't have to tap into the entirety of Facebook. 

The Developer is the person that writes this code for a software product. Developer Marketing is how we as marketing professionals excite developers to try new functionality as well as evangelize the work that developers have done to excite customers to try these new user experiences. 

To me, the only real red flag is being a personality mismatch. Culture fit is important, and working with someone who isn't on the same page as you and the rest of your team around their motivations will only make the job harder and more stressful. Job hopping or gaps in a resume or experience in a different industry or any other potential warning signs aren't actually red flags to me because there is probably a reason behind it all and if you hire the same background all the time, you won't be prepared to solve a new challenge. 

I tend to look at DevRel as a pretty unique role that's part CSM, part Marketing and part Pre-Sales. Developer Marketing is full-stack marketing around a technical product. To sum it up quickly, DevRel tends to have a great pulse on the developer community and how your current developer audience will feel about your launches or features. Dev Marketing tends to have a pulse on positioning, bill of materials, product management alignment, etc. So I tend to look for Dev Marketing to influence roadmap, build a product narrative / comms plan and execute GTM vs DevRel to engage the developer community, surface back real-time feedback and help developers that are building an integration to actually get it live. Think of it as DevRel is a little closer to the customer and a little later in the funnel than where Dev Marketing sits. 

Developers want to know what something does and how it works. They want to jump in and try it out themselves. They want to see something new and get their hands on it. I’ve seen some persona work that says developers like to be the smartest person in the room and value content that stumps them. So you can say it does need to be technical, but it's not really about how technical the copy is and more around are you creating a message that caters to how the specific persona engages. If you lead with the story arc of market problem -> winners and losers -> product solves problem, that won't really tell a developer how to create something. Rather than look at it as how technical messaging needs to be for developers, I look at it as the core developer work isn't always early funnel. And early funnel content is more around the art of what's possible vs later funnel content is more around how to get something done. Marketing to developers tends to map closer to later funnel content. 

My biggest piece of advice is to not forget about decision makers and end-users. Developers are a hugely important persona that has a unique set of needs, but they are ultimately not the sole decision maker in most organizations and they build for users. So if you can know about who the developer is building for and who else the developer is going to interact with to make a decision, you can build a pretty sound developer marketing strategy. Oh and do persona work and potentially external research on all of these audiences. Developers don't like being marketed to and will see through any fluff, so how you nuance your message to resonate with this group is important, you’ll want to be more sure of your message than with other audiences so you may need to do some extra validation.