Frequently when I speak with folks in the graphics industry about product management, questions about developer’s issues come up in conversation. Any kind of large-scale software development project requires support, so it’s not surprising we’re seeing the establishment and growth of developer relations programs in many tech companies.
This got me to thinking how they’re interrelated: in a very black & white nutshell, I see managing product a bit analogous to inbound marketing and developer relations as somewhat analogous to outbound marketing.
This is overly simplistic, but I think it helps frame the discussion for how to maximize developer relations’ success with the goal of shaping, shipping, and managing a successful product (for example, be it an API, a complete SDK, or perhaps even a game engine & editor).
It’s important to note that most managers involved with developer relations for software products hold a firm belief that anyone hired to work with developers on behalf of the company need to be as skilled (or almost as technical) as those very developers. I hold a slightly different view because I’ve had the fortunate experience to work with both sales engineers and technical marketing support folks in both software and hardware firms. Support from great sales engineers and excellent technical marketing people are as important to developers’ success with your product as your developer relations outreach efforts.
In my experience, I have not seen much in the way of formal processes in place around gathering customer information and requirements from developer relations engineers but I have seen plenty of process and even worked with some awesome applications for managing inbound leads as well as outbound marketing practices – many of which were inspired by developers using the product.
It may be worthwhile to apply some of the marketing industry’s best practices to engineering product management and good ole’ fashioned developer relations.
A keen awareness and repurposing of the various tactics, techniques, and tools from the marketing technology industry can help provide a framework for successfully managing the developer relations’ process in such a way that it effectively optimizes product. But first, let’s take a look at some key similarities and differences between the two fields: marketing and developer relations.
Establishing trust between company and partner/customer is first and foremost for both. In any relationship, be it born of a marketing outreach program or ad hoc developer-to-developer relationship, one must first establish trust.
I came across this great post on Quora based on the writings of “trust expert” Charles H. Green, who describes the 4 ingredients of Trust in (Understanding The Trust Equation). Here’s the conclusion, but I suggest reading the aforementioned Quora post if inclined, as the comments are also noteworthy.
Conclusion: Reducing perception of Self-Orientation is the greatest lever to increase trust in relationships. Ask more questions. Listen. Don’t fill silences. Let the other person feel that their point of view, their feelings, their presence here are as important than your own. Charles Green also has a pretty cool infographics on trust on his blog.
Establishing a sense of trust and actually being trust-worthy are essential for any business to succeed, but seem particularly important in the sales and developer relation’s role. I think this is why marketing and marketers often get a bad rap from engineers: they are just too far away from actual customers, and therefore the trust variable may not factor in as seriously as in developer relations or business development. In fact, I do not think it’s too much of a stretch to say that I have seen many folks in business development with strong technical backgrounds take on the role of developer relations as well, especially in start-ups and smaller companies.
Okay, now that I’ve gotten trust taken care of – which may be the most obvious outlier that differentiates marketing programs from developer relations programs, let’s take a look at what they really have in common.
Key tenets both Marketing and Developer Relations share:
- Opportunity to share your vision with the community that you think will either entice them heartily to engage with your product and/or solve their problems
- Proactively listening to what the community needs and filling developer needs with concrete help and support via any conduit possible
- Providing an easy to find, easy to use conduit for developers to offer you feedback, e.g., using social media’s ability to bring market feedback back into the mother ship
- Analytics tools to measure outreach and feedback success. Note that marketing seems to have more tools at their disposal than developer relations. Still, any developer relations program can be strategically planned to take advantage of some great marketing and sales tools if architected thus.
Okay, now that I’ve drawn some hopefully useful parallels, let’s take a look at some of the better-known developer relations programs out there today from the likes of Amazon, Apple, Google and Microsoft, just to see how they shape up in terms of “best practices.”
I’ll start with Google’s Scalable Developer Advocacy program:
From Google’s Reto Meier on Quora: https://www.quora.com/What-is-the-Scalable-Developer-Advocacy-team-in-Google-Developer-Relations:
Scalable Developer Advocacy is part of the Developer Relations team — whose role is to be the interface between developers and Google’s developer offerings.
More specifically, Developer Advocates on the Scalable Developer Advocacy team are engineers who operate at scale to inspire and teach developers about Google’s developer platforms, ecosystems, and APIs.
They are responsible for crafting a narrative based on developer and product needs and priorities; creating engaging, discoverable, and useful developer content (including training, videos, blog posts, social media, web sites, and conference appearances); and delivering and distributing that content at scale to as many developers as possible.
The team also receives and analyzes feedback from the developer community, and advocates on behalf of developers with Google’s product and engineering teams to adapt and improve the underlying platforms and APIs.
Google’s “content tsunami” pretty much sums up Google’s perspective on developer outreach, which while awesome in many ways, and certainly useful when searching for specific content help, may be a bit overwhelming to some. That said, a few years back, I was very happy to have the Chrome daily builds and plenty of blog posts about their new WebGL support around when testing some WebGL code.
As Google is well known for holding the bar of rigorous technical hiring standards very high, it’s probably safe to assume the content and support coming out of Google is best-in-class. Last June, Reto Meier also wrote a great post, “The Core Competencies of Developer Relations” on this very subject. He says: “… a thriving developer ecosystem needs a trusted Developer Relations team made up of engineers who are the interface between 3rd party developers and the engineering and product teams building the underlying platforms.” This perspective will surely enable experienced developers on their platforms, but it may be a bit intimidating to developers just getting started on their software and platforms.
Next up, let’s take a look at Apple’s best in class developer programs:
Apple’s developer outreach and developer relations are today considered by many to be best in class; just go to https://developer.apple.com/ to see how succinct, streamlined and efficient it is for developers to get the info they need – to a point. The point being their developer support ecosystem is deeply meshed to point developers straight to developing and submitting for their respective operating systems.
Education is a bit buried but it’s still there, and their interfaces to information are second to none. I think Apple does a very nice job welcoming beginners and newbies as well to their platforms and OS’s.
Education is a bit buried but it’s still there, and their interfaces to information are second to none. I think Apple does a very nice job welcoming beginners and newbies as well to their platforms and OS’s.
And now Microsoft:
Microsoft’s generic website is a tad disappointing from the developer relations perspective, but a quick search for “Microsoft developer relations site” brings Microsoft’s top hit to Microsoft Edge, (screen shot shown below with my clicking on the drop down menu ‘Developer technologies’ at the top of the white bar).
To be blunt, outside of Microsoft’s deserved success for the Visual Studio IDE product line, crafting clever marketing terms such as “Edge Dev” when you really mean “developing with Microsoft for the Web” just adds unnecessary overhead for developers IMHO. Why not just call it “Microsoft Web Dev” or something easy to remember and find like that? I’ll probably never remember the word “Edge” again…
In any case, finding Microsoft developer support and information is not hard, and probably useful enough, thanks to Microsoft supporting developers for decades, as well as being fairly ubiquitous in the software industry, but it’s not something I’d want to model a new 21st century developer support program on.
Last, but far from least, is Amazon’s developer relations and outreach found at https://developer.amazon.com/public/solutions and from where I clicked on “Getting Started,” shown in the screen shot below.
Amazon does a great job segmenting support portals for their various markets including platforms (e.g., PC/Mac, iOS, their own Android OS based Fire, HTML5, even game engines such as Unity), devices (e.g., Fire TV), to services (e.g., Alexa). Beyond that, but quickly findable from their developer home page, it’s easy to find resources such as API help, resources, and more support.
Extra credit for their Flipboard style home page:
But what about that framework I discussed earlier that takes advantage of marketing technology to support best practices for developer relations?
There is not much on the internet in the way of research on how to best manage your developer relations program but I did find this data focused article helpful from the London based agency Metia, because their report shows just how solitary is the work of a developer, how frequently they do the majority of their work from home, and how reluctant they can be to engage off-line, and if they do, it’s generally for key conferences and off-site training to enhance their learning. I have found this to be true in the game development world in particular.
Some of the marketing industry’s best tools can be put to effective use in the developer relations discipline if these programs can be repurposed to bring together connections and content to support your (developer customers’) code development process.
Thanks to the enterprise cloud computing era we find ourselves in now, many of these “marketing tech” SaaS tools provide the perfect test bed for in-house management of developer relations best practices. If an organization approaches management of developer outreach and relations similarly to how it manages product launches, this may enhance the developer’s experience with the supporting company, as long as there is no resulting marketing-like overhead to the developer.
What kind of tools can help?
CRM tools are of course now ubiquitous, but CRM is NOT DRM (repurposed here to mean ‘developer relationship management’), but… there are times a combination of a few great tools can be close to what is needed. Whether it’s community (forum, bug/issue tracking), or content (SDKs, code snippets, white papers, FAQs, etc.), “there’s an app for that” – and usually the one your developer end-user wants is open source and cloud based. Similarly to cloud-based applications such as Salesforce being nearly ubiquitous for business development professionals, applications such as Github, Bugzilla, Slack, Trello, Jenkins, etc. are where developers turn to for code access and maintenance, bug-filing and tracking, communication, build support, and twitter, StackOverflow, LinkedIn, etc. for community, education and help. You might even consider adding one or two good project or product management tools to the mix too if that makes sense. A nicely curated product management tools list can be found on Product Hunt but I think this Quora post has a more comprehensive list; still I found no applications really targeted at managing developer relations. There always seem to be plenty of project management tools as well. Capterra’s new 2016 list of top project management tools is worth a look.
From my own experience, CRM tools like Salesforce, Eloqua and Marketo can all be customized, to a point, to support developer outreach and developer relations programs, but I have yet to come across any marketing technology tools used specifically in a developer relations capacity (in practice). Finding, tweaking and using the best tools can help your organization create best practices for managing their developer relations team.
But what about hiring former developers as DevRel managers?
Too often (and with the best intentions), corporate managers tend to hire former and current developers for their developer relations team – and developers tend to do what they do best – write or tweak code. This is great and on the surface makes perfect sense, but it’s also important (even on a very limited HR hire budget) to hire at least one developer savvy marketing or business development professional. Today, many people in marketing or business have been working with engineers for years, and many have even dabbled in their own development projects. However, perhaps more important than technical ability or deep insight into the product is the skill to bring empathy and then trust to the table, coupled with the skills learned through years of marketing technical products. These skills, applied to developer outreach and relations, can be very valuable to the company’s stakeholders.
Experienced individuals who’ve worked in marketing for a while generally know well how to craft information in an engaging way, how to message it, and how to track results, but may not be as tuned in to the developer mindset as an experienced developer relations professional (with development experience). Joining the two together on a team can be very productive. A two-way symbiotic relationship between marketing and developer relations can bring out the best products for developers that are not merely self-serving the company’s bottom line – something we see all to often in marketing programs.
Marketing to engineers and software developers is growing increasingly more common as many new products entering the marketplace are for use online, in gaming or some kind of alternate or mixed reality space (e.g., AR/VR), all of which come with APIs/SDKs/ADKs and toolkits to access or enhance end users’ experience with the core product offering. Metia, mentioned earlier in this article, posted a blog on Venture Beat a while back that makes a lot of sense: “Software CMOs, meet your toughest customer: developers.” Beyond documenting some of the obvious ways developers are more discerning from other non-engineering consumers, perhaps the best takeaway here is the fact that companies marketing to software developers need to be “… prepared for their enterprise-class expectations in terms of ease of use, documentation, service levels, and reliability.”
Think of it this way: assume the software developer has a need to absorb your true value-add in a faster, more coherent way than what any traditional marketing campaign can deliver, delivered in a way that is counter-intuitive to the usual hype, rhetoric, or splash of a traditional marketing campaign. Work with actual developers both in house, and outside, to craft your messaging and deliverables. As the Metia blog post says, “The resources most highly valued by developers originated from product teams, including documentation, critical updates, SDK, sandbox, and test tools. The least valued — loyalty programs, vendor news, and product brochures — typically originate from marketing.”
Get developers what they need when they need it; use marketing tools to help deliver and manage your efforts but leave the fancy go-to-market plans for the end-user’s products.
Lately I’ve been asked a few questions about how to reach and connect with those developers who are so deep into writing and debugging their code, so dedicated to their own vision that they never ask for feedback once they’ve been tasked. Then, in the off chance late in the development stage they are asked to change direction, they either refuse, or become so difficult your job as product manager or program manager becomes a living hell. Sometimes, they even quit, which may be your worse case scenario.
To be frank, I’ve seen this happen many times on projects I’ve worked on, whether it be in product management, shepherding a specific program pre or post-launch, or just trying to help business development when they bring questions back to the engineering team. After many years working with software and hardware engineers, I’ve found three key ingredients are necessary to build a mutually beneficial bridge between engineer and customer. The first is empathy (for the engineers and their work), the second is trust and the third is respect. In fact, I have found them to cascade from one to the other. The second is actually a byproduct of the first, and if it continues in a productive manner, you are then able to build respect. Without their trust and respect, you won’t get very far with engineers.
Developing empathy, definitely a key soft skill, is easiest if the product or program manager has a keen sense of what needs to be done technically. Empathy is gained by focusing on mutual interests and a shared stake in the value of the work at hand, but is nurtured by listening, truly listening to the engineer first, and the customer second. I know this sounds paradoxical as the engineer is there to develop a product the company wants to sell, and the customer’s (or stakeholder’s) requirement should come first, but if you don’t listen to the developer and the vision they have of the problem, you may miss some important benefit that perhaps even the customer hasn’t thought of and marketers are not even aware of. In fact, so many of the products we use today that enthrall us did not come from customer requirements but from creative people with a vision and the means to achieve their vision (through strong engineering followed up by great marketing). By listening closely and asking engineers questions about the technology, their work, their challenges with the project and what they perceive as their value to the product’s end use, you will learn a lot and you will be on your way to establishing the empathy you need to gain their trust.
Likewise, sharing your own vision and institutional knowledge with the engineer also helps as they often feel isolated due to the sheer effort of their own contributions. Sometimes you will agree with an engineer, sometimes you will not. When you do, and you act as their champion to key stakeholders, you have then won their respect as well. Do it repeatedly and you will win their trust. Conversely, you can still win their trust and respect even if you (or upper management) do not agree with them after you’ve established empathy by providing honest feedback followed up by supporting them in any way feasible as they cope with the challenge of working on something they do not agree with, or do not wish to work on.
You may be thinking, “easier said than done” but every real world software and hardware project has trade-offs introduced by the stakeholders or the creatives peppered with the temperaments of those who deliver said products. Many years ago when I was an intern at Bell Labs in N.J., a wise person once said to me “where there is talent, there is temperament.” This truth has not changed in all my working years. Sometimes the higher the temperament, the greater the talent, but sometimes great talent is meek. Regardless, everyone working on a product or program should to be heard, understood and represented. This is both a product manager’s and a program manager’s role.
Not long ago, I had a fun lunch with a former colleague (we worked together at two different semiconductor companies over the last seven years). Over some nice tea at a Chinese restaurant in Sunnyvale, CA we started comparing semiconductor corporate culture as it relates to vehicles. My buddy was better informed than I as he had worked (but no longer does) at the three distinct and best known semiconductor companies in Silicon Valley, although two of them now mostly operate their businesses outside California.
The analogy goes something like this: one company is just plodding along soccer mom style, going from point A to point B, mini-van style, not giving up, occasionally winning, with no real sense of urgency, but a good sense of commitment. Another company acts like a race car, everyone moving as fast as they can to win the race, with their eye on the driver, the owner of said race car. The last company is best represented by a big Mack truck, joining the race later than the other two, but winning by plowing down the competition.
Needless to say, I had a laugh as I thought it was a a great analogy and a fun story. I’m sure you can figure out which company is which vehicle.
When I think about launching any new software “product” these days, be it for developers in the form of an SDK, consumers in the form of an app or application or enterprise in the form of a standalone executable or client/server application, I always first consider these three major “must-haves” or market requirements.
Every marketing plan for software (cloud based or otherwise) should include these three major tenets be fully addressed:
1) Platform: Platform coherency should be clearly defined
– Must be low friction for deployment and well documented for access (no excuses)
– Should be open source (if business feasible)
– Have a support ecosystem if the product encourages growing a user or developer community (aka: community forum, simple helpline email access, FAQ, newsletter, etc.)
2) Content: Content should always be included, even if the content is only code samples
– Content is what motivates adoption and sells the developer on using the platform
– Encourage user-generated content (especially if the primary goal of the application is UGC – think Snapchat and Instagram)
– Content can help you determine which distribution models may work best (the other way around is true as well).
– Content should help provide support for user acquisition, lead gen and more
3) Support: Support should be just as much business oriented as technical.
– Partner guidance (e.g., mobile platform advice, infrastructure tools such as Github, Bugzilla, etc.)
– Other possible synergistic partnerships (e.g., ecommerce tools, ecosystems apps and tools, support partners, etc.)
– May include co-marketing aids (if that makes sense for your product)
– Could be contract based and/or subscription based (or better yet, free!)
– If the product is technical in nature, such as an software development kit (SDK), expect to create developer forums, FAQs, and have someone on staff active in other internet channels where your developer customers may congregate.
I hope to write more about this soon, especially regarding content driving distribution choices.