Courier is the best way to design and deliver notifications for products. Courier lets customers customize their notifications in a visual design environment, and then deliver them through any channel using a single API.

Courier was part of Y Combinator's Summer 2019 batch. They are growing fast—currently the team is 10 people based out of their HQ in San Francisco, primarily composed of engineers at this point.

Troy Goode is the founder and CEO at Courier. I recently had the opportunity to sit with him and understand why they're betting the future of their company by prioritizing their smallest customers.

Tell us about how Courier got started.

I led engineering for a company called Eloqua, which is one of the leaders in the marketing automation space. We took that public and sold it to Oracle back in 2012. At Eloqua, we built out tools that allowed marketing teams to design and send out emails using a drag and drop environment. And following my experience at Eloqua, I became routinely frustrated by the fact that for the transactional notifications that my products were sending, we didn't have the same kind of environment. For something as simple as a forgot password, and more complex things like an end of the week summary, we have a lot of complexity that is still just sitting on the engineers' shoulders.

I found that my engineering teams are having to build this out themselves over and over and over again. I looked at building out a robust version of it at one of the companies I was the CTO at. And we ended up not being able to justify the expensive, robust solution that a product like Slack has. Instead we ended up with a really crappy solution that was not well loved by users, because it sent notifications to multiple channels at the same time for a user. I went and talked to the team over at Slack, who I think have best in class notifications across multiple channels, learned a little bit what they were doing, went and talked to vendors like Twilio and Amazon to see if they had something that we could buy. And ultimately, I learned that everybody's still just hand coding this and doing it themselves, so ultimately I decided to leave my CTO role and start Courier.

Tell us something interesting about Courier.

Traditionally, messaging companies have pretty substantial free tiers, which is true for Courier as well. And that means that the vast majority of customers that sign up for Courier aren't paying us anything. That's kind of the expected structure for go to market for a business like ours. And you look at Twilio, you look at SendGrid, they're all kind of structured that same way. But what that does is it changes the way you need to look at culture with your customers, because at a traditional software company, you're giving most of your attention to the enterprise customers, to the customers that are paying the most. But the nature of this kind of messaging API space is you're placing bets on earlier stage companies, and you're basically sowing seeds that you expect to harvest years from now — where you're working to become incredibly valuable to a company at the earliest of days. You expect to see some percentage of them grow into very large businesses in their own right, and then we will be the partner that's has been there for them the entire way. It's a very different way that you have to think about how you treat customers and who you spend your time with. The nature of this market is that if we fast forward five years and Courier is a success, it will be a success not because of enterprise sales, but because we were able to build a bottoms up channel where free customers showed up, got a lot of value, and grew into paying customers.

What major channels do customers provide you feedback?

• Live Chat via Intercom

• Shared Slack Channels

• Email

Who handles customer conversations?

• Everyone

Many of our customers know multiple engineers on our team by name and vice versa. Our engineers will reach out and ask a customer for advice on something that we're building. They will do that without having to wait for me to suggest it.

What is something that your team struggles with when it comes to listening to customers?

We try to be hyper responsive to customer requests and build them out as quickly as we can. We'll change our roadmap priorities on a dime to make sure we're prioritizing things that will move us towards product market fit, as opposed to things that are maybe a bit more aspirational. The downside is obviously, some things are bigger than others. And we can't always implement the feedback immediately. And I don't think that we have enough structure for those longer term issues. Basically, if we get feedback from you, and we can deliver a solution with a few days of work, we will we will crank it out that week or the next week, and just be done. We've optimized for that kind of agility and that speed of execution. As a result, we haven't really spent the effort to optimize for how do we queue up things that we should be working on six months from now.

What is something that your team does well with respect to listening to customers?

I think one of the things we've done a very good job of is building relationships between our line engineers and customers. Many of our customers know multiple engineers on our team by name and vice versa. Our engineers will reach out and ask a customer for advice on something that we're building. They will do that without having to wait for me to suggest it. Similarly, if a customer sees something cool, they generally know who built what, and they'll be like, "Hey, I saw something really cool that you just launched in the editor. Good job, Riley. Looks great."

We've built a transparent relationship between our team and our customers that feels really authentic, as opposed to, when you grow larger, you end up introducing purposeful barriers between those two audiences. And I think as a result, that damages the fundamental relationship between yourself and the customer. Perhaps you need to create that damage in order to scale your business, but we aren't really at that stage yet. For us the optimal thing to do is to have as few barriers as possible — to tightly integrate ourselves with customers, go over to their offices and hop into their code base, if they let us. We like to blur the lines as much as possible and create as tight a connection so that we can we can learn as much as possible from each customer.

How long do you think you can scale this?

I'm confident that we can at least double in team size and still keep this going. I guess there's two vectors to scaling this: there is the team size and there is the customer count. I think the customer count actually scales quite well for us being an API company — once we get through that initial onboarding phase, the relationship persists, but the amount of customer engagement reduces dramatically. So we might only hear from somebody once a month or maybe less, but we spent the time building that relationship in the early period where they needed a lot of attention. I think the limiting factor will probably be more on the team side of things. I'm confident we can at least double, so we're certainly not planning to change anytime soon.

Troy, thank you for talking with Userstand. It was great to learn a bit about Courier and how your team is making a strategic bet on investing in your smallest customers.