Net Dollar Retention for Dev Tools
Pricing Tips, Documentation, and "Time-to-Cool"
I love getting into the mechanics of what drives net dollar retention, particularly because the best practices are changing rapidly, especially at companies with a PLG model or who are serving developers. In this post, I sit down with Salman Kothari, COO at Mux, a video API company with a stellar net dollar retention rate and Series D funding from Coatue (and me!) last year. Among my learnings: treat documentation like a product in itself, be careful about what pricing benchmarks you reference, and create a "Time-to-Cool" metric for customer onboarding.
If you'd like to hear more about scaling tech companies a few times a month, you can sign up for my newsletter here:
When we initially spoke about having this conversation, you were very excited to start by talking about the product, because you felt that that was one of the most important drivers of net dollar retention (NDR).
Yes. In general, you know, a lot of people think of NDR as something that's owned by a customer success, and that's definitely true, but it starts with the product and should be co-owned by the product team and customer-facing folks.
There’s a factor that most companies don’t even include in the “product” category that I think is just as important to driving NDR, and that’s documentation. We've been absolutely obsessed with every aspect of the developer experience, beyond just their use of the product. We want developers to be wowed by the documentation. We've invested heavily in that. Other companies might just hire a technical writer. But we have a developer experience team that owns the documentation and treats the documentation like a product.
From the start, you need to think about docs in the same way that you'd launch a product and manage ongoing releases. You need to incorporate the updating of docs into every product launch cycle. This is simply good hygiene. You run tests before you launch a product; you should update your docs as well. And if we're managing docs like a product, then product managers are actually writing a lot of the content for documentation.
We also want our documentation to be delightful, just like we want our product to be. Our product managers try to bring the fun by embedding little Easter eggs within the documentation.
In between releases, our support team logs in a Slack channel when they notice a mistake in a doc. And every new person that joins the company, whether they're an engineer or solutions architect or customer success manager, digs deep into the docs and calls out aspects that are out-of-date or incorrect.
I know you have a consumption-based pricing model. How did you design it to drive NDR?
To drive NDR, the product needs to be set up so that customers can benefit more over time, and the pricing model needs to correlate with the value that you're getting as a customer. Our pricing is based on the usage of the video that you upload, store, and deliver. That means when our customers are increasing their usage, it’s because their customers are consuming more video. With our simple consumption-based pricing, it’s not only easy for customers to understand their bill, it’s also easy for them to see the value they’re getting from Mux because they understand how it correlates to their own users’ engagement.
For API-based businesses like Mux, the customer sets something up and then lets it run. Our product is embedded into the customer's product, which is a powerful foundation for the customer to get value and consequently expand their consumption with us over time.
Other companies whose pricing models are based on seats or based on their cost structure have to have tough conversations with their customers. The customer doesn't understand how the price relates to the value that they're getting. Simplistic pricing that is tied to value makes those conversations easy.
What advice do you have for startups that are designing their consumption-based pricing model?
Keep the metric simple. Originally we flirted with making the pricing dependent on video quality, cost considerations, and other factors. But we prioritized simplicity. The main question was, what will resonate with the customer? Specifically, how does the customer perceive value?
I often see people consumed by the underlying costs. It's good discipline to consider that. But you can't lose sight of the business value that your product generates. That value should determine the pricing metric, and then you should do a gut-check on what that means for covering your costs.
We've iterated on our pricing five times now. Initially we did some benchmarking, looking at other services that you could use to try to piece together Mux yourself, and seeing how much it would cost you to stream a minute of video.
When I first joined the company, before we launched the Mux video product, we had a goal to have 100 discovery conversations with customers. One of the questions we asked was, what are you willing to pay for an hour of streamed video? Some customers had a ready answer because they understood the problem well, but the vast majority of customers needed to think about it or gave a high-level answer. To be able to meet your customers where they’re at, It's important to be targeted with your questions and put them in context.
I often find that customers will compare the price of your product to the price of other products that are in a similar part of their tech stack. For example, they might expect that the price of Mux would be x% of the price of another product that they're using. How do you think of your pricing in the context of your ecosystem?
A prospective customer might initially think that they should be comparing us to the cost of storing, hosting, or processing videos, but video streaming is really different – it's far more expensive, because it's hard to run video at scale. So we spend time educating customers about what it would cost them if they were to build it themselves – what's the total cost of ownership.
In general, I find it important to understand deeply where your customers are coming from, and put yourself in their shoes. They probably haven't thought about this problem as much as you have, and so it's helpful to lead with education.
How do you think about whether to price at a premium or a discount to your competitors?
It totally depends on your target market and how you intend to grow. Our strategy is to empower every developer who's going to build anything interesting with video. It's important for us to have a monopoly of new projects. We have a set of developers who might be using Mux on a side project, but maybe they'll start a company later. Supporting developers throughout their careers is an important part of our growth story. For that reason, we don't want to be the expensive provider. We also think that most of the video that's going to be consumed in 5 to 10 years is from services that don't exist today. So we want to capture market share by empowering every single one of those new use cases.
Our ultimate goal is to make building beautiful video experiences accessible for every developer. We don’t see our pricing as either premium or discounted, but rather as a price based on the value we’re helping to deliver.
When you designed your pricing model, did you already have a sense of how many units of your primary pricing lever would be consumed by your customers? Did you forecast that by account?
Yes, I think you have to do that. You need to understand how your customers will grow in consumption and revenue over time, and how that compares with your acquisition costs. It's especially important to forecast how your discounting curves (i.e. discounts for volume) will affect your long-term revenue from your customers as they expand. Not knowing these things when you go to market can be a bit dangerous. You won't get it perfectly right the first time, but that's okay.
Who should be leading your pricing initiative? Should you hire a specialized pricing analyst?
Early on, whoever is doing biz ops type of work (connecting dots between product strategy and finance) should lead pricing initiatives, with key input from Product. Eventually, I think it’s worth investing in a dedicated biz ops team and even a dedicated in-house pricing specialist. We now have an in-house pricing person who runs very sophisticated pricing surveys to deeply understand the willingness to pay.
The folks that I've worked with in this realm typically want to broaden their skill set to Biz Ops more broadly. They might have come from Simon-Kutcher, which is a great pricing consultancy firm. They might have worked there for a few years and are now ready to utilize their skill set at a dynamic start-up.
It can be beneficial to hire a consulting firm like this, because they can go really deep, but at the end of the day, it's helpful to have someone who is embedded in your company and deeply understands your use case.
Our pricing person spends half his day on pricing initiatives and half on deal desk.
Moving on to your customer journey. What aspects of that journey contribute to strong net dollar retention?
The customer journey in many ways starts with the website and documentation – which a user will look at well before they even create an account.
Then when they create an account, there should be a flow set up that allows people to actually play around, rather than clicking through a tutorial-like onboarding flow that's common with other tools. One of our developers coined a phrase, "Time-to-Cool Factor." How long does it take to do something interesting with the product? This question is more important to us than questions like "What's going to drive a purchase quickly" or "What would it take to get them to upload as much video as possible quickly." We feel that we have that one shot to gain mindshare from people. So this kind of "time-to-cool," or time-to-delight, is a key factor.
We provide free credits at the beginning so that you can get up and running quickly without spending money. The consumption of those credits is a big leading indicator of future revenue growth. But we care about what they're doing in the product, not just how much they're consuming. Only with that deeper understanding of adoption can you forecast future engagement and revenue. So we measure many aspects of product usage.
For our high-consumption and strategic customers, our Customer Success team plays a major role in helping these accounts derive the most value from our products throughout their journey. Our Customer Success team is highly technical (which I think is really important for a technical product with technical users) and has a deep understanding of their customers’ use cases and needs, so they’re able to help these customers grow in meaningful ways. With a technical CSM team, CSM teams can naturally engage with our customers at multiple points in the customer journey, not just onboarding and renewal phases. CSM best practices like executive business reviews are great, but paired with exceptional on-going technical support and proactive training around new product features, you end up getting better engagement throughout the customer journey.
Do you have a specific way of encouraging virality among Mux users, or is that virality more a beneficial consequence of other things you do?
We've stayed away from "powered by Mux" tag lines everywhere because we're an infrastructure, API tool, not consumer-facing. Instead we see virality happen in a couple of other ways. First, developers will sometimes share the tools that they built their projects with, like on Stack Overflow.
Second, we do a bunch of interesting open source projects. We launched a service called Stream.new, which allows you to easily compress a recording and share it through a simple drag-and-drop. And then people will branch off this and build interesting services on top of Stream.new. One time someone built a product for people's virtual weddings, where they'd collect sound bites from each of their friends to stitch together a tribute video for the couple. And developers can see that the product is powered by Mux.
Our founders often say, being a great developer product company is more than building products for developers. So we focus on shipping amazing products, experiences, and content to authentically generate word of mouth, which is far more powerful than simple tricks for generating virality.
I know you've been very intentional about building your culture around your customers. What recommendations would you have for other companies?
One of Mux’s company values is turn customers into fans. From that, we have an operating principle in my organization about Customer Obsession. That means the customer-facing teams being obsessed about their customers, but the principle also extends to the recruiting team being obsessive about candidates (who are they customers) and the people team being obsessed about employees (another customer type). The goal is to truly bring delight to customers. Our CEO said in an all-hands recently: do the right thing for employees and customers first, in your decision-making, and that reminder is a helpful orientation for people. If you build that culture early, it keeps reinforcing itself.