Postmark Message Streams: How It Started vs. How It’s Going

A few weeks ago we released one of the biggest features and product changes in the history of Postmark. Here’s the thing: very few people noticed. And yet I consider it one of the most successful releases we’ve ever done.

In this post, I’d like to outline the 22-month journey that got us to the point where Message Streams are now available to all Postmark customers—which means that you can send all your email (both transactional and bulk) via Postmark. This is usually where I’d say something like “come along for a wild ride” to entice you to keep reading, but that wouldn’t be a truthful statement. All I have is this: I invite you to come along for a slow, steady ride. No need to strap in.

How it started #

Since Postmark’s inception in 2009, we have proudly been a provider for transactional email only. We spent years building our brand positioning around the concept that we are the email service provider you choose to get your mission-critical email to the inbox lightning-fast. We introduced the concept of Time-to-Inbox (TTI) and exposed our delivery times on our status page. It is what we became known for, and what we are great at.

Nearly ten years later we asked ourselves a question:

What if we took everything we’ve learned over the years about sending transactional email, and use that knowledge to build a better, more reliable way to send non-transactional, bulk email?

This idea immediately got us excited. Over the years we heard over and over from our customers that they wished we support bulk email, for two main reasons:

• They love our product and want to use it to send all their application email.
• They don’t like having to use separate providers for bulk and transactional mail.

Up to that point we had always resisted this call and stood strong on our core promise: getting your transactional email to the inbox as fast as possible. We know that sending bulk and transactional email over the same IP address pools inevitably introduces delivery issues since they have such different properties. Bulk email has much lower engagement rates, which can make inbox placement difficult. Further, inbox providers often slow down huge bulk sends, and you don’t want your transactional email to be inadvertently caught up in that and get delayed.

So we asked ourselves not just how can we do bulk email, but how can we do it differently? Do it better? We took this question to our team during our annual planning, and together they came up with the concept we now call Message Streams. In short, Message Streams allow us to separate transactional email from bulk email (what we call Broadcast email), so that we optimize for what’s important for each of those very different types of email. With transactional email we (still) optimize for Time-to-Inbox. With broadcast email we optimize for reliability—dependably getting your emails to the inbox, without worrying too much about how long it takes.

We officially started working on adding Broadcast sending to Postmark in January 2019. We didn’t have enough information to know how long the project would take, but we had a rough goal of being in a public Beta sometime during the year. We started planning the various phases and features, realizing that many gaps existed that we’d need to figure out along the way.

How we approach product development at Postmark #

It’s at this point where I need to take a bit of a detour to talk about Postmark’s superpower when it comes to product development. Here it is:

We make our own timelines, and then we prioritize doing the right thing over hitting those timelines.

Timelines are our guardrails—a way to keep momentum and motivate ourselves. But if something takes longer than expected, or we need to change scope to make the product better based on customer feedback, there is not even a debate internally. We just do it.

Here’s one of many examples. Early in the design phase of Message Streams, we decided not to add front-end marketing features like a WYSIWYG editor or list management to the product.

But in our early discussions with customers we realized that even though everyone preferred this approach, there was one part of list management that would be a dealbreaker: managing unsubscribes. And our initial designs required customers to manage their own unsubscribe process. After getting feedback we realized that’s just not going to work for most companies. So, we adjusted the scope of the project. We still didn’t add full list management for uploading CSV files, etc. but we realized we needed to build an unsubscribe process for customers, as well as an API to manage all “suppressed” emails. Did this mean we needed more time? It certainly did. But it also added value and removed a major hurdle for customers. No-brainer.

Collecting customer feedback early and often #

In May 2019 we felt ready to start getting some feedback on our planned approach. We absolutely didn’t want to work on this project for a year (or more) before customers could see it and react to it. So Anna, our head of deliverability, posted publicly about our expansion into bulk for the first time, and we opened up Broadcast sending to a limited number of invite-only customers. At this point we hadn’t implemented Message Streams yet, so there was nothing in the UI to use. We asked customers to create a separate server in their account, which we then hooked up to our bulk IPs, and asked customers to use the feature that way. This was our first time observing how we would handle Broadcast sending in the wild, and the feedback from customers proved invaluable. This process allowed us to refine what will be needed in the UI, how an unsubscribe process should work, and finalize our Message Streams concept.

And so the year went. Every month or so we would release a small piece of the backend and frontend puzzles, see how it worked, and what we needed to change. In September 2019 we added Message Streams to the UI, but again, the feature wasn’t even close to being done. At that point you couldn’t even create a custom Message Stream! It was just a way to start showing customers how the UI will change, and get them used to the new paradigm. As we rolled into 2020, we added the Suppressions UI and API as part of the planned unsubscribe process, as well as webhook management APIs to support Message Streams. We also re-worked and extended most of our other APIs to support stream-level detail. We were able to do all this work in a way that didn’t require a single update to customers’ existing integrations—a huge win for them as well as for us.

Then, well… 2020 happened.

