Revolutionizing Business Messaging: Building the First RCS Platform in the US

Picture this: It's early 2016, and the messaging world is about to be turned upside down. Rich Communication Services (RCS) is emerging as the next big thing in messaging, threatening to make traditional SMS/MMS obsolete. At 3Cinteractive, where we lived and breathed messaging services, we saw both a massive threat and an incredible opportunity. We needed to act fast to stay ahead of the curve.

A close up of a cell phone with a keyboard
A close up of a cell phone with a keyboard
The Challenge
Getting Our Hands Dirty

The timing couldn't have been better. GSMA had just launched the RCS Universal Profile, and we were fortunate enough to be part of the working group establishing these standards. As the product manager, I jumped in to lead this greenfield project that would reshape how businesses communicate with their customers.

gray concrete building during daytime

The Fun (and Not-So-Fun) Parts

On December 3, 1992, Neil Papworth, a 22-year old software engineer at Sema Group Telecoms sent the first text message, or SMS (Short Message Service). It simply read “Merry Christmas”.

Fifteen years later, Rich communication Services (RCS) was created by a group of industry promoters, including telecommunication carriers and device makers.The basic concept was to improve SMS and MMS messaging with features from popular internet-based messaging apps.

The next year, GSM Association (GSMA) officially adopted RCS and published the initial specifications with a simplified version 3 years later. In 2016, GSMA launched the RCS Universal Profile, a standardized version of RCS that works across different mobile networks and devices. 3Cinteractive was honored to be part of the working group that built the standard and began working on that as it was being finalized.

This is where I come into the picture as the product manager responsible for additional integrations and building an orchestration platform. As you can imagine with any emerging technology, API contracts and specifications were fluid and open to interpretation making life interesting as we integrated with RCS gateway providers like Google, Samsung, Mavenir, and others. Additionally, telecommunication companies were also trying to ramp up their support of RCS, each having their own flavor and twist to the recipe.

I worked closely with our Chief Architect to theorize the best way to approach the integrations and connections to the carriers. From there, I wrote the Product Requirements Documents (PRD) for building abstraction layers for the RCS hubs and the telecommunication platforms allowing us to standardize the UI/UX for the upcoming orchestration system.

As the team built the integrations, I went to work with our sales team, solutions engineers, and client managers to interview clients about their needs and desires. I combined the findings with detailed and in-depth analysis of other workflow web applications ranging from SMS to marketing automation to ERP to derive the best-in-class user experience (UX) for the new app.

After building a few wireframes and low fidelity prototypes, I put it in front of the users for their input. I worked with engineering and design to see what was possible, prioritized the proposed changes, and repeated the process a few more times. The timing worked out well as we were wrapping up the integrations and finalizing the hiring of additional staff to support the product.

We had the core RCS team in place. The major feature concepts were identified. Next, we pulled together a group and participated in a User Story Mapping session which resulted in the framework for the entire platform. By the end of the week, the PRD was updated, design was finalized, and I had created the epics, features, and user stories with acceptance criteria.

I led multiple scrum teams that totaled between 15-20 QA, front-end and back-end engineers that would take on this massive task with a deadline of the next major industry event, Mobile World Congress in Barcelona. I’d love to tell you everything went smoothly, but it didn’t.

We had to fire and hire contractors because of quality and speed concerns. API changes were being released with contract changes that weren’t communicated. Carriers were still working on their own systems and weren’t ready when we were ready to connect to them. I was still managing other product lines that pulled my attention away that led to some delays. Some of our developers had legacy knowledge of our other products and were pulled to resolve issues with them. The list goes on as I’m sure you can imagine.

That didn’t stop us and rarely slowed us down too much. The team was dedicated, in part, to finding the right people, the company’s full support of the endeavor, and the leadership and inspiration of the Scrum Master and myself.

Since this was a 0-1 / greenfield project, we were fortunate to avoid fire drills like critical issues in production. That came later. The QA team was led by a brilliant engineer who stayed on the cutting edge and taught the QA contractors QA automation which greatly reduced manual testing and sped up development. This resulted in very few bugs going to production when the product was released and allowed the engineers to focus on new features/functionality.

The team succeeded in hitting the deadline and we demoed the platform on time where attendees could build their own messaging interaction flows and experience RCS first-hand at the trade show. It was a tremendous success and generated a lot of buzz across businesses and carriers.

people gathered outside buildings and vehicles

The Plot Twist: Japan

Japan was the first “gold standard” country in the world. This meant that all their major carriers supported RCS and talks between us and the Big 3 - NTT Docomo, Softbank, and KDDI - began resulting in 2 of the 3 signing deals with our platform. NTT Docomo and KDDI wanted us to supply them with a white-label version of our RCS Engagement platform for their business clients to use.

One major problem arose. We had the foresight to utilize an external file for all the labels and text within the UI. This made it easy for us to switch between English and other languages like Spanish or German. We did not take Japanese into account. Kanji was very different from Western languages. The current platform accounted for a 33% increase in length of characters and Kanji didn’t always fall within those limits.


This meant it was time to go back to the drawing board with the design team and build a more flexible layout that would work for the Japanese people. We worked with the carriers on new design concepts until we were in alignment and began work. There were several architecture concerns the Japanese carriers had due to their culture that we needed to adjust for. I met with them 2-3 times a week to discuss progress, status, and change requests.

Once we had an agreed deliverable, it was time for me to travel to Japan where I delivered multiple training sessions with each carrier and provided them with the materials for their sales enablement and marketing teams.

The Victory Lap

  • The first business A2P (application to person) RCS message delivered in the U.S.

  • The first platform to send RCS messages to 11 countries across 3 continents.

  • The first platform to be white-labeled.

  • The first platform to be used by 2 of the 3 largest telecommunication companies in Japan (the first gold standard country for RCS).

  • The first RCS marketing winner of the Mobile Marketing Awards (presented in England).

  • Generated new sales over $2million/year and over 50 new clients like Walgreens, Best Buy and FC Barcelona as the product manager/owner for the CPaaS application platform with an entrepreneurial mindset.

gray concrete building during daytime

Summary

Building Something People Would Actually Want to Use

Instead of just guessing what our users needed, I:

  • Dove deep into client interviews alongside our sales and solutions teams

  • Studied everything from SMS platforms to ERPs to nail the user experience

  • Created prototypes and actually put them in front of real users (shocking, I know!)

  • Ran multiple iterations based on user feedback (because who gets it right the first time?)

Managing the Chaos

Leading 15-20 engineers across multiple scrum teams, we faced every challenge in the book:

  • Contractor issues? Check.

  • Surprise API changes? Absolutely.

  • Carriers not being ready? Of course!

  • Getting pulled into other projects? You bet.

The Secret Sauce

Looking back, our success came down to a few key ingredients:

  • Building the right team and fostering a culture of innovation

  • Staying flexible and adapting to changes (there were many!)

  • Keeping users at the center of every decision

  • Not being afraid to go back to the drawing board when needed

This project wasn't just about building a platform – it was about positioning ourselves at the forefront of a messaging revolution. And spoiler alert: we nailed it.