I <3 APIs Masterclass: Building a Successful Developer Program

I am lucky enough to be spending this week in beautiful San Jose at Apigee's I <3 APIs conference. There have been a number of great insights shared, but few as valuable as the masterclass that I attended yesterday on building and marketing a successful developer program. Here were some of the points I found most valuable.

Jeff Hadfield, @jhadfield

 

  • Deloitte, API Trends 2015
  • Iot is a bunch of sensors talking to bunch of data in the cloud using both cloud and big data processing. Not just a wearable, not just your smart fridge.

How can we convince management that developers are important?

  • Software is eating the world “we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the industry.”
  • Hardware value increasingly in software. John Deere recently implemented a developer program. Why are tractor people having/using APIs? Sensors, etc, “precision farming”. IF TRACTORS CAN DO IT WE CAN TOO.
  • Uber as example: of all the spaces you thought would get disrupted, taxis probably wouldn’t have been it. 
  • APIs ties services, social media, data. Uber, for example, used a map via API, used available trackers on the iPhone, used APIs via square, hooked into existing social.
  • APIs drive purchases, consider>adopt>ops>add value.
  • The New Kingmakers, Stephen O’Grady
  • Apple’s App Effect

 

Exercise: Value proposition building

  • Every framework is flawed, but are they useful? 
  • Peter J Thompson: Value Proposition Canvas
  • Product: Benefits (why) + Features (how start here) = Experience (what?)
  • Customer: Wants (emotional) + Needs (rational) + Fears (hidden, deep whys)
     
  • EVERY ONE is different, best way to get to know your customers is to actually talk to them. Not trying to sell, just trying to ask.
    •     What does your usual day look like?
    •     What are your biggest challenges.
    •     What do you want to learn?
    •     What would make you a hero?
    •     What makes our API good and what would like to see made better?
    •     Why are some better than others?

 

Demographics—how to market/what motivates devs.

  • Stack Overflow 2015 survey
  • 84% of dev use open source software.
  • Developers trust things that they can see inside of. SHOW them as much as possible.
  • The hierarchy of developer motivations.
  • IBM research: developers want:
    • to solve a business problem
    • to solve a specific technical problem
    • to build existing or learn new skills
    • “fame and fortune.”
  • Computers are stupid, and that is why we have developers
  • The pragmatic programmer
  • Developer personalities: 1 in 40 people in the US is a software developer. 25% of people are INTJ, ISTJ, ENTJ, INFJ or INTP. 71% of devs are those types.
  • Please understand me: character, temperament and type.
  • Developers are “rationals”: represent only 5-10 percent of people, value intelligence, pragmatic, skeptical (need to think of all the things the stupid computer could do wrong), focused on problem solving, seek knowledge, prize technology, understand systems to make them work better. 
  • Break down of Myers-Briggs:
    • introvert (69% of devs, focus on the inner world, like to think about things, concepts. Do NOT want to talk through things with others) 
    • Intuitive (69% why things happen, long range implications, big picture, understand today and future)
    • Thinking (65% of devs, objective analytics, prefer to make their own decisions, logical)
    • Judging (77%, impatient with long descriptions, can make premature decisions just to be ‘done’, organized, structured, decisive)
  • Developers just want to find out where they need to go to do the things they want to do (action you want to take needs to be visible all the time)
  • Show benefits, let em touch it, let em test it out.
  • Developer relations is really just technical marketing. (we all like to buy, but no one likes to be sold to).
FullSizeRender-1.jpg

 

Developer Program Best Practices

  • Events and Community, Web site & Support, Marketing and Outreach, evangelism and strategic account management. 
  • Events and Community/Marketing: Standalone dev events are not as effective as they could be. Many choose to focus on one-to-one outreach. Local events, virtual events (webinars?), paid participation (showcase at apigee is a great example), owned events/hackathons (having our own event right out of the gate is never a great option). MVDP: participate in vertical events: speaking, exhibiting, content marketing, local events.
  • Online portal and content: MUST HAVE ONE. Used to drive engagement and inspire developers. Fundamentals: documentation, downloads, support. Balance between providing pre-purchase information and technical info. Involving engineers brings more people into the picture. Look at Twitter and Twilio,[ MSFT, SFDC, so much here] Facebook, Google. Make it clear where people need to start. What is the pain point? Advertise to that (features and benefits)—build them a path. Maybe sample apps for first stage of customers? Discussion community or links to external communities for discussion. If you’re going to have your own discussion board, you need to maintain impression of activity, or at least pay attention. Or, maybe you point them to a specific tag on stack overflow,
  • Tech support & evangelism: they should not be as different as they initially seem. Tech support should take place from early in the dev experience, during product, and not just later in the process. Closely align evangelism and support to make sure that there is excitement. Twill and Google both kill this here. You need to make sure that there is a content creator/community participation to see community.
  • Account management: if you get this customer, others will follow. Managed accounts are important. Microsoft, Intel, Apple. Task developer relationships team with care and feeding of strategic flagship, bellwether and other metaphorically signifiant partners.
  • Demand maturity determines strategy. When dev are drivers, you can rely on quality product, and scrappy tactics. When IT drives adoption, you must spend more money on that. 
  • Github, docker, very dev driven. MS, SFDC, IBM, SAP all very corporate it-driven/costly.
  • Evangelism is dev driven, marketing is corporate it driven.
