Guide: Cultivating trust in your developer ecosystem (Part 2)
Discover more from The Ecosystem – by Calyx Consulting
Guide: Cultivating trust in your developer ecosystem (Part 2)
A practical checklist for engaging developers and building trust for the long term
Part one of this series focused on the changes needed to build a developer-considerate internal culture.
In this post, we’ll share how to cultivate trust with your external community. Think of it as a developer engagement checklist for building trust.
Trust-building practices fall into two buckets: first, providing access to knowledge and people, and second, building relationships. Read on as we cover both.
Providing access to knowledge and people
Your early developer adopters have spent valuable effort and brain calories providing feedback, logging bugs, and even promoting your product to their networks. As a result, they may feel entitled (rightly so!) to certain access.
Access to: early peeks at your future product vision, features in early beta, your internal team’s knowledge and connections, and (in the case of developers building a business on your platform) your customers.
Here are a few ways to help these early developers feel heard and invested in your community.
Post your public roadmap
This is standard fare now, but at Slack, we were one of the first SaaS platforms to do this. People loved it.
At events, print out a human-sized version of your roadmap organized into short-, medium- and long-term items. Provide stickers for dot voting and sharpies for annotations. Staff the area with someone on your product, eng or devrel team to engage with attendees.
Besides being a valuable feedback mechanism for you, it’s a great conversation starter for attendees who might otherwise feel shy about approaching your team.
Make sure the important stuff can’t be missed
You need an API changelog, but make it obvious what developers must pay attention to (i.e. upcoming deprecations).
Want to really piss off your developers? Make changes to the way their product is discovered, understood or used and don't tell them. When you are making any significant change to app discovery or functionality, it needs to be (1) messaged early and (2) messaged clearly with an obvious path forward for affected developers.
Slack calls out important updates in red at the top of the changelog, while Stripe denotes backwards-incompatible changes with a “major” tag. Shopify has a filter to only show the updates that require action, and highlights them in red.
Offer both pull- and push-based updates
Changelogs are great for reasons (like RSS), but — as a mostly pull-based communication method — are not reliable. People aren’t checking a changelog twice a day, and updates are easily missed.
To address this, you should also send an opt-out developer newsletter, but keep it hyper-focused and avoid any sniff of marketing jargon.
Give early access to new features
Betas come in two broad flavors: closed, with a curated group, or open to anyone in your ecosystem. At a certain scale, you’ll need to do both.
1. Closed beta
One common challenge with early betas is actually getting the rich feedback you need to progress in your product development.
Deep and meaningful feedback only emerges from in-depth usage, not tire-kicking. And people are busy! Combat this by making your beta worth people’s time: offer co-marketing gives, or consider paying participants.
When your product is in high demand, developers will bang down the doors to get into a private beta. In this case, access to a private beta is a significant perk. Keep a waiting list and set expectations that deep feedback is a requirement for access.
Well-run betas take a lot of effort to manage. Remember, these participants are your partners, and you are managing the relationship for the long-term. Establish SLAs around communication, and make your expectations of participation clear at every milestone.
Staff your beta appropriately: it takes time to run a great beta, but it’s absolutely worth the investment.
2. Open beta
You want people to build with your product, but it’s not quite ready for prime-time. This tension means you must set clear expectations with developers around what “open beta” means.
I’ve seen “beta” be used to describe anything from “this is totally experimental and might get deprecated in three months” to “this is basically production-ready and won’t meaningfully change.”
Make it very clear, with `beta` tags and other obvious warnings on your documentation, what may change with regard to your product.
This enables developers to decide how much effort to invest and avoids bad surprises if the product does meaningfully change, causing extra work for them — the quickest way to lose trust.
Building face-to-face relationships
These practices broadly fit within the “community work” bucket.
Host a Developer Advisory Board
“Advisory board” sounds fancy, but it’s simply a way to forge personal relationships in a focused way with a rotating cast of community members.
These ~quarterly meetups are meant to:
1. Deliver meaningful feedback to your Product team, and
2. Deepen relationships with a selection of developers/customers/partners.
These events work best when they’re intimate, and focused more on conversation than presentation: think 8-15 external attendees and 4-6 members of your product and eng team.
Intentionally fill the room with people with vastly different opinions; sit the young startup founder next to the corporate developer from the large enterprise company.
Experiment with roundtables and different ways to make sure the loudest voice in the room doesn’t dominate the conversation.
Post-event, add each event cohort to a dedicated Slack or Discord channel as a persistent hub for them to keep in touch with each other and with you. Have PMs and engineers pop in periodically to solicit feedback or start a discussion.
Host office hours
When introducing a change that requires action from your ecosystem, offer multiple ways for people to access help according to their preferred learning style: video, webinar, documentation, etc.
Offering virtual office hours is an inexpensive way to scale your team to the furthest reaches of your developer ecosystem. Anyone can sign up to receive personalized support.
Help developers get usage
The reality is,
if developers aren’t seeing real usage of what they build, no amount of special swag will make up for it. Stickers are not a strategy.
For a platform with third-party apps, drive usage by making it simple for users in the product to discover them.
Tasteful in-product discovery of relevant apps will always beat “marketing” in terms of impact.
You can also get creative with marketing opportunities that benefit both end-users and developers. Some ideas:
Solicit and promote guest submissions on your developer blog
Feature relevant apps in emails, blogs and other content
Create intentional spaces at events for third-party developers and customers to organically mingle
Invite developers to speak at meetups and events
How do you engage your community? What has worked well? We’d love to hear from you.
—
Thank you to Ceci Stallsmith!