How it’s going #

As the global pandemic hit and everything ground to a halt everywhere, we had to take a hard look at our roadmap, how we could best support our team, and what we could realistically accomplish. I’m not going to rehash that process, since Chris, our CTO, put it really well in his launch post for People-First Jobs:

The world is different right now, and yet, businesses are somehow expected to operate the same as they have in the past. There’s both spoken and unspoken pressure to return to “business as usual,” especially if you were already a remote team. Simply picking up where you left off leaves many unanswered questions. Chief among them: Is it appropriate to launch a new feature or product right now?

With multiple projects planned for an April release, we’ve grappled with this question. The answer has generally been an easy “no.” With so much stress, uncertainty, and overwhelming information in everyday life, launching just doesn’t feel right, especially if it’s gratuitously feeding off the crisis. For now, those projects will stay quiet, and we’ll open them up when it makes sense.

We shifted away from Message Streams for a few months while we focused on some important infrastructure updates, while also working on People-First Jobs. Eventually, it was time to get back to it, and we set ourselves a new goal: to go live with Message Streams for all customers by the end of the year. But for that to happen, we still had one major roadblock to overcome. How do we convince people to trust us with their Broadcast email after so many years of building trust based on the idea that we only send transactional email?

Addressing the positioning dilemma #

Early in our discussions with customers, we kept running into an issue. We have, for so long, told customers that our focus on sending transactional email is a good thing. The fact that we are now asking them to trust us with bulk email without any impact on the delivery of their transactional email was met with some understandable skepticism. When we eventually figured out—through trial and error—the best way to talk about this, we could not only provide customers with the comfort level they needed, we also stepped into a huge product differentiator.

Most email providers send transactional and broadcast email over the same infrastructure—including the same IP ranges. From the beginning, we decided on a different approach. We knew we needed dedicated infrastructure for each type of email in order to optimize for what’s most important based on what our customers are sending. But it wasn’t until Jordan produced the video below that everything fell into place for our messaging and positioning.

The “don’t mix your recycling with your trash” line resonated with our customers, and it felt like finding a lost puzzle piece under the table somewhere. We always knew it was there, we just weren’t quite sure what it looked like.

Rolling out Message Streams—step-by-step #

With Message Streams around 90% feature complete and our infrastructure in place, we took our first big step this September. We turned Message Streams on for all new Postmark customers by default. We also started removing references to transactional email from our website. Although we didn’t see lots of immediate adoption, we also didn’t see any complaints or concerns about our move away from being a transactional-only provider. So, in the spirit of “no news is good news”, on October 12th we turned Message Streams on for all customers. Our internal celebration was huge. This was the culmination of almost 2 years of our lives, and it felt so good to flip that switch. And then we waited. Nothing happened. Which is exactly what we expected, and wanted.

We didn’t want to make a huge deal about the release, because we didn’t want to suddenly get overwhelmed by bulk sends while the feature was still so young. We knew from our data—from watching adoption and trends for months—that it takes a little time for our customers to discover and move their broadcast sends over to us. That is what gave us the confidence to finally turn it all on.

After a few days, we took the next step: we started reaching out to individual accounts to let them know about the feature and offer them help with getting started. It has been amazing to see the feature grow in a controlled way and to see the overwhelmingly positive feedback as customers get ramped up.

So that is where we are today: we are continuing our gradual roll-out, while implementing some automated emails to help customers get started if they set up a Broadcast stream but don’t start sending within two weeks. (By the way, if you haven’t given Message Streams a try, right now is an excellent time to do it! You can sign up for some tips and recommendations here.)

What we learned #

This is the part where I want to talk about why I am so grateful and excited about this release, and why I think it went so well. The short version is simply this: we took our time. The longer version is that by releasing small pieces of the feature every couple of months, gathering customer feedback, and not rushing ahead to meet arbitrary deadlines, we are now in a position where Broadcast sending is in an active growth phase as more people discover a feature that meets their needs perfectly. Taking our time allowed us to do so many things that we wouldn’t have been able to do if we were driven by other metrics, but here’s a list of what I consider the most important:

• We could adjust the scope and required feature set as we started to see real-world usage.
• We could test our messaging and positioning in the real world, and make changes before we needed to commit to a specific approach.
• We could have tons of help docs ready on Day 1 of wide availability since our support team already knew what customers’ most important questions about the feature would be.

So much of the discussion around modern product management revolves around the value of small, incremental releases, not planning ahead too far, and not taking on giant projects that don’t have a clear end in sight. This was our challenge with Message Streams. We knew it would be a long project that is impossible to define or estimate accurately in the beginning phases, and that kind of thing is generally frowned upon by modern product leaders and coaches. But we found a way.

Doing partial releases every few months—incomplete as they were—and getting feedback from our Beta customers early and often meant that we could build momentum, adjust our assumptions based on real-world feedback, and eventually complete a giant project with very little risk to our business or infrastructure. I can’t wait to do it again in 2021.