I have certain rules to make sure I don’t pull a Twitter.
Jeremy lives and loves all things API and platform. He was the first hire for Platform at Box, where he founded their Developer Relations team and created a community of over 15,000 partner developers. He’s been Head of Platform at both Tradeshift, where he led the design of Tradeshift’s new developer frameworks, documentation and developer tools, and Edmodo, where he grew the Edmodo App Store to over 500 applications. He’s currently a Product and Platform Strategy Consultant, Instructor at Product School, a mentor at Alchemist and Acceleprise, and an advisor to several software startups. We’re not sure if he actually sleeps, but he took some time to with us to talk about what he’s learned along the way…
OpenChannel: What metrics do you care most about for a developer community?
Jeremy Glassenberg: If I can bundle the metrics, I look at the overall funnel:
- Awareness (from outreach, other channels)
- Development (they’re working on an integration)
For each stage in the funnel, there are questions to ask and metrics to watch. In the awareness and registration stages, how many developers are registering for API access? For those coming to you, how are they finding you?
Just as CRM is used with customers, members of the developer community. When developers take interest in your platform and start hacking away on your APIs, if you’re not actively in touch with them, they will just fall off radar as they encounter challenges, and focus on other opportunities. You really have to keep a good communication line, and keep them excited about your platform throughout the process.
I’ve also seen many partners launch integrations and then walk away, moving onto the next thing. If they build a V1 or an MVP to test the waters, and no one is there to help them gather feedback and analyze results, they may lose focus on never build that next version.
So, I always prioritize direct communication and watch that funnel. If we see developer accounts registered from interesting companies, but we don’t see them touching our APIs, it doesn’t hurt to reach out and offer support.
OC: What causes the biggest improvement to that group of metrics?
Jeremy: The number one rule is communication. John Musser highlights this, in his top-ten list of how developers struggle when working with a new development platform. Surprising to many, the top pieces are communication, good documentation, and good support. That is something that I prioritize at every company I work with. No matter what the budget or marketing efforts, if you you’re not interacting personally with the developers, it’s not going to work.
Many companies wanted to replace traditional Business Development through a self serve developer portal, that partners will just work on their own. I haven’t seen that philosophy work well in the market. A platform should be self-service in principle, but in practice, communication is still vital.
Design everything so that they’re not supposed to need you, but don’t expect to be able leave your developer community to run on its own.
OC: How do you allocate time on your team?
Jeremy: When I was full-time on the ground as a Developer Advocate, I got into a bad habit of checking email first thing in the morning. So many articles show that successful people don’t do this, instead focusing on the biggest goal/challenge of the day, going to email later.
Then again, this is an external-facing role and when it comes to developer support, you have to be reactive. Over time, I’ve learned that developer support and developer outreach should actually be under different teams.
Team members for outreach and for support may have similar skills, but one role will be more reactive and volatile in the day-to-day. There could be certain weeks when you encounter an unexpected surge in developer inquires, and can easily lose track of outreach initiatives to proactively expand your developer community.
For developer outreach, if you’re really organized and you have that funnel figured out, you can take a look at the state of the funnel and it could be:
- What is the inbound today?
- What is the development status?
- Are there any projects at risk?
For Support, everywhere I’ve been, our goal was respond to a developer inquiry within 24 hours. If you’re not waking up and checking email, I’d say check the state of the funnel.
OC: What’s the hardest part of managing a developer community?
Jeremy: Now people are more aware of APIs, so if you reach out to developers you’re more likely to get a response. I think the greater challenge is that once you have a platform with an ecosystem, you’re going to have a lot of developers with a lot of questions.
I would say the biggest thing is time management and prioritization. The challenge is to maintain a brand of good communication, even though that means you’re spending a lot of time with developers who need more hand-holding. I won’t name names, but many platforms that were able to generate value, and awareness, translating to a large community of developers, lost their brand and community over time by lacking empathy for those developers, reflected both in product and communication.
Side note, you’ll find a set of developers who ask deeper questions. They also find the flaws or limitations in your APIs platform try to hack around them to come up with good solutions. Those are the partners you really want to find.
OC: What are the biggest mistakes you see other companies and community managers making?
Jeremy: In platform consulting, I guide companies to avoid common mistakes. I hope that in a couple of years, many platform consulting opportunities actually die out or evolve as many learnings in building successful ecosystems become common knowledge.
On the product side, I continue to warn companies against thinking “let’s just make it built by developers for developers”. They think the persona here is technical, so we should leave the APIs entirely to engineering. Engineering teams may have less of a process to interact with customers, be in businesses, consumers, or developers on your API.
However, they have APIs already built – internal APIs tied closely to the backend, and not at all tied to use cases for your developer community. The company slaps documentation on those APIs and open them to the public, then wonder why the platform doesn’t work. The issue here is that they didn’t really design their APIs properly, they didn’t treat it as a product problem. These APIs will be used by customers, just more technical customers, so you need to apply a proper product process to understand these developers and provide what they need.
Another common mistake is benchmarking what successful platforms are doing today and trying to copy them. I recommend Twilio and Stripe as having the best executed platforms and documentation. but they’ve both come very far. These companies are applying designs and tactics now that don’t fit well with a new platform.
I’ve seen companies launch developer forums right at the start of a new developer program, and wind up with an empty forum for a while. Developers perceive that as an unpopular platform and are discouraged from participating.
Similarly, I’ve seen large companies convinced that developer outreach is all about hosting big, costly booths at tech conferences because they have seen other big brands doing it. These booths help to generate awareness and can bring many developers into your funnel, but this is just one of many tactics needed. How many people are attending the conference and how many will actually see your booth and come by? What percentage of a developer community with hundreds of thousands of developers actually came through conferences? It’s surprisingly common to see large investments in the wrong areas and then wonder why their platform didn’t take off, it’s because they’re missing the little things that are actually far more effective.
OC: How will developer communities (tools, roles, etc) change over the next 5 years
Jeremy: When I started at Box, our documentation was in PBwiki. We had to manually set up how we were defining inputs, outputs, optional and required parameters and the formats of the outputs. Then Swagger came along, with others like RAML and API Blueprint, that make it easy to formally define how everything is going to work, not to mention generate good API documentation and many developer tools easily. I do think you can write better API libraries on your own, but it’s nice to be able to generate code samples right off the bat.
Additional frameworks have really fit in and changed the whole process of designing and implementing APIs. With Open Source Frameworks like Tyk coming along implementation becomes easier. When consulting I can now share a handful of tools to design your APIs, to document your APIs, to provide a good portal for developers, and to manage the APIs from the backend.
Marketplaces are an upcoming challenge, as the business and UX challenges are more complex. One can invest months building a marketplace, but without knowing the intricate need of both the consumers (buyers) and providers (suppliers). When not getting the expected results, they don’t really understand why and just get frustrated.
Combining better tools and processes for development of APIs and Developer Portals, I expect this to trickle into marketplaces as well. As with other aspects of a developer platform, there are little things that amazingly haven’t become commonly applied yet.
OC: What developer community do you really admire and why?
Jeremy: Twilio had it together across the board – API design, developer site design, and outreach/communication with their developers. Whenever I talked with the team, I could see that the process they used to design their APIs, interact with their customers, etc, all was well executed.
Now Twilio is a bigger more established company, so you can’t just look at what they are doing today if you’re starting off. They have so many tools now that they had to redesign. You have to look at their past and see how they transitioned. If you’re starting off it’s not the benchmark.
OC: What’s something about you that most people don’t know?
Jeremy: A long time ago I did some volunteer work for Mozilla, and I am actually unofficially titled “The Best Firefox Mascot.” They didn’t see it coming what I did, so there’s no video of it, just a photo….
OC: Have you ever had an unexpected negative reaction from a developer community? What caused it and how did you fix it?
Jeremy: I think through a combination of being a little careful, and also lucky, we didn’t have anything major. I have certain rules to make sure I don’t pull a Twitter. It’s okay to start conservative and then go liberal, rather than establishing and open platform and setting restrictions later, forcing existing partners to comply.
I once ran an apps marketplace with partners who were more difficult than usual. For a marketplace, we need to establish a quality standard of what we’re willing to promote to our users, and furthermore, need to be strict about security and privacy policies. We’d actually find partners getting very defensive when we couldn’t publish their app not only for significant usability reasons, for even when addressing security holes.
When your platform is a marketplace, you are a distribution channel for these companies. They depend on you for revenue, so your decisions that can really affect their revenue. You have to have high empathy for these partners, but also, you sometimes have to make decisions in the interest of the ecosystem, and in the interest of an individual partner. When you make such calls, actions still need to be taken in a responsible manner, and with understanding.
OC: If you only had one tactic, one tool and one hour to manage your community, what would you do?
Jeremy: Communicate. At bare minimum, have an email list and contact form. If your platform started as a side item but got popular, good communication will be difficult, but to maintain a brand you have to be responsive to the developers. Watch the inbound inquiry and respond fast. It’s difficult to be pro-active when overloaded with inquiries, but make sure you or someone else has the time evaluate the highest value opportunities for your platform. Decide what kind of partners will generate the most value, find them and reach out.
We want to thank Jeremy for his time and awesome insights! If you want to learn more or get in touch with Jeremy, you can check out his Linkedin profile.