Adam Brown

Over the last year we've been scaling the team at Mux more than ever. As we do that, we're considering how we can help new team members build a company that's seen as exceptional by our main audience: developers.

While the developer tools space has grown quickly over the last ten years, it’s still a relatively new business model. There are mature playbooks for building a consumer business or for selling B2B products to the enterprise, but developer businesses, despite massive success in some cases, are all still early, and the playbooks aren’t as developed.

As an exercise, the four Mux founders wrote down characteristics we think are key for a successful developer product company. Here's what we came up with, and how we try to apply these at Mux.

Authentically great

Developers are skeptical by nature—they have highly tuned BS meters. They appreciate products that do what they say, say what they don't, and then exceed expectations. Word of mouth is the best growth channel for developer products, so it’s better to be authentically great than to rely on tricks to grow.

At Mux, we aim for our products and customer experience to be surprisingly great so developers are excited to tell other developers and bring Mux with them from project to project. We try not to overstate what our products can do and how well they do it—we avoid superlatives and over-promises in our product and marketing messaging.

At the same time, we invest in creating a healthy company—we wrote down our company values before launching our first product (one of which is "Be human"), and we scale intentionally. There's not much worse than learning a company you rely on is actually toxic behind the scenes.

Intentionally transparent

Developers need to solve problems and evaluate solutions quickly. They can’t do that if the answers are hidden behind vague language or human gatekeepers. Transparency removes friction and builds developer trust, and is especially important for difficult but important answers such as outage details or a post mortem.

At Mux, we publish our pricing publicly, we share the math behind our Mux Data scores, and we open source our client-side tools. We aim to be quick in reporting Mux service issues and open about what went wrong. Being transparent takes more work but it's worth it.

Every customer matters, large or small

The developer behind a Gmail address may one day build the next unicorn. And the bad experience of any developer can travel quickly through the developer community.

While many companies reserve their best product and support experiences for high-revenue customers, we aim to treat every customer surprisingly well. We give every developer access to every API feature rather than hiding some behind enterprise plans, and we intentionally invest in a responsive technical support team that's available to everyone.

This doesn't mean everyone gets the exact same customer experience. Large organizations often need different things than small ones. But every developer should have the ability to move quickly, get answers, and build any type of application.

Design matters

It's a misconception that developers don't care about design. From branding to UI to APIs, intentionality in design signals that there is investment in a product. Good design creates joy and trust, compared to the quick-hack projects and API afterthoughts that developers can be regularly frustrated by.

At Mux, we invested early in our brand and product design and are currently building incredible teams in these areas. We treat our documentation as a first-class part of our user experience. We painstakingly review API design decisions for consistency and elegance. Our own engineers are engaged in helping us design innovative features for developers.

Consultative sales & marketing

Ten years ago, selling to developers was unusual. Now, individual developers are usually the decision makers in technology buying decisions, and if they aren’t, they’re key influencers.

Selling to developers is a little different than selling to other personas. Developers habitually skip "marketing copy" and go straight to the docs. They're frustrated by products that force them to talk to a sales person first.

While that’s generally understood, when taken too far, companies start to underinvest in sales and marketing. The opportunity is actually to tune these functions to support developers in their buying process through clear, educational messaging and a partner that can help remove friction for their specific use case.

We use sales at Mux to enable customers to understand and use a product, not to convince them to do something they don’t want to do. Our marketing is direct and technical. We describe our products accurately and we aim to answer developers' biggest questions quickly. We provide added value whenever we can and do what’s necessary to help a builder be successful, even if it comes at the expense of a short-term win.

Engaged community member

Developers use many different tools when building an application, so every developer product is part of a large community where there's opportunity to build respect and love as a good community member.

At Mux we aim to be seamlessly integrated into this ecosystem. This means working well with developers' favorite tools and partnering with like-minded companies to create more complete solutions. We show up as engineers at key developer events. We look for places where we can be uniquely giving back to the community in the form of education and open source. And we organize communities where we can (like Demuxed).

Your thoughts?

Agree with the above? Disagree? @ us on social media somewhere, or just come join our growing team and tell us directly.

Over the last year we've been scaling the team at Mux more than ever. As we do that, we're considering how we can help new team members build a company that's seen as exceptional by our main audience: developers.

While the developer tools space has grown quickly over the last ten years, it’s still a relatively new business model. There are mature playbooks for building a consumer business or for selling B2B products to the enterprise, but developer businesses, despite massive success in some cases, are all still early, and the playbooks aren’t as developed.

As an exercise, the four Mux founders wrote down characteristics we think are key for a successful developer product company. Here's what we came up with, and how we try to apply these at Mux.

Developers are skeptical by nature—they have highly tuned BS meters. They appreciate products that do what they say, say what they don't, and then exceed expectations. Word of mouth is the best growth channel for developer products, so it’s better to be authentically great than to rely on tricks to grow.

