Jan-Erik Asplund
Background
Adam Brown is co-founder and the head of architecture and technology at Mux. Previously, he was a senior software engineer at Brightcove and worked on the Zencoder team. We talked to Adam about the post-COVID growth of live, streaming and interactive video and about video's transition from a marketing tool for companies to an essential product for an increasing number of software companies.
Questions
- You worked at Brightcove before Mux, as did some of the other co-founders of the company, and were on the team behind Video.js. I'm curious how those experiences building in video for years beforehand influenced the founding of Mux.
- Could we dive a little bit into the use cases of Mux for developers and those folks who get the most use out of the product?
- I'm curious about that [proto-product 04:40] transition. How did you all think about, "We're going to start with data and then go up the stack to video"? How do you think about continuing to expand in the future?
- Can you talk more about Netflix and YouTube having more introspection into the video stack and what that implies and why? What makes them particularly good at it, besides being huge companies?
- Regarding Mux's usage-based pricing model, can you share any insights into how Mux has scaled along with customers over the years?
- How does Mux think about itself culturally as a company? Having had experience with other video companies, do you think there are major differences culturally in how Mux is engineering-centric? Is that unique in the broader video space?
- You mentioned two lines of business, enterprise and developer-first. I'm curious to learn more about the differences there. For example, when Twilio was going public, Uber was a huge share of their revenue, but it wasn't a massively different experience for Twilio to serve Uber, whereas at some other companies the top enterprise customers can have some influence over the roadmap of the product itself because they're sufficiently large. Where does Mux fall in that spectrum? What does the distribution of revenue and customers look like between enterprise and developer-first? If they're separate internally, does it influence how you service them? Is there more custom stuff being built for enterprise customers versus the more off-the-shelf product?
- I'd love to talk more about the future and where you see the need for this enterprise video solution. What is the big missing piece or pieces and how are you thinking about building towards this future?
- You mentioned earlier that you saw yourself more as a platform. As you go up the stack into things like Mux Video, how do you see the positioning of Mux alongside Vimeo, Wistia and tools like that? Do you see it as the whole pie expanding so it's not really competitive?
- If Mux is in the middle of the stack, AWS maybe at the bottom, and top of the stack is Wistia, Vimeo, and YouTube, where would you slot Cloudflare, Bitmovin and Twilio's video API?
- How do you think about live versus hosted in the future? That's another distinction where some of these players are more focused on hosted video, and it seems like Mux is a bit more looking at live.
- We've talked to a lot of businesses that had more activity during the pandemic, but I sense that you had a combination of both more activity and different activity. What changes did you see during this time?
- How does Mux going into COGS affect your pricing?
- To the extent you can talk about it, what kinds of workflows and corresponding products are you imagining, besides data and video?
- Do you see the expansion of Mux's customer base and TAM primarily as growing the customer base that you're targeting now, i.e., teams with the desire to build some differentiated experience over video with developer resources and budget? Or do you see more up the stack motion, where you can sign up and start using Mux to build these experiences without developer resources?
Interview
You worked at Brightcove before Mux, as did some of the other co-founders of the company, and were on the team behind Video.js. I'm curious how those experiences building in video for years beforehand influenced the founding of Mux.
Adam: The most obvious influence is that's where we all met, so there's that.
For each different piece of building a company -- when we worked at Brightcove, we worked on very different things. I've always worked more on the infrastructure side of things: I ran the live video architecture there and built out a lot of the cloud services and things like that. Some of the other founders, Matt and Steve, were working more on the Video.js side. The product that we worked on there was Zencoder along with Video.js, and both of those products were really developer-first products: Zencoder being an API to transcoding and Video.js being at the forefront of what developers are interacting with as they're building out the video player side of things.
I think that influenced or just brought to light how much we valued that developer experience. We've always worked on developer-first products and, being developers ourselves, see the value in what we could bring to the video market from that perspective. And taking some inspiration from other companies, we look a lot at Stripe and Twilio and folks like that who have done similar things in the space: targeting developers first and building products around the developer as the go-to-market strategy.
Could we dive a little bit into the use cases of Mux for developers and those folks who get the most use out of the product?
Adam: We have two products today. We have our data product and our video product.
The data product was the first thing that we built, and it is an analytics collection tool set for collecting video end-user experience metrics. We build SDKs that integrate with video players that then let us analyze and present metrics on how well their full video stack is performing. As developers, the use case here is you're trying to make a choice between video player A and B or video delivery stack B and C, and you can see how all of these things are performing compared to each other. That's in the developer workflow set. Then once you have it up and running, it becomes your monitoring for that as well. For larger livestreams and things like that, these kinds of monitoring use cases can be really important. You can actually make real-time decisions based on some of this stuff.
The video product is the full end-to-end solution. You give us a video source file -- whether it be live or a video on demand, like a recording -- and we handle all of the hard bits in between: the transcoding, the storage, and the delivery, including that last-mile delivery -- that CDN to ISP delivery -- as well. At the simplest, you give us a file and we give you a URL to drop into the video player, and it's going to work everywhere.
I'm curious about that [proto-product 04:40] transition. How did you all think about, "We're going to start with data and then go up the stack to video"? How do you think about continuing to expand in the future?
Adam: The short answer is that the timing wasn't accidental. We didn't build a data product and say, "Maybe we should build a video product, too." We always wanted to build the video product. Video is huge. There's a lot of technical challenges there. It's really hard to go out and compete from the ground up with some of the other well-established APIs that have huge engineering teams.
There's a handful of platforms out there where you expect video to work really well and they've become the cornerstones of the market: you think YouTube, Netflix. The thing that they have that a lot of other companies don't is that end-to-end introspection into their video stack. They've invested in those client-side tools. They've invested in these kinds of data tools. We saw an opportunity to get off the ground there with a product that was developer-friendly and in that space, and ultimately also be able to inform our own video product as we built it out. So there were two sides to it. There was opportunity to find a product fit and have a great developer product there, and also serve our own interests in building a video product later on.
Can you talk more about Netflix and YouTube having more introspection into the video stack and what that implies and why? What makes them particularly good at it, besides being huge companies?
Adam: You look at the transition from a startup to enterprise on a spectrum: the more advanced you get, the more money you have to solve these types of problems. You're going to invest in that tooling to really perfect it. You look at products like Data Dog or New Relic and people like that who have gone out after "How does a developer get this introspection tool set when they don't have the team to build it?" It's kind of the same idea. People don't often think that the video stack is that hard when they don't know how hard video is. While there were some other products in the market for this kind of quality of experience analytics for video, they weren't developer-friendly. They were "Call us for pricing and sign your contract" to even begin to get started.
What we see with Netflix and YouTube is they've got entire engineering teams dedicated to this. You're not going to accidentally get great client metrics: you really have to invest in it. That's not something that most companies that are just trying to make a cool video product are going to be able to invest in early on. Even today, you look at our customer list, and some of the larger media companies that use our data product, they didn't even have this kind of stuff. But over the past ten years, the expectation in video quality online has dramatically changed because of what YouTube and Netflix have done.
Regarding Mux's usage-based pricing model, can you share any insights into how Mux has scaled along with customers over the years?
Adam: We started with the data product and as soon as you get into some customer of decent size, that's a lot of traffic very quickly. So there's the technical side of scaling that. As an engineering culture and a company, we've always known since the very beginning that success for us on a product and technical standpoint means a really, really large scale infrastructure side of things. We've planned for that since very early. It's kind of counter to a lot of startup wisdom: do things that don't scale and be scrappy early on. We felt we knew what product market fit looked like very early, and it was really, "How do we scale and build from that?" from day one.
On the company side, I think one of the challenges there is that, between our two products, we cover a lot of different segments of the market. We've had to scale on the enterprise side of things while at the same time focusing on the developer-first mindset. I don't think it's been particularly challenging. It's something that we knew that we were going to have to do, but it's meant that we've had orgs and our internal structure facing each one of these segments intentionally since very early on.
How does Mux think about itself culturally as a company? Having had experience with other video companies, do you think there are major differences culturally in how Mux is engineering-centric? Is that unique in the broader video space?
Adam: I don't think being engineering-centric is necessarily going to be unique here. Video is inherently a really technical challenge heavy product. I always tell people, "Video is the biggest use of bandwidth, compute and storage on the internet." Even at small scale, you're quickly getting into real scale cyber liability type challenges. And on top of that, everyone expects it to work all the time.
From a culture perspective on the engineering side, we do tend a little bit more towards controlling our own destiny, like running products ourselves, not relying on external vendors. We run on multiple cloud providers, we run in multiple regions, we build redundancy into everything. That's really core to the engineering culture. There's a lot of SaaS products in the space where, "Here, we'll host the database for you" or "We'll run that." We've always shied away from those kinds of products, for better or worse. It's an extra burden on ourselves to get good at running these things and operations, but that's what we're here for. We really see ourselves as a platform more than anything else.
Being so engineering and developer-centric internally, that really does fit our model externally as well. We're developer-first, built by engineers. We're always thinking about the API. One of the more unique things about our culture is that we have a developer experience organization that is kind of its own org. It's not engineering, it's not sales, it's not marketing directly. We started out in the very beginning having a developer experience organization that's hiring engineers for building those customer-facing -- whether it's tooling, documentation, whatever -- a significant focus on that developer experience. It was never a byproduct of engineering and product in marketing. It was a very intentional all-in unique organization. That's probably something that is telling of our culture and how we think about the product and how we interact with our customers.
You mentioned two lines of business, enterprise and developer-first. I'm curious to learn more about the differences there. For example, when Twilio was going public, Uber was a huge share of their revenue, but it wasn't a massively different experience for Twilio to serve Uber, whereas at some other companies the top enterprise customers can have some influence over the roadmap of the product itself because they're sufficiently large. Where does Mux fall in that spectrum? What does the distribution of revenue and customers look like between enterprise and developer-first? If they're separate internally, does it influence how you service them? Is there more custom stuff being built for enterprise customers versus the more off-the-shelf product?
Adam: I'd say it's very rare that anything is custom built for an enterprise use case. If we're going to build it, it's going to becoming a feature of the product. It might exist in a more premium tier, but it's going to be part of the product.
Probably the best way to think about this is looking at the segmentation between our two different products. What we found with the data product is it was very successful in mid-market and up. To some degree, the developer is just trying to get their simple video product with a few users off the ground. They're not even at the point where they're caring about the quality of experience yet, though we want them to and are continuing to push them to get us installed earlier and think about this earlier. We found enterprise success early with the data product, where we were able to go to customers like Fox or CBS and be a meaningful part of their stack. Navigating those relationships from an enterprise sales perspective is a muscle in and of itself.
The video product has really focused on a different segment. For one, building the full core solution that's going to solve all of the enterprise needs is years away. We want to get there, but we really started at the other end: developer-first and solving the more core developer experience side of things. We have the enterprise sales engine and that experience with the data product that we can bring to the video product, but the video product's working its way there at the moment.
As far as revenue goes, video is much more expensive to operate and run than the data product. Our revenue today skews towards the video product with our recent growth, but that's because inherently there's a lot more money moving around when you're moving the more expensive video stuff.
I'd love to talk more about the future and where you see the need for this enterprise video solution. What is the big missing piece or pieces and how are you thinking about building towards this future?
Adam: Maybe the best way to talk about this is that there's a different segmentation that we've identified on the video product. Obviously, we're focused on developers, and we want that developer in his basement that's working on his app in his spare time and wants to put video into it to find us. That's a very big focus. Then, when you look at enterprise and the really big contracts, we've got a lot of features and things to build to get there.
In the middle, there's an interesting distinction that we make between media and tech companies: media being more along the lines of the HBOs and things like that, and tech being more like -- Robinhood is a good customer example for us. They're a tech-first company but they've decided to bring in video for strategic bits. They're technically very competent. They build a lot of software. We just want to find ways for them to build better experiences with video.
That segment has been really, really strong for us. We see a lot of parallels between that and the solo developer or founder. A lot of the ways that you find your way into those companies is some development team is tasked with adding video and they don't really understand the full scope of that, and one of the developers finds us and brings us in. That's been really successful.
When you get into the media side, where they start out with a big requirements list for the video side of things, ideas like captions and maybe DRM and all of these more complex things -- that's the place we're working towards now. But the tech industry and specifically user-generated content has really been where we focused on.
You mentioned earlier that you saw yourself more as a platform. As you go up the stack into things like Mux Video, how do you see the positioning of Mux alongside Vimeo, Wistia and tools like that? Do you see it as the whole pie expanding so it's not really competitive?
Adam: It's more the latter. We strongly feel, and we do see, that the pie is expanding. Every app today has some sort of video component to it and we only see that getting bigger.
I think the distinction that we would draw between some of those tools and us is we feel like we sit at a slightly different abstraction layer. You look at AWS at the lowest level: they have a lot of tools to put all of these things together. You still need a lot of video expertise on your team to do that. You need a video engineer that knows how to set this encoding setting or how to store and what CDN to hook up. Then you've got the ones that you've mentioned that are sitting at a slightly higher place in the stack where you don't necessarily need as deep of a technical integration. You can maybe click a couple buttons and wire it up to your other systems, but you lose some flexibility.
It really is a battle of the abstraction layers. We obviously run into those companies in sales and probably will continue to more as we expand what we're doing. But right now I think we really do feel like we're playing the abstraction layer at a slightly different spot than them.
If Mux is in the middle of the stack, AWS maybe at the bottom, and top of the stack is Wistia, Vimeo, and YouTube, where would you slot Cloudflare, Bitmovin and Twilio's video API?
Adam: They're more right there alongside of us. But they're also serving very different needs. They are more specialized in certain areas today for the most part. They're picking off one piece of it and doing those well. I think where we see ourselves going is really more of, "How do we cover the full spectrum of video and do it in a way that is super developer-friendly and, ultimately, not need any sort of video expertise on the customer's team?"
The best parallel I can draw to this is, if you look back 15 or 20 years when AWS came out and people started moving things to the cloud, people still had sys admins and people racking, stacking servers on their teams. Nobody is doing that today as a startup. But today, there are still people bringing in video expertise to their teams at a very early stage in order to build some of these new and unique video experiences. That's what we want, that same kind of play. Like, "You don't need that. It's on your team. We have all the tool set that you need to fully build out your video experience."
How do you think about live versus hosted in the future? That's another distinction where some of these players are more focused on hosted video, and it seems like Mux is a bit more looking at live.
Adam: From a technical standpoint, we don't draw a lot of distinction. That's one unique thing about our technology. Most places where I've worked or seen the inner workings, those are two different technical stacks and it's very distinct. Internally, we really don't think about them too differently, down to the transcoding happening on the same workers and things like that.
From a future of the product perspective, where live gets a lot more interesting is when you talk about interactivity, and that's the place where we're spending a lot of time. We just recently released our LL HLS implementation where we try to bring down the latency for large distribution live. You have use cases where viewers are chatting back and you want that three to five second max latency to talk to the broadcaster and build more interesting experiences around that. As we're continuing to iterate on the product we'll probably focus a lot more there, on "What can we do to more enable that interactivity?" If nothing else, the pandemic really brought this home with everybody switching events and things to live. There's the traditional broadcast one to a million, but how do you get the feedback and bring people into those experiences in a more compelling way? There's a lot of people doing some really unique things there. That's where we're focusing a lot of our efforts today.
We've talked to a lot of businesses that had more activity during the pandemic, but I sense that you had a combination of both more activity and different activity. What changes did you see during this time?
Adam: I think the biggest thing was traffic. We just saw an explosion, particularly in live.
But the more interesting thing was the use cases that were popping up. We saw everything from funerals to weddings, entire companies popping up around each one of these use cases. Concerts and music experiences have been huge. There's a question of what happens when things return to normal. Nobody knows, but I think a new precedent has been set to some degree. As an example, there are so many concert-streaming companies that have cropped up lately. Is the new expectation, "Sure, you can go attend the concert, but why would you not also have a revenue stream from streaming it for the people that couldn't make it?"
I don't think we'll see the dramatic traffic spike that we saw the pandemic drive again, but I don't think we're going to see a decline. I think we're going to continue to see this industry grow. Other examples are kids sports, when grandma and grandpa couldn't come to the event and now there are companies out there distributing cameras for every kids sports game that they'll livestream and things like that. I don't think that's going to regress. But there's a lot more we can do besides just the passive livestream.
How does Mux going into COGS affect your pricing?
Adam: Pricing is forever going to be a challenge. Video is so expensive to operate that we've invested a lot in our technology early on to be able to always be able to compete here -- that's the best way I can put it. We want to be able to move between different infrastructure providers and be really flexible with this pricing. This is something that took a lot of investment and something we focused a lot on.
I think that we will forever be able to be competitive with anybody else's pricing, but we really plan on, at our abstraction level, being the glue that makes it not a commodity. We want to be able to build the tool set that other people can't replicate. The workflows that people are able to build on us should be really sticky. Take Amazon, for example, where you have to do a bunch of engineering work to build a workflow that takes engineering work to undo and rebuild. Again, it's our abstraction layer that I think is the powerful bit for us.
To the extent you can talk about it, what kinds of workflows and corresponding products are you imagining, besides data and video?
Adam: There's one that's just tying the two together. That's something we're working a lot more on now. The data product has traditionally been focused on engineering teams as consumers that are trying to optimize their video platform. Obviously, when we are the video platform, that becomes a little less useful. It's still quite useful for client-side decisions like the video player: Which player are you choosing? How is the implementation actually done in your webpage? And things like that. But this same data set can also tell you a lot about how people are actually consuming the content, like the things you would expect to see from a YouTube creator dashboard. I think there's a lot of power there in tying these two together, since we have the infrastructure for both.
Other things like, again, those interactivity experiences. How do you tie metadata to video streams so that you can have feedback from end users and have more interactive experiences from those end users?
Do you see the expansion of Mux's customer base and TAM primarily as growing the customer base that you're targeting now, i.e., teams with the desire to build some differentiated experience over video with developer resources and budget? Or do you see more up the stack motion, where you can sign up and start using Mux to build these experiences without developer resources?
Adam: I think that's more up the stack. Right now, obviously, we see a lot of growth with just the existing market. Having video in an app is becoming table stakes for any kind of real experience. Whereas video was optional for a product or an app five or ten years ago, now it's becoming more and more required. And somebody's building those. Developers in those are the ones that we're targeting.
I think we'll see -- and we already have seen -- a number of customers of ours that are platforms themselves. They're there for the more UI, workflow-y based things. Or even livestreaming -- a lot of our live customers are live platforms for other end users. We really plan on focusing on the infrastructure and platform side for those.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
