The Ins and Outs of Building Braze Native MMS

The Braze customer engagement platform is built to be both naturally cross-channel and channel agnostic, allowing brands to reach their customers on the channels that speak to them in ways that support personalized, intuitive experiences. That means we’re always looking for opportunities to expand the mix of messaging channels that our platform supports. Because Braze is designed to support advanced capabilities like dynamic personalization and predictive analytics on every channel, we also have to be thoughtful about what we build and how we do it in order to ensure a scalable, effective product.

What happens when you combine that meticulous approach to channel expansion with the growing need to support increasingly rich, eye-catching messaging experiences? You get Braze native Multimedia Messaging Service (MMS), which we began supporting earlier this year. Let’s take a behind-the-scenes look at this key new channel and how the product and engineering organization worked to make it a reality for our customers.

Building Braze Native MMS: What the Process Looked Like

The launch of native support for SMS within our platform in 2019 opened up big new customer engagement opportunities for brands. Once SMS was part of our messaging mix, adding MMS seemed like a natural extension of this channel, allowing customers to take full advantage of both SMS and MMS not just for traditional transaction use cases, but also for engaging marketing campaigns.

Demand from current and prospective customers quickly inspired us to stand up support for this channel. Building out a feature like Braze native MMS is an iterative, multi-step process, requiring different stakeholders from around the organization to weigh in, share their insights, and assist with various phases. For us, this effort plays out as follows:

1. Assembling Your Team

Before you can kick off a project like building Braze native MMS, you need to put together a team. Because our product and engineering organization works in focused verticals, that meant pulling together SMS-focused representatives from our Product Management, Product Design, and Engineering teams to collaborate on the effort and identify other potential stakeholders, as appropriate. In this case, our team made a point of touching base 1–2 times per week beyond general team standups, in order to ensure that we were communicating regularly about how the project was evolving.

2. Carrying Out Discovery

Once we had our team in place, we began a robust research and discovery process, with the goal of answering the following questions:

• Is there a concrete customer need for this feature?
• What do other customer engagement platforms’ offerings look like when it comes to MMS?
• How can we seamlessly connect MMS to our existing native SMS channel?
• Ultimately, is it worth prioritizing this feature and—if so—how should we approach building it?

Our discovery process tends to be relatively standard across different product verticals. When we’re dealing with a new feature like MMS, that process involves internal conversations with go-to-market team members, customer interviews, competitive analysis, and more. The goal is always to identify assumptions and risks, gauge customer demand, and assess whether the proposed effort is both feasible and valuable for our customer base.

During the discovery phase for this project, we found MMS was coming up more and more often with potential customers, as well as with existing customers looking to send richer messages via text-message marketing. Our takeaway was that MMS was increasingly being seen as a core component of a text-message marketing strategy and reinforced the importance of finding a way to enrich our native SMS offering with MMS.

3. Scoping the Planned Feature

This part of the process—where we determine the must-haves for an upcoming feature—was pretty smooth in this instance. In large part, that was due to the fact that MMS operates in a very similar manner to SMS and we were able to rely on existing connections to our Braze Alloys technology partner Twilio to pass this additional layer of data. Overall, the main issues in front of us when scoping the feature were less about how we should support MMS and more about ensuring we got the details right. For instance:

• Are we clear on what configurations need to expand our SMS integration to support MMS?
• How is our existing billing around SMS usage by customers affected by the introduction of MMS?
• What will it take to get customers set up with MMS (e.g. enabling short codes, etc.)—and are there any steps we can take up front to minimize the work needed?

To reach alignment on how to answer these questions, we held discussions—both internal and external—about which MMS capabilities were needed and the impact our customer contracts allowed, from a billing perspective. Following these conversations, the Product team sat down with Engineering and Product Design to talk through how to build native MMS before they began to mock out the feature set. Once the design prototype was ready, we held a product kickoff where Engineering reviewed the design and required product set then provided guidance on what was achievable today, what couldn’t be done, and what needed to be modified for the project to move forward. In these kinds of meetings, the ultimate goal is to agree on what will be included in the minimum viable product (MVP) version of the product.