“developer relations is a longer term customer attraction and retention strategy, not a metrics-driven, lead gen tactic.”
  • For a fledging developer relationships effort, a budget of 2m. a team of 2-3 is ideal. Budget is seed units, content development, travel, event budgets, advertising budgets and so forth. Team members, manager, director Vp), evangelist (marketer), tech team (api, sdk and web devs).
  • Developer relationships usually work with a direct report to sales for the most part.

More on marketing

  • Apigee’s developer program hierarchy of needs
  • Awareness can be complex—maybe they know it’s important, then you need to show them you are better.
  • Awareness: word; understanding: sentence; engagement: paragraph; adoption: buy it and keep reading.
  • Through your marketing funnel, you are increasing trust. You are decreasing reach, number of people you are talking to lessens. The need for touch/engagement increases. Dev influences increase. Search becomes less valuable all the way down to the bottom, and also only become applicable about halfway through.
  • It’s okay on twitter to retweet one billion times. Content reach is limited with our social efforts.

 

 

Michael Raslan, @eatabagel

Director of research at Evans Data Corporation - Understanding the development landscape for APIs

  • The only developer relations conference (in march) run by Evans Data
  • Why developers? They are the barometers or technological change
  • Largest pop of developers in APAC and EMEA. 2021, dev pop in APAC up by 50%
  • Def of developer: someone who works with apps and software development. Also people who have influence in the developer lifecycle (executives, management)
  • Consumer/commercial are one of largest segment at 28%, corporate apps are also 33% and are largest.
  • Back end, 28%, DB (25%), client/server apps (20%), business logic development, b2b/b2c.
  • Over half of developers are now spending at least half of their time on mobile development (APAC and NA)
  • EMEA less likely to focus on new technologies, effected by more conservative habits.
  • Iot dev expecting to at least double in the next 12 months.
  • Iot focus: office automation, industrial space, NOT wearables. Interesting.
  • 20% of devs list cloud as their dev environment. (also expected to double, like IoT)
  • 27% of dev involved in big data, increasing need to analyze information coming in.
  • External public cloud, mobile clients = largest security concern.
  • Is security about perception or actual compromises? This specifically has to deal with perceptions of vulnerabilities. Weak server side security and client injection are the two weakest security points.
  • 11.5 million working on publishing APIs or working at companies who have published APIs. 60 percent of dev pop. Almost *all* developers are using APIs. 
  • To grow your brands and your product adoption, you need to make UI offerings available to a larger audience (via APIs)
  • What business problems are dev trying to solve? No one size fits all understanding of what dev are doing—depends on industry and market habitation.

 

Bruce Jones

Hadfield Jones, technical field evangelism.

  • Questions that they often hear: how do we convince people internally, what should our strategy be? How do we do outreach.
  • Why do developer outreach? Who should represent the company in the field? When should he program start? How long will it take? What’s the outcome.
  • Early integrations, experimentation and partnerships get other people talking.
  • Sphero: 4 years of dev programs/other learning opportunities built into one awesome new product (bb-8 droid toy)
  • What other toy companies have open APIs? Furby, etc.

 

Michael Leppitsch

