My big ass report on developer relations and marketing

451 DeveloperRelations cover page

I’ve been working on a large (30 pages in lovely PDF) report on developer relations and marketing, especially, though not exclusively, targeted at people like cloud and service providers who are discovering the need to cater to developers. It’s published now. As with most of my work, I’ve tried to inject a bunch pragmatic, tactical advice alongside just enough macro “trends and drivers” nonsense to make the case for why you should care and then how you should start planning what to do next.

The report is available for 451 clients, but here’s the key findings which summarize the meat-y parts of the report:

  • Developers have played a large part in driving the success of companies like Microsoft and SAP, consumer websites like Facebook, and service providers like Amazon Web Services and DigitalOcean. These companies’ offerings can be traditional ISV software, SaaS,
    infrastructure delivered as a cloud service, or even “Internet of Things” devices.
  • While developers may emote a distaste for traditional marketing,they are actually very responsive to finely tuned developer relations and marketing programs. These programs revolve around understanding how developers fit into the offering’s strategies and plans, creating value propositions that appeal to the needs and desires of various types of developers, and ensuring that you “show up” to relevant developer communities.
  • There are many developer communities, both on the Web and in real life; most of them will be third-party sites that are not under your control. However, as developer relations programs grow, gaining more budget and resources, building your own developer community may be beneficial.
  • One of the strongest clusters of developer value propositions centers on speed and increasing productivity: getting software to production faster, ensuring very low barriers to entry to try out new technologies, and otherwise simply moving faster.
  • “Content” (text, video, audio, documentation, and even source code) is one of the primary mediums for interacting with developers, and, depending on the type of content, it has many different applications in developer relations programs.
  • There are many topics for content, but some of the more popular ones are educational materials about using your offering; “war stories” about how you solved a difficult problem; the story of how you made something (aka “sausage making”); commenting on industry trends and how your offering fits in; and case studies on how developers have used your offering. Documentation and source code are key types of content for developer relations programs.
  • Documentation is a particularly important type of content – both “manuals” and narrations or tutorials that are in a more natural voice. With rare exception, every developer relations program should look at documentation as a core type of content. Source code and the social networks associated with sites like GitHub are also an important type of content that most developer relations programs should have.
  • Conferences continue to be an effective engagement point for developer relations communities. They can range from large, vendor-centric events to small “unconferences.” Companies have reported to us that both types can be highly successful, depending on the tactics and conference.

You can always sign up for a trial to take being a client out for a spin.

Thanks!

Thanks to all the people who helped with it, esp. Claire Hunsaker and Barton George who were extremely generous with their time and suggestions, and of course my 451 colleagues who gave much input. The organizers of DevOpsDays Austin and SAP’s developer relations program staff we also very generous with their time and comments for the related case studies.

And, of course, I’m thankful for all that time I was lucky enough to spend at RedMonk pacing through the mechanics of getting non-developers to understand us nerds. If you haven’t read the seminal The New King Makers, go read that or much of this fancy PDF of mine will seem odd.

My big ass report on developer relations and marketing

“When have you crushed days into minutes for me lately, nerd?!”

Dennis reports on a refer SAP user group survey which points to difficult up-take for HANA. It seems like the primary blocker is coming up with justifiable reasons to buy and use the thing, a “business case,” as the kids say.

On the other hand, the actual performance of the thing seem to be real, if under-appreciated by those report hungry LoB-monsters:

BW on SAP HANA was always going to be an easy win given the time it takes to run reports. Crushing days into minutes and hours is a massive obvious win. What is less clear is whether those kinds of win turn into cash that can be released into other projects or process improvement. One problem I came across was that the massive speed improvements had put data analysts under incredible pressure as LOB started feeding them with many questions, not just the handful they’d been used to hefting.

I suppose that’ll be the result of Big Data installs over time: “when have you crushed days into minutes for me lately, nerd?!”

Here’s another take in the ASUG survey from Chris Kanaracus.

“When have you crushed days into minutes for me lately, nerd?!”

SAP cloud revenue to reach ~€20B by 2017

Hagemann-Snabe reckoned any change would hit the company’s revenue for 2015 but it would have reclaimed any losses by 2017, such is growth in demand.

He’s reported to have predicted cloud would lead to sales of more than 20bn Euro by that date.

Greater focus on cloud comes after SAP reported a five per cent drop in sales of its bread-and-butter on premises software business by five per cent to €975m ($1.3bn) in the third quarter, reported last month. Software and cloud subscriptions were up seven per cent to €1.16bn ($1.58bn).

SAP cloud revenue to reach ~€20B by 2017

One of SAP’s first SaaS attempts shifting around

While some reports had that SAP’s Business ByDesign was being slowly shut-down, the Enterprise Irregulars list pointed out a Tweet from Vishal Sikka that it was more of a transition, one that will ROCK no less.

Whatever the case, and perhaps this is all rumors as well, here’s a good chunk of info from the original piece in Wirtschaftswoche (I don’t read German, so I’m just going off the Reuters story):

The magazine reported, however, that the product, which cost roughly 3 billion euros to develop, currently has only 785 customers and is expected to generate no more than 23 million euros in sales this year.

I like keeping up with these early cloud build-outs – it’s good foder for figuring out how large, incumbent tech companies do with updating their portfolios. Back at RedMonk James covered ByD pretty closely, here’s a piece from 2009. It seems like a really good way to go down-market. As I recall, there was a lot of in-housing of the technologies, which has always been SAP’s, well, “thing.” And the fact that they’re moving it to HANA is more of that. NIH doesn’t portend failure at all: Google is rife with NIH, building its own platforms and such.

The bigger thing to pay attention to is (a.) enterprise software vendors need SaaS versions, or at least versions that will take advantage of private cloud technologies to ease management and cost control, and, (b.) making a SaaS that’s “enterprise grade” is hard.

One of SAP’s first SaaS attempts shifting around

The service runs in an HP managed cloud environment, as a managed virtual private cloud or a managed private cloud, within a regionalized, enterprise-class HP data center facility, the company said. It is powered by HP AppSystem for SAP HANA which is SAP certified, and allows customers to benefit from in-memory computing technology and process large quantities of data in the main memory of the server to provide quicker results from analysis and transactions.

in 2006, Mr. Plattner decided to shake things up. He took a bottle of red wine and sheet of paper into the garden behind his house. By the time he had reached the bottom of the bottle, he says, there wasn’t much written on the paper. But, he says, he reached the conclusion that in-memory systems were the future