AMA: Matterport Former VP of Product Marketing and Platform, Indy Sen on Developer Product Marketing

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. 1. 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. 2. 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. 3. 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.

Lol, yes, marketing to developers and technical audiences like data scientists is not for the faint of heart. They are naturallly suspicious of glitzy marketing, and have very low tolerance for buzz words (e.g. "business transformation", "collaborative intelligence", etc). Wining and dining them will only take you so far (to this day, engineers are the only employees who get a free meal at Apple). And when you ask for feedback, boy will they give you feedback. Brutal. Honest. Feedback. But here's the thing. The minute you win them over with the quality of your solution/tool, they will evangelize the f out of it. Because your solution (dev tool, API, client, platform) if it works well, gives them the ability to do something faster, better and/or in ways that saves them tons of time and headaches from a support, maintenance or non-recurring work standpoint. Better yet, you'll make them look like geniuses for implementing and betting on your tool. So my main advice is focus on winning their hearts, not wallets, by striving for a great developer acquisition experience, a company brand that simply shows that you care, content that's written for them, ideally by them. 

I like the spirit of this question, as it's not just relevant to API products but also any product that has a similar onramp due to it being technical. You also touch on something that many inadvertently forget--that it's not enough to launch a product, you also have to think about the "landing" and how to drive continuous engagement. Here are the few things I've seen teams do: * At the product level, you want to monitor API usage, and depending on the behaviors you're trying to drive, figure out whether they're hitting the points of interest that don't just denote that they're onboarded (assuming you have some kind of tutorial or "hello world" moment in mind), but that they've made a bunch of calls, connected the API to an app or workflow and moved whatever process they're trying to build into production. Typical PLG phases track to this i.e. activation > adoption > standardization > advocacy * For marketing, I can share what we did when I led developer marketing at Mulesoft as an example. There we ended up building three specific user journeys that tracked a developers progress across the process of consideration (mostly marketing driven) to onboarding and adoption (product and customer success driven) and used a mix of tactics to lead them through it: email nurtures specific to the intent we had flagged at the time of sign-up (e.g API design and management) to get them situated, interactive html5 walkthroughs when they first logged into our platform based on that intent (implemented WalkMe for this), and then based on usage patterns would trigger follow-ups from CS on how they were doing and whether they needed help (that latter part was a bit higher-touch but lucklily this was a function I could rely on given how important onboarding and going from PoC to production was important to what we did). * Finally, I think it's really important to highlight the successes of other developers on your platform and make sure that devs who are earlier in their experience with your solutions can see this. You want to make it aspirational. One of the things we did really well at Box for example in the early days (or even Salesforce for that matter) was tout the successes of our developers and partners across our channels. For example, featuring a developer/partner spotlights on your blog, doing a homepage takeover or carousel item that highlights a specific developer project or partner, and even leading with external signage/billboard that puts those developers first are all things that demonstrate that your organization lives and breathes their success. If you're a pureplay platform company, you're likely already thinking about this, but if platform is an adjacent GTM (e.g Salesforce, Slack, Okta, Apple), you need to make sure that marcomm understands this and keeps it in rotation alongside your company's other narratives.

Good question. You should definitely have the technical stuff at the ready, and usually docs will be your best friend for that, as would "Getting Started" guides, video walkthrough, etc. But I tend to think of the technical stuff as the what and messaging as the how. Developers are people too :) You don't have to throw the technical goobledygook at them outright. Especially when you're trying to convince them of your value props. That's where good messaging comes in. Be as straightforward and human as you can be. They'll know where to find information on your ESB, CLI, App Script, API, SDK and will definitely expect that information to be there once they're ready to technically implement. But messaging should focus on getting them to mentally commit. When our team launched Gmail Add-ons in 2017, we built a really cool way for people to add their third-party app in Gmail's now ubiquitous "third-rail". We had the Apps Script tutorials and SDK documentation for that, and they knew that Gmail was their ticket to a billion eyeballs. But here's how we "messaged" it. WRITE ONCE, RUN ANYWHERE With Gmail Add-ons, developers only build their integration once, and it runs natively in Gmail on web, Android and iOS right away. Users only install the Add-on once, too, and it shows up in Gmail across their devices. So instead of wasting time writing separate integrations for web and mobile, you can focus on bringing your app’s most powerful features right to your users when they need them most. Gmail Add-ons are built in Apps Script using a newly-designed "Card" system that lets you easily combine different UI components. Developers can create a snappy user experience that feels like it was natively built into Gmail. The result: integrations that are cross-platform from the get-go that save your team time. Link: https://cloud.google.com/blog/products/application-development/bring-power-of-your-apps-into-gmail_9

