Episode 39: Rancher — A support-based business model that scales, with co-founder Shannon Williams
Shannon Williams, Co-Founder and VP Sales of Rancher lays out how a great team with deep domain knowledge can actively identify a product market fit in a crowded space, and emerge a winner. It’s an inspiring story of a plan perfectly executed. This is a MUST LISTEN episode of Underdogs!
Intro
Michael Schwartz: Hello, and welcome to the Open Source Underdogs podcast. I’m your host Mike Schwartz, and this is episode 39, with Shannon Williams, Co-Founder and VP Sales of Rancher.
Let’s go for a minute into the land of hypothetical. If I can ask all 38 previous podcast guests a question, “Is monetizing support a good idea?”, I think there would have been virtual consensus that support doesn’t scale. Except, Rancher is perfectly executing a business plan to do just that.
I hope you’ll enjoy this episode. Tweet your comments at @fosspodcast, and we will asynchronously discuss in the Twitter sphere, but for now, here we go with the interview. Shannon, thank you so much for joining us today.
Shannon Williams: Thanks for having me, Mike. It’s exciting to be here. Looking forward to our conversation.
Origins
Michael Schwartz: Can you just fill us in a little bit about how Rancher got started and what was the mission?
Shannon Williams: We’ve been going now since 2014. In a lot of ways, it feels like we started before that, because my co-founder Sheng Liang, Will Chan and I, the three of us started another company called Cloud.com back in 2008. And, for all intents and purposes, we’ve been working together every day for 11 years now. That company was an early developer of open-source infrastructure-as-a-service software.
We built a product called CloudStack with the founding members of the OpenStack foundation. I had a really fun run there for about three years before being acquired by Citrix, and spending another three years at Citrix.
In our work on CloudStack, we learned a lot about, as you can imagine, managing infrastructure at scale, building out private clouds, helping a lot of large companies build public clouds. At the time, everything we were focused on was how do we deliver virtual machines to developers quickly from anywhere.
But over the course of working on a lot of private clouds, we noticed that we had a lot of conversations with people trying to figure out how to blend their on-premise infrastructure with this growing amount of cloud infrastructure.
One of our early customers was GoDaddy actually. They were looking at building a public cloud, and Darren Shepherd, our fourth co-founder of Rancher, was a Chief Architect there. We got to know Darren really well.
We started talking in 2014 about what could be done to bring together the on-premise infrastructure, the cloud infrastructure, into something that overlaid it all, and to really allow people to treat infrastructure like Cattle, like a disposable commodity. And Docker was just getting started, the concept of Containers was emerging, and we thought there was a really cool opportunity to look at leveraging that, to build out management tooling, infrastructure services, and kind of imagine the next generation of infrastructure management, which would hopefully enable people to do computing anywhere, with really consistent deployment experience, management experience, monitoring experience, all these types of things.
And so, Rancher was born. For almost 5 years now, we’ve been working on continuing that journey, how to build open-source products that are available to anyone, and really allow them to run workloads anywhere. So, that’s really where we came from.
Value Prop
Michael Schwartz: This market, it’s really diverse. There’s a lot of tools and tooling in this area. I’m wondering, what’s the exact value proposition for Rancher service?
Shannon Williams: Rancher is open-source software, we have a number of open-source projects but our most famous is called Rancher, and it really sits at the management playing around Kubernetes. Organizations use Rancher because they are deploying and managing more and more Kubernetes clusters.
Rancher provides distros of Kubernetes. We have one called RKE, which is a pretty typical, upstream distro, it’s really good for deployment, automation. Then, we have one that’s optimized for the Edge or other low-resource utilization called K3s.
We provide distros of Kubernetes to people that need to run Kubernetes, but Rancher itself actually sits above those distros, it’s the management client. What’s cool about it it’s really distro agnostic. It actually manages any Kubernetes. And by managing, what that means is an organization implements Rancher so that they can deploy and control, and then grant access to dozens or hundreds of Kubernetes clusters – some running in the clouds, some running as hosted services like GKE, and EKS, some running on premise, maybe on the Edge.
By bringing all those clusters together, what Rancher allows them to do is, dictate policy, control access, monitor availability, manage deployment of applications, manage catalogs, attach additional open-source services, like Prometheus for monitoring, or Fluentd for logging, or Istio for service match, and so, Rancher sits at that next. So, how do I manage Kubernetes everywhere according to my organization’s policies.
By doing that, it enables them to then really deliver their service reliably. For organizations, they think of Rancher as the Kubernetes platform, it’s Kubernetes as a service, it’s how they deploy apps and run anywhere.
Monetization
Michael Schwartz: The Rancher GitHub repository has 14,000 forks, which is really a lot. But there’s only around 60 something developers, which I could see is probably primarily being the people in your organization – can you talk about the relationship between the open-source project and the activity there, and the SaaS service?
Shannon Williams: Just to be clear, we don’t offer a SaaS service. Rancher is open-source software only. We only provide open-source software that people use, but what we sell is support for those open-source projects.
On any given day, there’s about 30,000 teams around the world running Rancher. Those teams, they may be a smaller group that’s deploying it for one application. There’s maybe somebody doing a Dev lab, or test lab, but of those about 1%, about 300 enterprise customers, these are companies that deploy Rancher, and whatever they are running on it, it’s critical to their business.
They contract with us to provide enterprise-grade support for Rancher, RKE, K3s, and really their whole Kubernetes stack up and down. By providing that Enterprise-grade support, what they get from us is the confidence to run really important workloads on the open-source Rancher, but what they like is that we don’t have your classic open-core only model, we don’t sell version that’s different to them. They just pay an annual support subscription, and they use it.
A year later, if they are no longer using it, they are not paying an annual support subscription. They can keep using the software, but they would be using it again without support.
Our model is geared around helping organizations that need support, get the best possible support in the world for Rancher, Kubernetes, Prometheus, and Istio, and all the pieces of technology that we deliver to them.
Why Open Source?
Michael Schwartz: Has open-sourcing the code really made a meaningful contribution to the company?
Shannon Williams: It’s at the root of our success. By open-sourcing the code, we enabled a startup with relatively no name recognition obviously, to come into, in a lot of ways, it’s a very crowded market.
Think about the companies that are dealing with application management platform as-a-service. When we started, you can imagine Docker, Mesosphere, Red Hat, Pivotal, these companies were already out there. You know, Docker, in their sense with having released the Docker project, orchestration and building different types of management tools, and with enormously more funding than us, much, much, much bigger brand recognition teams.
We had to find a route to market with limited funds, we needed to let our product be our best piece of marketing, and so we took that approach. We believed in this for a long time. In our last company, we had a very similar approach. We made Rancher fully open source and free because we felt that it was the best way to get adoption, to plant seeds in organizations that would need this technology.
By putting it out there, we really bet on two things. We bet that people would like it, and that they would want to use it, but we also bet that this technology was crucial. And that at least a good chunk of people who use it would find value in getting support for it and find value in having SLAs that they can rely on for that application. And we’ve been thrilled. I mean, our company’s now almost 200 people, we’re more than doubling this year. In terms of revenue, it’s really worked out really well.
People really do love Rancher. It’s something that makes me really confident with the model as you have to believe in your engineers, you have to believe that products can be great. We also spend an enormous amount of investment of time working with our open-source community. We have a huge Slack community of thousands of users who come in with suggestions and ideas on how to make the product better. We get thousands of issues, and feature requests, and bugs filed by the community.
I don’t think we have more of a user community then of a contributor community. I love it because they come to us with real problems that need to be solved, and I identify them. Often, their use cases sometimes are pushing the boundaries that we may not see out of a Fortune 500 company that’s using Rancher. So, it all sort of pushes forward with the hopefully creating a great product for everyone.
More On Why Open Source…
Michael Schwartz: So, just to sort of dive a little deeper on that. If you made the software commercial tomorrow, do you think the 300 or so Enterprise customers, who are using the software, do they really care about it being open source? Or is it just a non-sequitur, or they just want the best software? So, if you made it commercial tomorrow, do you think that that would be bad from where you are today?
Shannon Williams: Yeah, I do. When I talk to organizations about our business model, they get really excited because there isn’t one of them which hasn’t been in a position of really limited leverage against their current vendors. Everybody has been staring at just massive renewal orders.
We closed, just this quarter, today is the end of our third quarter, and we closed three deals with organizations that are spending a lot with us, half a million a year in recurring revenue, for example, to support environments. And their frustration in some cases was platforms that they had built, PaaS platforms, where the cost had grown exponentially. And they just had no ability – even though these were all based on open-source, they weren’t themselves open source. I mean almost everything is based on something, open source at this point.
What people really like is, they like an open-source product, because they always have the option to leave it there, let it run, support it themselves, hire some engineers and figure it out. In the end, if you are running a proprietary tool, and you don’t pay, you have to yank it out of production. And that is impossible for most companies.
I think our business model, yes, some people would still buy a Rancher, and be fine with it, but I think a lot of the smartest CIO’s I talked to are really excited to see a company like us, that embraces open source for commercial purposes, provides really good support, and is committed to building open-source products. For us, it’s allowed us to grow faster than any other approach I’ve been able to come up with.
Pivot To K8S
Michael Schwartz: Seems like Rancher made an epic pivot towards Kubernetes at some point, I guess, fairly recently – what did you learn from that process?
Shannon Williams: Well, the hardest part about getting into any market is making bets, and then figuring out where they come down. Rancher started about the same time as Kubernetes. Right around 2014, Kubernetes was starting at the same time we started our company.
At the time, we really thought Docker and their Swarm and stuff were probably more likely to win out. They had so much momentum. But it only took a year to realize that Kubernetes was actually really well-built piece of code.
So, when we first started working with them, we were kind of thinking we would be managing Swarm clusters and Mesos clusters, and then, even before we launched our 1.0, we decided to support Kubernetes, because it was a really good piece of software.
So, we released our 1.0, our first product to the market in 2016, Rancher 1.0, at the time, if I was talking to them, I would have said something like, “You know, it seems like different companies are choosing different orchestration approaches to containers because they need different things from them.”
Some people want to scale really big, like Twitter. So, they’re using Mesos, other people really focused on the developer experience, and they’re choosing Swarm. And it wasn’t really clear yet that one standard was going to emerge, but what we started to see was some stability issues with some of the other orchestrators that we saw as a manager. It was like, “Ah, these things aren’t stable as I would have expected them to be.” What we found is that Kubernetes is really reliable.
So, as we imagined our business, and trying to support these technologies and helping companies implement them, we felt like it was safe to bet on something reliable, and that did require pivot that moved away from messaging, and product development had gone into supporting, we built our own thing, we had Swarm, we had Mesos, we weren’t really sure what orchestration was going to take off. But as we got more comfortable with Kubernetes, and luckily, we started working on it early, it made it really easy for us to honestly commit to something we liked.
By that point, by 2017, we were all in on Kubernetes building on that. And since then, we already had a lot of people using it in our 1.0 product, we also had a really nice base installed, we didn’t just lose.
So, a lot of times, you have a pivot, and it means almost starting from scratch. But actually, we didn’t really lose hardly anyone because it was very much in line with the direction that most of our customers wanted to go as well. Even if they maybe chose a different orchestrator, they also saw the market going this way, so they were really, really appreciative that we gave them a path to get to Kubernetes off of maybe something else they had chosen when the market was still a lot less clear.
We found that that wasn’t nearly as big a problem. Now, what is hard in pivoting, especially, one of the things we built was our own orchestrator called Cattle, and one of the hardest things was actually convincing our own engineers that the Kubernetes was actually superior to what we had developed ourselves.
That’s a hard thing to do because no matter what, if you built something, you’d always love it. And at the same time, in an early market like we were in, lots of people loved the thing we built, a lot of people telling us, “Hey, we really like this Cattle. It’s really good and you should just keep improving that.”
But as an entrepreneur trying to build a business, you have to be really, really honest with yourself, and you have to really look at all the signals, not just the ones that maybe are giving you the positives you want to see.
All the signals told Sheng, and I, and Will, and Darren, that we needed to really focus our business on solving the problem that we thought most organizations were going to have. And that was, how to take Kubernetes to scale, how to bring together a really complex ecosystem around it, how to build a platform that would work.
That meant really having long conversations with our engineers, convincing them if they weren’t excited about this, that maybe there are other things they could work on in our team and finding the team focused on doing this.
It worked out great, but it was not trivial. We have a small team, I can only imagine when you see big companies today trying to pivot to Kubernetes, you’ve got years and years of customers install base, and how difficult that might be for them.
Pricing
Michael Schwartz: Great. It takes a lot of leadership. Most sizable organizations are using Containers today, so if you can sell to anyone, it becomes sort of challenging, so who do you sell to? I’m wondering, do you segment the market at all?
Shannon Williams: One of the nice things about open source is, it has allowed us to, give an idea most, I would say the 300 Enterprise customers, like every quarter now we’re closing about 50 new customers. Every quarter we are closing, we look at what the source of those are. I would say 30 of the 50 came from open-source Rancher users.
They started with open source, they used it at a business-unit level, or line-of-business level, and it became important to them, and they needed support. Those deals, they are not very competitive, they’ve already kind of looked at Rancher, they have a relatively short sale cycle, they’ve done the proof-of-concept – we don’t have to go in and prove that Rancher is the right solution for them.
What we found is that we don’t really need to segment that. The product pricing was probably the most important thing to segment. We did find that with such a huge install base, one of the mistakes we couldn’t do is, we couldn’t support everyone for free, for a small amount of money. We needed to kind of keep a relatively medium-sized bar, to ensure that people who needed support had to make an investment to get it.
For example, we could have gone with a lot of SaaS models, $10 a month or something like that, but the reality is, infrastructure and Containers, Kubernetes – these are all really complex. The support is quite real. We provide a lot of advice, a lot of architectural help with these organizations doing it. So, there was a real risk that we would price the product so low, and that we would then be trying to do this for lots of companies with very different levels of technical skills.
I’d say, the closest thing we came to segmenting the market was providing a lot of free open-source support for people who are trying to figure it out themselves, but then, charging a reasonably significant fee to come in and get support. Our customers had to invest tens of thousands of dollars on an annual basis to get support with us.
By doing that, it allowed us to work with companies that really valued this. We’re investing their time and the money into making it successful. That was really the best qualifier. It allowed us to focus on teams that really could help us grow the business at the same time.
We’ve seen some industries become really big with Rancher, but it’s more just a sign of who uses Containers. It’s companies, and certainly the internet, and the technology industry, but there’s a lot of financial services, companies, fintech companies, biotech companies, universities, research organizations, we’re seeing adoption in government and military use cases. It’s really broad now.
Retail, Edge’s driving, all sorts of interesting use cases, oil and gas, all sorts of interesting use cases in manufacturing, automotive – just lots of cool things that people start to imagine, a model where Kubernetes becomes this grand unifying theory for computer, where it runs everywhere. It runs in their single node, base station, it runs out in the windmill farms, it runs in Chick-fil-A shops, it runs in factories, it runs on cruise ships, it runs in data centers, it runs in the cloud. It’s a really exciting time to be working on tech, I would definitely say that.
Pricing To Value Ratio
Michael Schwartz: Normally, it’s really hard to get pricing right. Did you have to pivot your pricing model a couple of times? Or how was your experience like, figuring out what are the right price points?
Shannon Williams: Oh, man, that is a good one. We learned a lot from our last company. I made every mistake you can make last time. This time, we definitely had to pivot a little bit to be quite sure what the right element was to scale on with the number of clusters, or containers, or nodes, or CPUs, or things like that, but we decided pretty early on that the size of the implementation was probably a good way to judge how the cost should change from a small deployment to a large deployment, the number of hosts and servers, things like that.
Actually, I would say we learned a lot, we’re fortunate, that were a lot of indicators from the market, as people talked to us I would say. Your first 10 – 20 customers give you a lot of feedback on pricing, whether you want it or not.
Usually, I think most people price to low, just by nature. We all want to just make it both amazing and cheap prices. Like, who wouldn’t love this thing? It’s the best and it’s the cheapest. But you have to be realistic about what it takes to fund a business, what it’s going to take to build a profit, and what you can do with those engineers you can hire, and then you have to convince people of the value. It can be tough.
I remember I walked away from a lot of deals in open source. I just said, “I’m sorry. I totally appreciate that you’re telling me you could use the software for free, so you couldn’t possibly pay me more than $10,000 or $20,000. But if I did that, I wouldn’t be able to build a business, I wouldn’t be able to write open-source software, and I wouldn’t be able to give you the level of support you demand from your other enterprise software vendors. So, I’m sorry, we can’t do business with you.”
And sometimes they come back, sometimes they don’t, but being willing to walk away from deals – for our business model, it is absolutely critical to have to be able to do it. Otherwise, again, the car I’m selling you is available for free. You can take the same car with the exact same features, you’re not paying for a special version, it doesn’t have a better horn or better tires –it’s the exact same car. What I’m offering you is the confidence of working with me on it, and the world’s best support for that technology. If you don’t value those things, then, we can’t come to any business relationship between us.
Technology Partners
Michael Schwartz: Have you used partners to help you deliver to customers, especially globally? Or are there any other business partners that have been important for you to build a business?
Shannon Williams: Yes, yes, yes, yes. Over and over again – yes. The critical partners for us have been really two big buckets. We have found that the other companies who are building critical technology for teams adopting containers. It’s a company that’s called Portworx that builds a really nice storage, and a company Aqua that builds great security, Sysdig who creates monitoring, Gitlab who does really cool tools for CI and Git deployment – all really commonly chosen by our customers.
But partnering with those companies, companies that fit into the same solution stack, we have been able to do two things: we’ve been able to build a much more credible solution for our Enterprise customers. And we’ve been able to align messaging and go-to-market together, and take maybe a couple of other organizations who are our size, venture-funded startups, and take our stories, and show them to larger organizations together.
And we would’ve done this through, we’d run online meetups, where our partners come and present to our users about their technology, and how they work with Rancher, and how they work with Kubernetes. That gives us a lot more credibility, and helps those company succeed, which helps the market grow because the market is vibrant. So, we invest a lot in partnering. We’ve also partnered really closely with the cloud providers.
We work really closely with Amazon, Google, and Microsoft in the U.S., and large providers around the world, to ensure that their implementation of Kubernetes works really well with Rancher. And that’s been fundamentally critical, especially because what we see is we see a market where, if you are in the cloud, you are probably going to use the cloud providers Kubernetes.
So, we want to make sure that we’re not trying to convince you to use Rancher’s Kubernetes on Google, take Google’s Kubernetes engine, which is great. Let us provide you with the common frameworks, whether using Google’s in Google, and Amazon’s in Amazon, on premise and Edge, or different types, everything is consistent, everything is managed the same way, everything is deployed, monitored, upgraded consistently. And you have a platform that really is this UberCloud we set out to build in the beginning anyways.
Integration Partners
Michael Schwartz: If a customer says that services aren’t enough, they want on-site engineers, they want sort of higher-level design consulting – do you do that as expert services, or do you work with delivery partners to do that?
Shannon Williams: We tend to work with delivery partners. We work really closely with both big and small delivery partners who had built expertise. In Rancher, we have a platinum partner program, which is made up of some amazing companies that have implemented Rancher for others multiple times, and really have deeper understanding often not just of our ecosystem.
So, companies like RoundTower, CloudOps, Readapt, Accenture. We work with quite a lot of the large multinational services companies. We work with different regions around the world. These companies, BoxBoat and other really good ones, these guys, they’re really staffed to provide ongoing services for organizations in a way that we’re not.
Like, we are great at coming in and giving you a ton of information about Rancher and helping your architect your Rancher deployment, but a lot of times, technology is only a chunk of the solution. The solution needs to include some transformation of how you do things, how you do DevOps, how to train all your developers around microservices, how they start thinking of some of these new service matches, and how they might get into solving business problems for your company.
We can point you in the right direction and help you with those things, but we’re very laser-focused on the Kubernetes platform. And these companies are much better than we are at providing the transformational experience around there. So, yeah, we very much partner, especially in those longer-term things.
What we have found as really critical is the actual investment of our own on customer success. I would say, one of the things that’s got a lot better as we’ve grown is, we’ve invested more and more in — I think it was like the first 90 days when an organization becomes a Rancher customer.
I think this is really important for open-source companies because if you are a SaaS provider and somebody’s using your product, you have a pretty good idea what they’re doing with it. But as an open-source software companies, especially ones that support that open-source software, organizations can have very different processes, they may have more or less mature implementations, they may or may not have built-in an HA deployment. And they’re coming to you to provide support. You really need to make sure they understand best practices, that you reviewed their deployments, you helped them understand how we recommend doing things.
We invest a lot more now in customer success than we did in the early days. When a customer comes on board, we really spend a lot of time going through their architecture, helping them make improvements that they will achieve their goals, whether it’s stability, multi-cloud implementations, or they might try to do something, there’s a lot of scale. And then, there might be something we’ve learned already that can help them. I would say customer success has been a big learning for us.
Net Retention
Michael Schwartz: Has that investment in customer success also translated into increased revenues per customer year-over-year, so they’re buying more, or other products, or other divisions?
Shannon Williams: Well, it’s still new enough that I wouldn’t say if I know how correlated those two things are, but we certainly believe they are. We are investing in it because our bet is helping a customer be successful, with even a departmental implementation or a single app deployment is going to pay dividends for both retention of that customer and that workload.
So, a year later, when they decide they want to renew that support they bought last year, they have a really good feeling that, “Yeah, that was a great investment. Partnering with these guys has been useful.”
But certainly that also works internally. As they use it, they seem to spread the word. I mean, we have seen over and over and over again the power of the success of a Rancher deployment spreading within a company.
Users love Rancher. It’s a user-oriented product. What’s so cool about a product that has 30,000 open-source users is, it says something about how usable it is. It’s like terraform, you use it, it’s pretty straightforward, you like it and you go, “Cool. This is easy. I can get this.” You tell your friend, “You should use terraform. It would help you do something.” It’s kind of same with Rancher.
If all those users are using it, they are clearly getting some value from it. When somebody in your company says, “Hey, use this.”, and you’ll probably benefit from it. And there’s no barrier. I don’t have to start by going and getting a license to try it. I can just use it. It tends to spread the same way. It’s just the word of mouth and the power of it kind of spreads.
So, we found that making them successful and making sure those early champions are well-armed to explain why they chose Rancher, and they got a really good implementation, they don’t get bitten by a bad config, or maybe not knowing the best practices, it helps us in the long run for sure.
Cloud Strip-Mining
Michael Schwartz: I’m sure you’ve been hearing about open-source strip-mining from large cloud vendors, but what I’m wondering is, do you think it would be good or bad if some mega cloud company offered a Rancher-based service?
Shannon Williams: I think it would be great personally. From our perspective, the value of these mega cloud providers is always tied into a big ecosystem that they’re trying to build around. What we find is that organizations want to live in those ecosystems, and leverage those ecosystems, but they know they’re not going to live in just one of them. So, they want lots of them. And the more that those ecosystems interact or work together, or do things that help them work together, the better off they are.
In so many ways, I think the strip-mining analogy is that it’s a rough analogy because, well, it’s true that some of these providers don’t put a lot back, and there’s definitely been some ugly competition between open source and commercial. For the most part, I think their relationship has actually been pretty beneficial, mutually beneficial between the cloud providers and the open-source software developers.
It’s often where it’s really struggling, where you‘ve seen it’s struggling is when organizations haven’t had a great business plan our route to market, or they haven’t been able to commercialize their own products. And then, all of a sudden, it gets embedded into something larger. And then, the only monetization of it happens in the cloud.
I think that’s where we see most of the problems. I think that’s going to continue. I think that that was happening before as well. You know, ideas are developed, but are never really taken to market fully or are not pushed into the market aggressively. Organizations build upon those something new, or something tangential, or something that accelerates them. And that is what ends up being the big success.
To me, that’s business. That’s something that’s going to happen in any space, whether it is open source or not. And, yes, in our world, people can take and build on it very easily, but that’s what you know you’re getting into when you’re starting an open-source software business. And if you don’t, you really should research a little bit more.
This is a knife that cuts in many ways, from a business perspective. And I certainly would look at the world, and I certainly wouldn’t call foul if that happened to an open-source project. I’ll give you a feel, in China, Rancher is incredibly popular.
From early days, my co-founder Chan grew up in China, and so, you have someone who can speak Chinese and talks about it in China – Rancher became really famous. We’ve had multiple times where startups have kind of emerged competing with us in the market, selling Rancher and providing support around it.
Our experience has been that that, as long as we continue to push forward the innovation and organizations really value what we do, they’re going to want to work with us. They are going to benefit from working with us.
As long as we keep pushing it forward and building the product better, that will continue to be the case. But you have to know what you’re getting into. I don’t feel like there should be a huge shock if you build an open-source product, and someone forks it, and does something cool with it, that’s kind of the idea.
When To Use Open Source
Michael Schwartz: Moving to slightly higher level, do you have any thoughts about when entrepreneurs should use the open-source development methodology to develop a commercial product?
Shannon Williams: For me, I think it’s about the product you’re trying to build, and what you think your route to market needs to be. If you’re entering a market that you think is pretty competitive, and has a lot of different products, and you know you’re going up against much more well-funded organizations than you, then, I think open source is a really, really important one to consider and to look at. Because it allows you to get adoption in what would otherwise be a really hard market.
If your only feedback is going to come from a handful of companies you can convince to POC you or pay for it early on, you are going to have a hard time building momentum. And you’re going to have a hard time having good conversations with users who either like or don’t like what you’re building.
To me, I don’t know, I’ve been building nothing but open source for 11 years, so it kind of feels to me like everyone should just build open source. I don’t find that it’s ever slowed down our monetization. It’s always been a benefit. But I certainly would say that if you’re building something that you think is transformational, that actually has a broad audience that will adopt it, open source should very much be what you’re considering.
If you’re building something that’s probably a service, and it’s going to be hosted, I think open source can be enabling capability, but I wouldn’t worry too much about the open-source side, I would just focus on building the SaaS platform product tool that you are building a cloud service.
Because I think in those cases, open source is less important than it is an on-premise software or fundamental software. You’ve seen with Docker, open-sourcing, and having an open source success is not by any means enough to guarantee a commercial business success, but it puts you in a position where you have a great chance to engage with users, listen to what they think is necessary. Next steps, what they’re excited about your platform for, your product for, and what they’re willing to pay for, and build on that.
Advice For Entrepreneurs
Michael Schwartz: Last question, any advice for new entrepreneurs starting a business around an open-source platform?
Shannon Williams: Of the four of us who started Rancher and started Cloud.com and everything, I’m the non-engineer. My role in the early time of building a company, I was considering my role then to be how to connect with users, like how to connect to people even before you have a product.
When we were in our first 6 months, our first year, I spent all day, every day, thinking about who are potential users could be, based on the direction we think we were heading, and reaching out to people, introducing myself and introducing the idea we’re building, and getting feedback.
You always have to be thinking about the next milestone of users, “My gosh, how do we possibly get to 10 companies using our product?”
And the only way I can ever found that works to get to 10 is to find them by hand. To think, “You know, I think this makes sense for somebody in that space.” I really believe that if you as a founder can’t explain your value proposition enough to get someone to sit down on the phone and talk to you about it, and maybe watch a demo.
Especially when you can tell them, “Hi, I’m Shannon. I’m one of the founders of this new startup called Rancher. We’re trying to solve this problem, and I thought it might apply to you guys. I really love your feedback. We are not trying to sell you anything, we just want your feedback on what we’re doing.”
If someone doesn’t want to talk to you with that pitch, you might be barking up the wrong tree with your idea. That initial response, if you can’t just explain what you’re trying to build to someone right away, and if you can’t get a meeting, it’s probably worth reflecting on what you’re doing, and maybe tweaking, and then trying some different approaches, trying some different messages.
Because if you can’t get a meeting, it’s going to be really hard to get a sell. It’s going to be really hard to get a user, it’s going to be really hard to convert them into a paying customer.
But if you explain to someone, most people love to talk to entrepreneurs starting companies, especially if they can really clearly communicate what it is they’re trying to solve. And that validation early on goes enormously towards then calling that person back in three months, and saying, “Hey, we got a first beta ready, would you like to take a look at it?” And getting those first 10 is hand-to-hand combat.
Really the first hundred is hand-to-hand connecting to people, showing them the product, showing them the value, and getting to use it. Every once in a while, you have these runaway crazy successes, where everyone’s like, “Oh, my gosh, I can’t believe – how did we live before this existed?” But most of the time, it doesn’t work like that. Most of the time, you have to connect, talk, demo, listen to the feedback, and go back and consider how far on or off your strategy you are.
Closing
Michael Schwartz: I said it was my last question, but now you just raised another question, and I can’t resist. Previously you mentioned that a lot of the leads for customers were from inbound, from customers who use the software, liked it, and then called you to purchase a support subscription. But 50 deals a quarter – that’s a lot of business. That’s really pretty stellar. And I’m wondering, what’s the right mix of inbound and outbound marketing sales to push for, or how do you balance that?
Shannon Williams: First step for all of this is find a real market. When you find a real market, things get a lot easier. Because you have to have something going on that’s causing people to look for a solution, they have to have a problem.
So, to your question, if I had my druthers, I’d have a 100% coming inbound, so everything coming inbound means that the market is actively looking for solutions. My brand is well enough known, we are the company they should at least talk to about this to get a demo. Ideally, it’s open-source, just download it, and install it, and try it, and see what you think.
I, from day one, believed in inbound as our goal. So, that meant, instead of spending a lot of our early dollars on advertising, for example, I spent almost everything we did, online communication to users. And that meant, oh, my goodness, we wrote dozens and dozens of pieces of content explaining how to use Containers, and Kubernetes, and Docker, to help people find us.
They may not be looking for Rancher, but they were looking to solve a problem. And so, we really tried to build a list of the lots of the problems they were trying to solve.
We hosted an online meet-up every month that grew to have thousands and thousands of people register every month. It was crazy. We just run them today – I just did one last week.
And what we said was, “Hey, come, it’ll be our smartest technical people. We will stay as long as you need. We’ll demo whatever it is we say we’re going to do. I won’t just show you a bunch of slides, we’re actually getting this code, we will teach you how to do it. And we will stay until every Kubernetes questions are answered.”
So, these things would run two hours, three hours, but they allowed people to cross hurdles, to learn how to build the CI/CD Stack on Kubernetes, or how to do monitoring on it, or how to deal with logging, or how to use containers and the cloud – whatever it was we were trying to solve that month, we really focused on it. It was really that. It was education, community, content that, coupled with early references that we built by hand, in that hand-to-hand phase, got the word out.
By continuing to invest in that, we were able to kind of sow so many seeds of open-source users that as they matured, and liked what they usd, they contacted us. The right mix for me is a 100% inbound from the open-source community. But what we did find was, as we grew, we started to run into bigger organizations. They have entrenched vendors.
All of a sudden, we might have won a line of business users, and then they just said, “Hey, we love this Rancher. We are going to use it for application A, B, and C.” But 80% of the company was using something else that they’ve maybe built themselves, or maybe they bought something, some other product a couple years ago to do PaaS, or something.
And so, because those organizations started to look and say, “Why aren’t you using this? Why are you using Rancher?”, we had to support them and show other people in the organization, “Well, actually, this isn’t the same. It’s different, and here’s why it’s different.” What we did find was there was longer Enterprise sales cycles, so we needed good high-quality sales people to work with bigger companies.
But the positive was, we found that those companies actually really appreciated that it was open source. And the fact that you already had one over, a group of people who really loved it internally, meant that you kind of solved, in a lot of cases, the biggest problems these IT teams were facing, which was, they were building stuff and no one was using it anyway because they were just going to the cloud, they were building something themselves.
So, when we could tie together, the IT organization, which is like doing everything they can to support forward-looking development while still being secure and still being cost-conscious. And teams that have usage and feel like they’ve got found something cool, it was just like made it for a much easier sales motion than your traditional either selling top-down or kind of getting some executive buy-in, and then hoping people use your product once it was brought in.
I don’t know, does that answer to your question, Mike? I kind of feel like I ramp up there.
Michael Schwartz: Yeah, that’s lots of great info. Shannon, thank you so much for joining us today, and being so honest with your answers.
Shannon Williams: Mike, it was my pleasure. Thanks for doing this. I love your idea of open source entrepreneurs just sharing and talking about what we do. I think it’s a phenomenal business model. It is a real transformation of the relationship between the developer of a really powerful software and the consumer of that software. So, it’s something I have enormous passion for.
Michael Schwartz: Best of luck with Rancher, and congratulations on all the success.
Shannon Williams: Thank you so much, Mike. You too. Have a great one.
Michael Schwartz: Thanks to the Rancher team for making this happen. Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie. Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.
The Twitter handle is @fosspodcast. Rate us on iTunes if you like this episode.
Next week, we have James Waters, SVP of Product at Pivotal. Until then, thanks for listening.