At Mux, we aim for our products and customer experience to be surprisingly great so developers are excited to tell 

 developers and bring Mux with them from project to project. We try not to overstate what our products can do and how well they do it—we avoid superlatives and over-promises in our product and marketing messaging.

At the same time, we invest in creating a healthy company—we wrote down 

 before launching our first product (one of which is "Be human"), and we scale intentionally. There's not much worse than learning a company you rely on is actually toxic behind the scenes.

Developers need to solve problems and evaluate solutions quickly. They can’t do that if the answers are hidden behind vague language or human gatekeepers. Transparency removes friction and builds developer trust, and is especially important for difficult but important answers such as outage details or a post mortem.

At Mux, we publish our pricing publicly, we share the math behind our 

, and we open source our client-side tools. We aim to be quick in reporting Mux service issues and open about what went wrong. Being transparent takes more work but it's worth it.

The developer behind a Gmail address may one day build the next unicorn. And the bad experience of any developer can travel quickly through the developer community.

While many companies reserve their best product and support experiences for high-revenue customers, we aim to treat every customer surprisingly well. We give every developer access to every API feature rather than hiding some behind enterprise plans, and we intentionally invest in a responsive technical support team that's available to everyone.

This doesn't mean everyone gets the exact same customer experience. Large organizations often need different things than small ones. But every developer should have the ability to move quickly, get answers, and build any type of application.

It's a misconception that developers don't care about design. From branding to UI to APIs, intentionality in design signals that there is investment in a product. Good design creates joy and trust, compared to the quick-hack projects and API afterthoughts that developers can be regularly frustrated by.

At Mux, we invested early in our brand and product design and are currently building incredible teams in these areas. We treat our documentation as a first-class part of our user experience. We painstakingly review API design decisions for consistency and elegance. Our own engineers are engaged in helping us design innovative features for developers.

Ten years ago, selling to developers was unusual. Now, individual developers are usually the decision makers in technology buying decisions, and if they aren’t, they’re key influencers.

Selling to developers is a little different than selling to other personas. Developers habitually skip "marketing copy" and go straight to the docs. They're frustrated by products that force them to talk to a sales person first.

While that’s generally understood, when taken too far, companies start to underinvest in sales and marketing. The opportunity is actually to tune these functions to support developers in their buying process through clear, educational messaging and a partner that can help remove friction for their specific use case.

We use sales at Mux to enable customers to understand and use a product, not to convince them to do something they don’t want to do. Our marketing is direct and technical. We describe our products accurately and we aim to answer developers' biggest questions quickly. We provide added value whenever we can and do what’s necessary to help a builder be successful, even if it comes at the expense of a short-term win.

Developers use many different tools when building an application, so every developer product is part of a large community where there's opportunity to build respect and love as a good community member.

At Mux we aim to be seamlessly integrated into this ecosystem. This means working well with developers' favorite tools and partnering with like-minded companies to create more complete solutions. We show up as engineers at key developer events. We look for places where we can be uniquely giving back to the community in the form of education and open source. And we organize communities where we can (like 

Agree with the above? Disagree? @ us on social media somewhere, or just 

An illustration of Steve Ballmer saying "developers, developersl, developers"

Developer product companies, despite massive success in some cases, are still early, and the playbooks aren’t as developed.

Steve Heffernan

Matthew McClure

Jon Dahl

Being a great developer product company is more than building products for developers

The Demuxed conference was recently kind enough to invite me speak about hardware video encoding in the cloud. Hardware vendors have been hard at work recently releasing updates to their encoding chips, and some of these enhancements are finding their way to the cloud providers. The drive behind this talk was to gather and distill some information on the current state of hardware encoding and how one might deploy it with containerization technologies like Docker.

I've spent quite a bit of my engineering career deploying video encoding services, GPU rendering processes, and most recently Docker containers to cloud providers. This talk is about what I learned trying to put all three together in the hopes of simplifying the barriers to hardware encoding.

Watch live video from on www.twitch.tv

 conference was recently kind enough to invite me speak about hardware video encoding in the cloud. Hardware vendors have been hard at work recently releasing updates to their encoding chips, and some of these enhancements are finding their way to the cloud providers. The drive behind this talk was to gather and distill some information on the current state of hardware encoding and how one might deploy it with containerization technologies like Docker.

I've spent quite a bit of my engineering career deploying video encoding services, GPU rendering processes, and most recently Docker containers to cloud providers. This talk is about what I learned trying to put all three together in the hopes of simplifying the barriers to hardware encoding.

Adam Brown

Being a great developer product company is more than building products for developers

Hardware encoding in containers

United States

United Kingdom

Products

Mux Video

Mux Data

Docs & Tools

API SDKs

Company

Learn about video