The key thing is will he or she be able to effectively fight for developers to have a distinct voice within your organization, especially for what they need to do in order to be successful. I've been at many companies where developer marketing or the B2D platform play was secondary or complementary to our key enterprise B2B play. T There's some baggage that comes with that from a GTM standpoint... notably a visual and verbal identity that doesn't fit all sizes. There's a myth that developers don't like marketing. I disagree. Developers don't like bad marketing (who does?) and the number one cause for that is if you speak to developers the same way you would to your ITDM/buyer personals. It never works and makes you look like "shirts". The best B2D product marketers will therefore help stand up a different (but complementary) look and feel for their developer audience. One that can co-exist with the core company brand and sometimes even hijack it (e.g Salesforce).

In of the questions above I alluded to having a developer marketing funnel. This is like your classic marketing funnel across top of funnel and middle of funnel but where bottom of the funnel should end up being focused on adoption and advocacy, not sales. Which leads us to how you measure effectiveness. Like with any GTM, you need to first begin by what you want to achieve before designing goals and measuring things. By and large these are the metrics broken out by funnel stages. Top of funnel: 100% you should look at traffic/visits, trials and sign-ups for your product, API keys generated, shares on social, buzz etc Middle of the funnel: distinct for every business but approximate it to your "hello world" moment or magic moment where the developer has tried enough of your product to want to take that statistically proven "next step". If you're doing events (digital or live), attendance is also good metric for this, especially if they came from a campaign. Product might want to monitor uptick in DAUs/MAUs based on your latest "marketing" push too. Bottom of the funnel: Straightforward. It can be # of deployments, # of apps pushed into production, # success stories and of course $ in either pipeline or in booked revenue if the developer is also the purchaser. I know you asked about campaigns specifically. This can be a tough one. Ideally it should be good enough that your campaigns help attain/influence any one of the metrics you have above. Not many roads lead to revenue in B2D, but ROI can be measure in other ways: Sign-ups. word-of-mouth/buzz/street cred, media coverage, and last but not least advocacy.

I'd say Developer Marketing + Developer Relations = Developer GTM. You'll want to pair these two functions as much as possible, and the way I've always thought about it is that Dev Marketing structures and provides the overall air cover (awareness, channel and content strategy, program management, measurement) and Dev Rel parachutes in for the high-touch stuff: enablement, evangelization, content production. Dev Rel are the true subject matter experts, the most authentic voices behind your product who can speak and directly enable a developer and with whom she can relate. Ideally you reserve Dev Rel for high-touch engagements whether it's 1:1 clinics, meetups, or sessions where they present to your audience at conferences. Dev Marketing is then the orchestration layer. You figure out what the goals are with Dev Rel (broader organization too depending on your size) but then prioritize and build activites according to your developer marketing funnel, which is very similar to your typical marketing funnel for ToFU and MoFu but where BoFu is about driving adoption, and not necessarily sales. That last part is actually important. You're not going to be very successful if Dev Rel/Dev Marketing is being goaled on sales vs enablement and reach. That's why it's really critical that Dev Marketing be set up as a dedicated function whose job it is to support Dev Rel. 

