I started my career at Google as the founding developer relations team member for a new product called RCS Business Messaging or more commonly referred to as RBM. I was new to Google, new to developer relations, and tasked with figuring out the developer go-to-market and what developer relations and developer experience should mean for this unknown product.
This article details how I approached this problem and the tactics I used to create and grow the community, keep it engaged, and even, make it thrive.
Joining Google developer relations
In February 2018, I joined Google as part of the Assistant Developer Relations team. While most of the team worked on growing engagement for Actions on Google, I was the odd person out, as I was the lone advocate working on RBM. RBM was a new platform that let developers build conversational applications over a carrier-based protocol called Rich Communications Services (RCS). This is the carrier standards-based upgrade to SMS. RCS supports similar features to what you’d expect any modern mobile chat platform to support; typing indicators, read receipts, high quality images and videos, and group chat.
The RBM platform abstracts away the complexity of RCS by providing a REST API that developers can use to send rich forms of communication from a business to a user. When combined with NLP tools like Dialogflow, a business could create a rich conversational experience sent directly to a consumer’s default messaging application on their phone.
While both the Assistant and RBM are conversational platforms, there really wasn’t a natural alignment between Assistant voice developers and the RBM audience. RCS is not available on every mobile device, so typically any business wanting to utilize the platform would need to use SMS as a fallback for non-supported devices. Additionally, RBM was aimed at replacing outbound business to consumer SMS, therefore the most natural audience were developers already working in the SMS marketing and aggregator space.
Since there wasn’t much overlap between Assistant developers and the target audience for RBM, I couldn’t really leverage the existing community my colleagues had helped create. Additionally, Google has many tools at its’ disposal to reach a very wide developer audience; conferences like Google I/O, Cloud Next, Google Developer Days, as well as hugely popular developer blogs and YouTube channels, but none of these were a natural fit either.
RBM isn’t a programming language, framework, or widely applicable Cloud infrastructure that any developer in the world would care about. It’s not something where live streaming my coding session on Twitch would make sense. The audience I needed to reach was much more specialized and fragmented.
So, this was my problem space. The questions I was wrestling with on a daily basis were: How do I learn about this developer? Who are they? and How do I make them successful with RBM?
Start with the users
I approached the problem of “what is developer relations for RBM?” like you would most product problems, start with the users. I applied a user-centered design approach to defining and understanding the problem space.
When I joined Google, RBM was already in beta and had a handful of businesses from the SMS space exploring and actively developing on the platform. The product had been announced at Mobile World Congress (MWC), so there was some existing industry buzz. Additionally, Google’s a big name, so although the existing developer channels might not be a perfect fit for this product, the Google brand carries with it a lot of advantages when it comes to creating industry interest.
Through leveraging existing Google business relationships and because of the announcement at MWC, we had some existing developers for the beta and that’s where I started. My first order of business was to put myself in the shoes of our developers and figure out what was the developer experience today?
Friction logging
For the beta launch, there had already been some documentation created by an amazingly awesome technical writer named Manny Silva that contained an API reference, a guide for getting started, a simple example application, and some additional guides for the base set of functionality. I went through the end to end getting started guide cataloguing the journey using a technique called friction logging.
A friction log is a tool to capture the end to end developer experience through a developer journey. The goal is to be as detailed as possible, highlighting parts of the journey that are delightful, confusing, or downright problematic.
I went through the initial RBM onboarding experience, exactly adhering to the documentation and logging bugs and making notes for improvements as needed. This gave me a good sense for what the onboarding process was like today. I was also able to work with Manny to make improvements to the existing documentation. Small things like improving instructional clarity and adding a relevant image when applicable.
Thematic bug analysis
Based on my friction logging exercise, I recognized that the getting started and launch process for RBM took a long time and was a potential problem area. However, I wanted to really understand how big a problem this was. To do this, I went through all the bugs that had been filed by developers since the beta launch and grouped them into common themes.
There were hundreds of bugs, but I read through every ticket. This helped me identify the common pain points and I found that my hunch was correct. The most common issues related to onboarding and configuration. In the early days, there were a lot of steps to get up and running with RBM. For example, to test an RBM experience, a developed needs an RCS-enabled device. Back in 2018, this wasn’t super common and although we had a process for enabling any Android device, it led to a lot of confusion and additional setup, preventing developers from progressing with the API.
Talking to developers
Digging through bugs and documentation is valuable, but nothing beats actually talking to real users. I worked with my cross-functional colleagues to identify an initial batch of registered companies to talk to and then set up informal meet and greets.
My goal was to introduce myself, my role, and try to understand what their company does, what their interest in RBM was, and if they had built anything, what hurdles did they encounter.
Above all else, developer relations is about building real authentic relationships with a community and this was my opportunity to start that process. I wanted people to walk away from these meetings feeling heard and knowing that I was a resource available to help them be successful.
Becoming an expert
During all this information gathering, I was also building up my expertise on RBM. I needed to become an expert if I was going to be respected by both internal and external stakeholders. To do this, I started by building as many product demos as I could think of. There was also no client libraries available, so I polled the registered beta users to find out what languages they were working in and came up with a stack rank of programming languages we should support. Then I created client libraries for the 5 most popular languages.
Additionally, I started jumping in and answering support tickets. We had a dedicated support team, but I saw helping out in this capacity as a good way to learn the product, the sticky situations someone might get into, and continue to build relationships with the community.
Focusing on Developer Experience
Developers were struggling to onboard and start working with the product.
This friction was hurting adoption and developer satisfaction. It was clear from my conversations with developers, exploration of tickets, and my own personal experience, we needed to improve our developer tooling.
The main issue was all the steps to register with the platform, create a business identity, and launch that business on RBM at that time were manual and required a human-in-the-loop on the Google-side to execute things in the background. So even for a highly motivated developer, registration meant a full stop while they waited to hear back from us. Same with registering a business and launching that business. These full stops meant our time to first message was multiple days. It also meant it was nearly impossible for an engaged company to scale.
I decided that focusing on solving this problem was the most high value contribution I could make.
Designing a developer console
What we needed was an API (for scale) and a console (for simplicity) to automate and speed up the getting started journey. Given RBM was still in beta, I didn’t feel like most companies were ready to invest heavily with an API integration, so I began by focusing on creating a developer console.
To start, I explored other consoles at Google like the Assistant, Dialogflow, and Google Cloud and met with the engineering and product leads from different teams to learn about their motivations for creating a console and the lessons they learned. As I started to think through the product requirements, I thought the best way to convey my vision and get buy-in from the engineering team I worked with was to create a mock console.
Using Node.js, I created an interactive demo console styled like other Google consoles. Once I showed this to the product and engineering leads, they were immediately excited about the potential of this product. I can’t understate the value of a well timed demo. Just as a great demo can inspire action from external developers, a demo is also a fantastic tool for building alignment and momentum for internal projects.
Once I had leadership buy-in, we had to find resources. The product lead was swamped, so I was asked to take the lead as a product manager for this project while the engineering lead worked to hire and build a web team.
As we started to hit important milestones with this project, I worked to bring in community members early for feedback with presentations and demos. These conversations were invaluable as they helped us identify missing features and blockers that we could fix before launch. It also helped to create community excitement about what we were building. Additionally, bringing the community into the product creation process is a powerful tool for building relationships. They feel heard and see the direct impact of their feedback.
After nearly a year of development and running an early access program, we launched the product to the developer community. There was an overwhelmingly positive reaction and although I can’t reveal numbers here, the growth of RBM within the first month dramatically eclipsed anything we had accomplished since the beta launch.
The business impact that I was able to demonstrate directly tied to making investments into dramatically improving the developer experience led to continued feature bets in this area. The RBM Developer Console grew into the Business Communications Developer Console, eventually supporting four different products. I had also proved myself as a product lead and expert in developer experience, and I’ve continued to have opportunities to take leadership roles to improve the developer experience across all our products.
Other community investments
While the console was in development, I kicked off a number of other community growth and engagement programs. One of the most impactful tools was office hours.
Office hours
Fairly early into my time at Google, I started hosting weekly office hours for all companies in our community. These sessions featured myself and other outward facing cross functional Google team members where we’d present product updates, events and workshops we’d be attending, and answer live questions AMA style.
I’ve continued to run these sessions for nearly four years now and I’m still blown away by the community engagement and attendance. We have hundreds of people show up week after week to participate in these sessions. It’s an amazing opportunity for us to put a face to the product, teach and reinforce best practices, hear feedback, and help unblock community members with issues.
We also use these session to poll the audience about feature prioritizations, product investments they are making, and recruit participation in our events and workshops.
Demos to inspire action
In the early days of RBM, we had a real market educational challenge ahead of us. RBM represented a paradigm shift in what was possible with carrier-based messaging. Instead of text-only, purely outbound messaging, business’s could suddenly create and support completely new interactive and complex customer user journeys. Developers in the SMS aggregator space needed to be educated about the capabilities of RBM and the basics of conversational design and brands needed to learn about the channel and understand the potential ROI for their business.
I spent a lot of time coding, building demos, and samples based around different user journeys the platform enabled. I would adapt these demos on the fly to make them brand-specific to help the business development team pitch a new prospect using a custom built demo relevant to the company they were pitching. It’s one thing to see static images on slides, it’s another thing to see your logo in a real application of a new technology interacting with a user.
I created futuristic demos, combining augmented reality with RBM. I stood on stage at events around the world and placed furniture on the stage with me all from a conversation with a fictitious retailer.
These types of demos helped demonstrate the RBM wasn’t just SMS with more characters, but that it was a fundamental shift in how companies could do business.
Hands-on events
Another tactic I used to try to overcome the educational barrier to entry was to run a lot of hands-on events. When we launched RBM into new markets, I’d coordinate a hands-on training event for developers where they’d spend time with me building RBM experiences. We typically saw significant pops of engagement from businesses in these countries post event.
One of the most rewarding events I organized was a two day bootcamp at the Google Mountain View campus. I invited developers from all over the world interested in RBM to come to Google.
We had 100 engineers from as far away as South Africa travel to California for this event. They spent two days learning everything from sending the most basic message to doing AI-powered conversations on the platform. We finished the second day with a half day hackathon where teams put together amazing demos in just a few hours.
Outcomes
The RBM community continues to grow and the messaging volume has exploded since the very early launch days. We’ve been able to leverage the RBM community to help kick off and create early engagement for other business communication product bets like Business Messages.
Just like any product or community effort, there have been a lot of people involved. I told this story from my perspective, but it’s really been a combination of cross functional team effort that has helped this product grow.
TAKEAWAYS
Building a successful developer community has to start with the user. You need to understand who your audience is, how to reach them, and how to make them successful before you can apply specific tactics. Any new community effort should begin by defining the audience and then the strategy.
Once you’re ready to apply tactics, experimentation and measurement is critical. I’ve told the Cliff Notes version of growing the RBM community, but there were plenty of things I tried that were not successful. That’s ok, those are learning opportunities. Growing a developer community is always a unique problem, the same strategy and tactics that worked for one product don’t automatically work for another. You need to experiment, test, and iterate to find the right special sauce to grow your community and help them thrive.
I hope this long post was helpful, thanks for reading, and please let me know in the comments what you thought. Also, if you’re from the developer relations world, share your ideas about growing a thriving community.