One of the big points of discussion in this instance was how many images could be included in MMS messages in the MVP version of the feature. Ideally, you’d be able to add any number of visuals to a text message. However, our research found that most customer use cases associated with MMS only required a single image to execute, suggesting that it made more sense to focus on launching an MVP that could support one image per message and then iterating from there.

This and other similar decisions made it possible for the initial release to go much faster, because it allowed us to rely on existing features and components like the Braze Media Library, which already allowed customers to upload and attach pictures and videos to messages in other channels. If we’d chosen to launch with multiple-image support, it would have required significantly more custom work and would likely have delayed our ability to offer native MMS support to our customers, making it a less compelling option from our perspective.

4. Building Out Native MMS

Building an MVP isn’t just about agreeing across teams on what needs to be included. Once we have that alignment, we go through a planning process where we identify the specific stages and steps needed to make the MVP a reality. Once we have this rough roadmap, we break the project into stages that can be accomplished one by one in a series of Agile sprints. In this case, the work that we had to parcel out included:

• Modifying our backend schema to allow for the attachment of a media message
• Adjusting our frontend to allow customers to upload media items for MMS
• Building in product controls to allow our Customer Success team to turn the feature on and off for customers
• Build in usage data collection features to support accurate, timely billing in connection with MMS usage

Our product and engineering organizations use Jira to support this kind of project management. During this phase of the project, we build out all of these different steps—and all of their dependent subtasks—as Agile “stories” within Jira; together, all those tickets form an “epic” that represents the creation of an MVP version of native MMS support within our platform.

In general, we worked to keep individual stories small enough to be handled in a single sprint, in order to allow for better testing and a more streamlined workflow. Some of the tasks were simple by nature—for instance, building in the product controls for Braze Customer Success Managers (CSMs) only took a few lines of code—but others were big enough that we had to find ways to subdivide them. For example, when we were working to build out the actual MMS composer within Braze, it required a decent amount of frontend and backend work. Similarly, the work involved in updating our backend to allow the attachment of media items was too large in scope to complete in a single sprint.

Building MMS Support: Key Challenges We Faced

While some software development efforts can be intense, complex, or involve significant struggles on the technical side, creating native MMS support within Braze ended up being a pretty low-drama project overall. That said, we did run into a couple challenges:

MMS Onboarding

While SMS and MMS are both types of text messaging, they’re technically distinct when it comes to sending outreach. In practice, the phone numbers that these brands send from have to be enabled for SMS or MMS, respectively, before the messages can be sent—which means that a brand with a long code or short code that’s only enabled to send text-based messages via SMS can’t use that send number to send visually rich MMS messages.

When we were building out support for native MMS, this meant that changes needed to be made to our SMS/MMS onboarding process. These efforts helped to ensure that brands looking to send MMS messages had the tools they needed to obtain the MMS-enabled short codes or long codes required to execute campaigns in this channel. To make that happen, we looped in our Integrations & Onboarding team and aligned with them on the needs and challenges when it came to leveraging MMS effectively.

File Type Support

With rich content, it’s important to be able to support media file types that most customers are likely to want to use when including visuals in their messages. But as with most aspects of building out a new feature, certainty around which file types to build support for can be hard to come by.

When we were building out MMS support, we used market research to determine that we should launch with file type support for GIFs, PNGs, and JPEG files. However, as we’ve monitored feedback since the launch, we’ve seen increasing calls for support for different file types—for instance, PDFs and calendar invite (ICS) files. That feedback then factors into our planning process for updates to native MMS support going forward.

Final Thoughts

While building native MMS support wasn’t the toughest or most mission-critical project our organization has undertaken, in some ways it’s one of the most revealing.

There is no “typical” feature creation here at Braze, but this kind of project may be as close as we get, since it is built on an existing product, required support and collaboration across the product and engineering organization (and beyond), and was consistently informed by our focus on Agile software development and iterative feedback loops for continual improvement.

To learn more about how we support SMS and MMS marketing efforts, check out our SMS/MMS documentation. Interested in becoming part of the Braze Product and Engineering team? Check out the open roles on our Careers page.