The key to getting started imho is alignment. This is especially important in B2B/B2C organizations where developer marketing may exist alongside a traditional marketing organization that's focused on the customer/buyer persona. Developer marketing, as mentioned in some of the answers above, is not your traditional marketing discipline in that it's more focused on adoption and advocacy than revenue. If you are being asked to have an impact on revenue, you'll just need to make sure you're resourced for that. Which underscores some of the other keys to getting started. Assuming alignment on goals, you'll also need to set your team up for success. That means a hiring plan and budget, as well as a handshake on what are shared resources and channels or not. Back to the point I made earlier about developer marketing requiring it's own verbal and visual identity, you'll want to make sure you can advocate for the cleanest developer experience as possible. At Box, it took our team a bit of time to ensure that developer marketing was not just a hand-wavey thing. We all knew it was important, but no one in the organization had a clear sense of how to orchestrate it, so it was a hackathon here, a promo there at first. And that got us to some initial traction, but nothing to write home about. The biggest thing you can do as a developer marketing leader starting, is to draw up a plan that first focuses on alignment and then inspires with a vision for execution based on battle-tested programs and contents. Have fun with it. By the time we hit our 1 year mark and blew our API key growth goals out of the water, the entire team was rooting for us. I think most businesses, especialy in B2B, understand that the developer channel is existential to their business. What prevents them from reaching escape velocity is alignment and resourcing.

Yep, a question that's near and dear to my heart because accurately representing your developer journey is such a clarity boost for everyone on the team. I like to think of the developer journey as a developer funnel. That's why developer marketing is still marketing at its heart. Traditional funnel, as always: * Top of funnel: Awareness, Interest * Middle of funnel: Consideration * Bottom of funnel: Preference, Sale Developer funnel, is very similar, with the exception of BoFu: * Top of funnel: Awareness, Interest * Middle of funnel: Consideration * Bottom of funnel: Adoption, Advocacy This is why your GTM will require many of the elements of traditional marketing across brand, growth, demand gen. But instead of a handoff with sales, you're going to have your developer advocates/evangelists, product team and solution engineers involved prior to an actual sale or purchase taking place. This is especially true for complex solutions like middleware or PaaS but anything you can do to grease the skids towards BoFu motions that lead to adoption and advocacy should be what you goal yourself on. Of course, if your product is self-serve then adoption should lead to a credit ard being swiped and recognizing revenue. But if you're part of a more complex sales motion, your job is to get the developer to fall in love with your product, get immediate value out of it so that when their IT buyer or LOB leaders asks thems about your solution, they can give them an enthusiastic thumbs up. There's a reason why Twilio has that excellent tagline: "Ask your Developer". What a flex!

There's no silver bullet for this. You want to bake competitive research into everything you do and have your antennae out. The cool thing about product marketing is that done right, you have a unique vantage point. You are the closest members of your team to customer conversastions, product conversations as well as what analysts and influencers think of you. So you have to synthesize those inputs. Take and share notes on an ongoing basis and then summarize findings in battlecards, competitive dashboards, win/loss analysis. Bottom line: Competitive Intelligence is a full time job. Competitive intelligence is always one of the first things I tried to build in my PMM organizations, having benefitted from great competitive intel early in my career as a PMM too, I know how valuable having the right facts at your fingertips can be so that any time a competitor comes in a conversation is an opportunity to deposition them or, frankly, to deposition yourself if this is not a conversation you can carry based on requirements. Saves everyone time. To gather competitive intel, a quick shortcut can be scanning prior customer conversations, look at deal entries in salesforce/your CRM to the extent competitive info was captured there, and prioritize the research based on who appears on deals. You can also carve that work out to an agency who will create battlecards based on independent research and customer interviews. Talking to analysts via an inquiry, especially if you're a larger organization, is also a healthy practice. But again, don't take this on by yourself, unless it's the #1 prioritiy. Either hire for it or outsource it to begin with. Finally, you can also look into implementing a CI tool/dashboard. Once you have the data, I've found tools like Crayon super useful to disseminate competitive intel as well as gather new inputs as it allows anyone to add to them. That makes competitive intel more of a team sport, which depending on your company stage, is not a bad thing!