Global digital transformation services at apigee, Recruiting Partners

  • Enabling the digital value chain -> User (customer), Apps (product, but adaptive), Developer (also a customer), APIs (more product, but contextual/predictive), API team, Backend. (how do your assets become valuable to the developer ecosystem?)
  • Analytics, personalization, demographics all provided via API. Ability to differentiate.
  • A lot of your direct value comes from changing the processes that your customer is using to engage with you.
  • Audiences for APIs: APIs reach developers to create brand/awareness, reach partner’s developers for distribution/adoption, reach internal developers (employees) for process efficiency.
  • How to be sticky with partners: reduce friction (quick onboarding, self-service for APIs), improving connectedness. Increase openness (hackathons, dev events, participate in forums), increase creativity (don’t create rules and boundaries, potentially exciting/new technology/ideas?)
  • APIs reduce stranded investments, reduce risk in partnerships, and lower cost for all parties.
  • You’re able to “light up” partnerships more quickly, because you already have the APIs there to use.
  • New partners, current product offerings -> increased market share, and thus expand our market.
  • New product offerings, existing partners -> product innovation, and thus expand portfolio of products.
  • New product offerings, new partners -> new business models, and then create brand new markets.
  • Single channel (single place to buy), multi-channel (multiple places, not connected), omni-channel (multiple places, all connected)
  • Omni-channel -> careful between creepy, convenient, and compliant.

 

  • Best practices: 
    • Co-marketing. allocate a budget to work with partners to take value to market downstream (marketing money), feature on your digital properties (or vice versa), promote at events.
    • What does trust look like? What do you contractual obligations look like? Easier because APIs are not custom development efforts, APIs belong to us, what the partner builds on the API is theirs.
    • Design a EULA/leverage APIs to standardize partnerships. Manage partnerships at the edge with API policies.
    • Data has tremendous value, data shared with partners is more valuable than data is siloed. Approach data conversations with value creation in mind.

Matt Carter, @itsmattcarter

The Developer Marketing Game Plan

  • Forces us to feature the developer as a HUMAN.
  • Two core components of developer marketing: track progress of your audience, preferences and evolve to meet them. Track how you audience is progressing towards your objectives. Build, Measure, Learn framework (best stuff you can learn is what isn’t working). 
  • Tracking enables us to see what customers/developers are doing so that we can do it better (let them do it on their own). As you measure, you do a better job at meeting their needs. 
You want to do better by your customers, not build your own mini NSA.
  • Steps to buy-in:
    • Awareness(do they know they have a problem and there are solutions available and that you have a solution to offer them)
    • Understanding (do they understand your key value prop), engagement (Is there need great enough to want to try your API and see if it works for them)
    • Adoption (do you remove enough pain or provide enough gain to justify the effort of using your API?). Adoption is bottom of the funnel. Then, maybe, you can move them to advocacy, which broadens the funnel back out again. 
  • If we do not get people to understand “hey this is amazing, this is what you can build” they will not buy our product, they will go with a competitor.
  • Everything in developer journey is related to marketing automation—things change depending on what their behavior is.
  • Github.io. Nirvana is if customer issues a pull request.
  • Lots of tutorials and white papers, then they realized they had too much stuff. Wanted to create a more structured journey. developers.hortonworks.com
  • If you have a buddy and they are wanting to learn about our product, where do you send them first?
  • Key KPIS: Awareness (views, conversion, perception baseline), understanding (content consumption, convert to lead, baby steps to trial), engagement (first successfully pilot), adoption (usage and renewals), advocacy (holy grail—developer program participation [social media, hashtags], user groups, number of groups, participations, geographic distribution).
  • Test driven marketing: start with you outcomes, work backwards, simplify, prioritize, have your scorecard set: goals (I need 50 leads), KIPs (I want to improve my conversion rate), qualitative (I I want to be perceived as a market leader ahead ofmy competition).
  • Tactics for marketing is really important to connect to the end result. For example, why are you doing a hackathon? What is the end goal for your company. 
  • Paid, earned, owned, social. Owned is digital properties, like you sites. Earned: partnerships, syndication, paid: advertising. Social: social platforms.
    • Paid: (use sparingly, super targeted), launching a new product, support for a marketing “moment in time” competitive Judo, supporting your SEO strategy. Hypothesize, test, repeat, own your mistakes.
    • Earned media: search is everything—70% of web traffic comes from Google/others (developers looking for answers). Tips for success: basic site hygiene (title tags, attributes). get your team to tweet about you. Don’t gate your KB. Every landing page should be a beautiful home page, essentially.
    • Owned (your marketing annuity): website, developer network/program. Ask for likes and followers, listen and respond. LinkedIn, publish story and advertise. Get people accustomed to providing answers, and your community engagement will change drasticly. YES YES.
  • 9 dollar marketing stack