October 20, 2015
Ep. #5, Overcoming the Fear of Shipping Code
In this episode, Edith and Paul talk about the fear of shipping, and whether code is an asset.
Thanks for having me on Election Day. Raise your hand if you voted. Excellent, it has nothing to do with the talk but I just wanted to do a quick survey and guilt trip you all to go vote.
Quick disclaimer, everything in this talk is my personal opinion, theory, and conjecture. If I say anything semi-intelligent I probably copied or stole the idea from somebody else.
The truth is, this framework called Unit Value, it's a framework and with all frameworks, it's one that I use to value companies as a Venture Capitalist and it's one that's always in the process of being refined and improved upon, so any feedback tonight is going to be part of this growing process around this Unit Value framework.
A quick introduction of myself, more so you can understand the biases I'm coming from and how I look at the world. I'm an investing partner at Greylock, which is a venture capital firm that's backed both consumer internet companies like Facebook, LinkedIn, and Pandora but also large enterprise software companies from Workday to, more recently, I led an investment a year ago in Docker, which is a open source container technology.
Before spending the last year and a half at Greylock I spent almost 10 years at VMware. VMware, obviously the category defining virtualization company. I joined in 2003 as an intern originally when there was about 150 to 200 employees, then full-time in '04 and was a part of that ride through the IPO until there was about 15,000 employees and over five billion dollars in revenue.
But while I was at VMware, running different products, I basically perfected this go to market framework as a product manager, first launching our VDI, or Virtual Desktop Infrastructure business from zero to over a hundred million revenue.
But then specifically the last four years I was there, I helped build our cloud application platform, launching an open source PaaS technology called "Cloud Foundry" and then we acquired several developer tools, the Spring source framework, middleware technologies, a bunch of data products around intermediary databases, running Postgres on vSphere, Hadoop on vSphere.
I've been fortunate enough to look at the technology landscape both from a low level infrastructure, storage networking compute standpoint, as well as a application infrastructure viewpoint.
Unit of Value.
First, to set the stage, in this battle of David versus Goliath, you have the big Davids that always change every time from small startup within Heavybit, but the Goliath has been Oracle, Microsoft, EMC, Google, Facebook; pick the Goliath you want to take down at any given time. What are the weapons you have or what are the strategies you think about when taking down a Goliath?
To channel someone smarter and more successful than I am, I'll quote Aneel Bhusri, who's my partner at Greylock as well as the CEO of Workday. Aneel likes to say that this race between startups and incumbents is really a race between distribution and technology.
So as a startup you have better technology, right? Innovative deep IP, but the incumbents have distribution, namely they have a sales force, they have a channel, they have partners, they have existing customers.
It becomes a race between you, as the startup, trying to build distribution, build a channel to bring a product to market versus the incumbent buying or building the technology to take you out. That's a classic race. We've seen it play out in Silicon Valley, this race between how to scale or go to market quickly enough with a product.
So we call this Go To Market or GTM and the question is why does Go To Market matter? Why do I, as an executive at VMware or as an investor at Greylock think about Go To Market?
First of all, Go To Market is the hyphen in product-market fit. You often hear VCs or executives saying, "You don't have product-market fit. You've got a great product, you know what market you want to go after, but how to get your product to market?" That's really the crux of Go To Market.
Secondly, from an investment standpoint, determining your Go To Market really impacts how much money you need to raise. So if you need to build a large direct sales force, like hundreds of reps or a large inside sales team versus indirect team, you need to raise more capital.
Thirdly it determines your profit margins at scale. So the heavier the Go To Market, the more bodies you need to throw at selling the product, it's going to impact your sales and marketing expense and your gross margin, operating margin.
Most importantly what the key takeaway here is your cost of distribution, be it direct sales model, indirect sales model, has to match what your customers are going to be willing to pay, right? And you've got to be thoughtful about this not at the start of day one of your product but also day 300 or 3,000 of your company or product.
So here's a quick laundry list of things you're going to hear when people talk to you about Go To Market. They ask about your channel, do you have resellers? Do you have partners? Do you have folks selling it?
On field ops, you have SCs, sales engineers. Do you have direct sales forces? Which are pricing? Which are packaging? Who are your biz dept. partnership? Are you going to do a deal with Google or Facebook or VMware? How are you getting awareness? How are you getting trial and adoption?
Open source technologies often are all about awareness and trial and each of these bullet points are worthy of a talk in itself but today I want to focus on this framework I call the Unit of Value and to be thoughtful about the Unit of Value in each of your companies tonight.
So what is the Unit of Value? The Unit of Value defined, its a noun in my mind, it's the smallest measurable unit at which your product delivers value. Your product could deliver value at huge scale but the unit value is the smallest scale, smallest unit, smallest amount, your service, your product that actually delivers value.
Secondly, it's the scaling unit as to how you kind of increase your product in pricing and services. It's the widget that you're producing. It's the car of your Ford. It's the bags of Doritos, if you were selling chips.
Thirdly, quite frankly, it's what your customers pay for, right? They're paying for a value of x, they're paying for a value of y. Servers, storage, databases, API calls. Be thoughtful about that Unit of Value because it's how your price, it's how you scale, it's how you sell your product to your customers.
So, Unit of Value can vary from small to big. So, starting from small, you could have a single Unit of Value, meaning that you get value at a very, very small level.
For example, Dropbox, raise your hand if you use Dropbox or other file sharing tools. The Unit of Value is one person, one user. You get value from Dropbox alone, you don't need anyone else in the world to be using Dropbox, you get value yourself sharing files.
VMware, in the early virtualization days, the Unit of Value was a single server. You installed VMware in that server, it can run ten to twenty virtual machines.
Docker, the value is not necessarily one server, in my mind, it's one container. It's one application wrapped up in a container because the real value of Docker is moving that container from one laptop to one server to one cloud.
But there's other things besides infrastructure dev tools like Office Suite- Word, PowerPoint, and Excel. The Unit of Value of that productivity suite again is one user. It doesn't matter if the rest of your company is on it or not. You can use PowerPoint, you can use Excel, you can use a word processor yourself, so a small Unit of Value.
There's what I call Medium Unit Values or Small Teams, so something like Salesforce or CRM software, really three to four sales reps is necessary. If you're a single sales rep, having Salesforce.com or SugarCRM makes no sense, right? Who are you communicating your sales pipeline to? Really the Unit of Value is selling to a small team of sales reps.
Secondly, Box, SharePoint, Wikis, anything that's kind of like collaboration or communication. Again it could be a team or a line of business. It's a Unit of Value that's a handful of employees, your developer, your companies, but it doesn't have to be the entire company, the entire Fortune500 enterprise.
So let's talk about big units of value. Hadoop by definition, big data. So you really only get value installing Hadoop cluster when you're talking about terabytes and not a petabyte of data.
Mesos, which is clustering software, again you can run Mesos on a single server or two servers but really the Unit of Value to get the most juice, the most bang for your buck of running Mesos, is a cluster of servers in a data center.
A lot of enterprise applications, Workday and Human capital management or HR software, the entire company is the Unit of Value. You don't sell HR software just to one department of three or four people, you have to sell it to an entire company. Same goes for ERP, financial software, a bunch of the enterprise apps, the Unit of Value is the whole company or nothing at all.
Now, there's no right or wrong. You can have a big Unit of Value or a small Unit of Value and every company here may have a different size or a different unit for the Go To Market. Bigger is not better, smaller is not better.
What bigger means is you're going to have a longer sales cycle, so if you're selling an entire company, an entire cluster, a big data cluster for a terabyte of data, there's going to be a longer sales cycle and bigger deals, but you're going to need a higher selling price to justify that longer sales cycle and those bigger deals.
The question for you, if you have a big Unit of Value is, how do you build the most cost effective sales force to move this large unit?
A smaller Unit of Value doesn't mean a smaller market or worse. It just means you have a shorter sales cycle, people can buy your product from a credit card, maybe it's free, maybe it's 10 cents an API call, maybe it's a hundred dollars per terabyte of storage, but it's a small Unit of Value.
The question here is, how do you create a cost effective channel for the small price point, but more importantly how do you scale up the Unit of Value over time?
I think for the folks in the audience at Heavybit, since most developer tools start at a small Unit of Value, maybe a developer, maybe an application, maybe a single database, how do you scale that up over time?
So really that's the crux of developer technologies and there's a range again, I'm going to take a stab at some of the things out here. IDEs in a lot of dev tools are going to be small. One person, two or three developers, collaboration tools. API services, be it building, push notifications, metering or metric management, that's also a small Unit of Value.
A single API call or a single application, something like New Relic or AppDynamics, this Unit of Value really can start small at a single app. Medium tools, like collaboration tools like GitHub, Atlassian, communication tools, again four to five people, ten, twelve, or thirty medium units of value.
Then large units of value are obviously platforms like PaaS platforms, like Heroku, Amazon Web Services, VMware back in the virtualization days. These are large, large platforms trying to build a cloud infrastructure, those are big selling points or big sales for the customers.
Sarah, our associate, put this framework together, again it's not right or wrong to have a small or big Unit of Value and so, as an investor we think, "OK, can this company get to a hundred million dollars in revenue or bookings?"
There's many paths with heaven. So on the far left, if you have a developer tool or an API service that's like 10 cents an API call. To get to a hundred million in revenue you need to have a billion API calls. That's what you need to do, a billion calls.
Or if you have a very large Unit of Value, you're selling clusters of Hadoop software or you're doing large scale enterprise software at a hundred thousand dollars, then the right models are direct sales force or outside sales force and then all you need is a thousand customers, a thousand deals of a hundred thousand dollars or more gets you a hundred million dollars.
To think about that right, put them in perspective, there's about two thousand companies, the largest two thousand account for maybe 60 to 70 percent of enterprise IT spending. So if you're going to go for a hundred million dollar revenue at a hundred thousand dollars a deal, you really need to get to half of that fortune 2000.
Then you scale in-between, so a hundred dollars per product, per Unit of Value, is more consumer self-service, right? A million again, a million sales, a million deals, a hundred dollars per, you get your hundred million dollars.
The ten to twenty thousand dollar mark is more self-service, inside sales reps saying, "Hey, here's our free trial," because it's an open source product and they call up for sales and support. But in the middle, there's kind of a no man's land dead zone that I've been talking about as an investor, that your Unit of Value, your average deal size isn't that big, so your not getting any of the largest deals.
But it's not that small, like ten cents an API call to be really frictionless, so you're hovering around this kind of ten thousand dollars plus or more average deal size and what happens is, you need to get ten thousand customers to hit your hundred million dollar revenue when you're a mature company.
But it's a dead zone because it's very hard to find a business model that can productively do that time and time again.
So for the experience we have as investors, we see things either on the far left or the far right, things in the middle we haven't seen work out.
Let's take the far left now, for the small Unit of Value. Now you can have a ten cent API call and you have thousands and thousands of users doing it. What tends to happen, even when you have this small Unit of Value, handful of customers generate a majority of your revenue over time as they scale up, and we're going to talk about scaling up in a bit.
Here are two companies that have had their names changed to protect the innocent or guilty in this case. The first one is a developer API service and they have a price in the pennies per API call. But 50 percent of their bookings on a monthly basis are from customers doing over 25,000 dollars, 200,000 dollars in deal size. So that means their unit value is small, 10 cents per API call, but somehow they've been able to scale up customers to do 25,000, 50,000 dollar deals which, if you remember, from here, starts to look at this inside sales rep category.
Secondly, our other company is a cloud app infrastructure, a data storage service. They have over 50,000 users, developers, but the average monthly customer is still small, about 50 dollars per month, but five percent of their customers could count for half of their monthly revenue.
Think about that, the average deal size per month is about 50 dollars per customer but customer concentration is so heavy that only five percent of the customers are half of their monthly recurring revenue.Again, they're on this side of the spectrum, right around this "Consumer Service," but somehow they were able to scale up a handful of customers to be very, very big and charge more.
So, the crux of this question is how do you do that? I call this, "Hw do you create non-linear value out of your product?" On the x axis you have the sum of the units. Consume, buy, your customer, and the y axis is the value, so I say value not revenue, not bookings, not price because you're going to create value for the customer.
The ideal in any pricing negotiation is how much of that value can you create or how can you capture? And that's how you charge on pricing. That's how you negotiate the deal. But this is value generated for your customer.
For some products, some services, it's a perfectly linear Unit of Value. I could argue, office productivity suits maybe, maybe some file storage, as you get more, consume more, the value just goes up linearly. But for the Holy Grail of any company here, you want to think about how to create non-linear value over time so as your customer consumes more of your product, more of your service, they're digesting, they're creating, they're consuming more value from you.
That matters, and that matters because for one, obviously when creating more value, you can charge more for your product.
Number two, it becomes defensible because if you're creating a ton of value, if a competitor comes in and you're creating this much value, he or she, that new startup, that new competitor, has to create that much value to replace you or displace you.
If you can scale non-linearly and create a lof of value for your customer, it gets harder and harder for you to be displaced.
So let's talk about being non-linear.
Here are three things to think about and then we'll talk a little more on framework and how to start creating the value.
One, the more they consume, the more value that you receive. Two, a very common way, especially around developer tools being non-linear, is additional products, additional ways into the enterprise. Typically at scale you're going to be selling management tools, monitoring tools, security tools, and we can talk about other kinds of add-on products that are often associated at scale.
That's not the only way but it's a very common way for you to think about your road map. What do I sell on top of my product, adjacent to my product, to create non-linear value?
But almost as important as what you're selling or what you're building is who you're selling to. So you might start with a developer, you might start with a dev ops or a system admin, but as you scale up to a large consumption volume, you're going to be selling to the CIO, definitely the CFO if the check size is a hundred thousand dollars or more, maybe the CTO, maybe the Chief Security Officer; so be mindful that as you add more products, the persona who you're talking to also changes.
In addition to adding new products, there's kind of three large ways of thinking about non-linear value, again, these are not meant to be exclusive and they're not exhaustive, but in a thumbnail sketch, you'd think about network effects, building standards, and building a platform.
Network effects, you've probably studied Metcalfe's Law. Basically, the value of the network is proportional to the square or the people using them and that just means, like on instant messaging or WhatsApp, the more people using it, the more value you get.
E-mail is the classic example as to how the internet grew in the early days and through communication, but more recently, you think about Slack in terms of productivity tools. Obviously GitHub has more developers, more open source projects are on GitHub, as more and more people use it the value of this product goes up in a non-linear fashion, the basics of network effects.
The second thing I like to think about as an investor is, "Can this be a standard?" or, "How hard is it to be a standard inside an industry? Inside a company?"
When I talk about standards, I talk about the technical standards and de facto standards. So technical standards are those things you create or abide, IEEE or the Java Committee. Slow, boring and they kind of set the frameworks and the rules.
De facto standards are really what I'm talking about and a de facto standard is how do you within a company, within a market, within a country, within an industry. How you become the de facto standard of how people think about sending storage, sending messages.
How did Amazon and those Amazon APIs become the de facto standard for cloud services? You might of heard this.
The "60/30/10 rule" that a lot of technology companies end up being at maturity- the main winner, owning 60 percent of the market, the number two player owning 30 percent of the market, and the rest of the competitors owning 10 percent.
This de facto standard concept combined with network effects and everything else, tends to lead the winner of every industry to get a majority of the market share. Oracle relational databases is kind of the classic example in the early days of how they over time became the de facto standard in applications and got 50 to 60 percent of the market share.
De facto standards are also driven by other factors and here's a couple of speaking points that are not exclusive, standardizing on a single product, new technology, and reducing complexity. I want standards on Go, Java, on the DotNet shop.
It reduces complexity, reduces cost because I, as an enterprise can now say this is my standard. There's standards for being a single pane of glass. So a lot of monitoring, management, security tools. Really the de facto is, I don't look at four or five dashboards, four or five products to understand what's going on, I want a single de facto standard on how to manage and scale my applications.
Office suites are kind of the classic example of this. In the early days, you don't get a whole lot of non-linear value when an entire company uses Microsoft Word, but all of a sudden there is some light standard effects of having the Doc format or the PPT format being the lingua franca of how you share documents and all of a sudden, that complexity; that friction of switching between Keynote and PowerPoint goes away because we're all on PowerPoint or all on Keynote.
Now, de facto standards can change, both within a company and in an industry and it can change pretty fast. I think the browser wars are the classic case example of how this can change fast. The Netscape Navigator, for those who remember, was the de facto browser for many many years and IE was nowhere. So this browser, this user interface between these and the rest of this thing called the world wide web, the internet, threatened the Microsoft franchise.
If we remember, in the anti-trust suit, Microsoft had this memo saying that, "We just need to get the 30 percent market share of the browser wars and the rest will take care of itself." What they really meant was, as long as you get to some reasonable market share, about 30 percent in any market, that de facto standard of Netscape Navigator is now broken.
They're not going to own 100 percent of the market. You're relevant enough that they have to support both IE and Netscape Navigator.
So even if you have a de facto standard within a company, it could flip. Even if you have a de facto standard within an industry it can go the other way as well.
Now, the third thing I was going to talk about is platforms. Platforms are the longest, the hardest to build, but also, you get the most economic rents if you build them correctly, so operating systems are platforms.
Also cloud platforms are platforms to talk about. VMware Virtualization is a platform. Docker's trying to be a small Unit of Value and create a container platform. So there's two or three ways to build a platform and again, they're not exclusive.
The first is what I call, a "system of record." More or less, a system record is data, it's a data base, it's a set of information that your company runs on or applications are built on. So with any large enterprise I would say there's three system of records that really matter.
There's the customer record, like who owns your customer? Who your customers are. There's employer record, who works for you? Who are your employees? How much do they get paid? What are their titles? What order they're in? Where are they in this planet?
The third is going to be your assets- Manufacturing days, it's basically my inventory, my work in process, my finished goods. For knowledge industries or process industries it's going to be more assets, financial.
So if you're an investment bank, you care about your balance sheet. If you can own any of those systems or records, you can build a platform. Classic example here is Salesforce.com owns your customer record. Workday owns your employee records. Oracle or SAP tries to own your financial or asset records.
So Salesforce built Force.com, this platform on top of their customer records so you can build applications. Once you own that data, once you control that data, all of a sudden you can build analytics, third-party applications, and share that data in broader ecosystem. You own a platform, you can create non-linear value. Same thing goes for getting your employee record and same thing goes for your financials.
Now you don't need to own a system record to build a platform in this space. You can be adjacent to it. You can be on top of it, but in order to build a really large platform, you have to figure out how to get your hands on a system record.
The second way to build a platform is to be that glue, that intersection between multiple layers of technology. That can be the app stack or it can be an infrastructure stack, so operating systems, virtualization.
Docker right now has a chance at this layer to be that glue between infrastructure- Storage, networking, monitoring, management, security. VMware for the better part of fifteen years built this glue layer at the hardware in the virtual hardware layer and became a platform.
Now everything below them e.g. hardware, had to work with VMware, everything above them, system management, had to work with Virtualization and they became this nice platform for you to build backup, security, storage, applications on top of it.
So when I looked at Docker as an investment from Greylock's perspective, I had this theory that this layer we built at VMware for fifteen years was going to get de-layered and broken apart in the scaled out cloud world and that all of a sudden, there was going to be a new platform intersecting all these technologies.
So I think about Docker and this "next gen" cloud infrastructure space as the potential to attack this layer. Then finally if you look at application platforms, Amazon Web Services, Google Cloud Platform, Microsoft Azure, they're really trying to do a bunch of things by being both a system record e.g. storage of data, offering you databases as a service, offering S3 on Amazon for storage and by trying to become this glue layer by offering middleware, messaging systems, database systems, and monitoring systems to connect you from different levels of applications.
Yet in this cloud world, this glue layer not only goes up and down in terms of infrastructure, but what I call East West, but now you're connecting other applications, other API services, other startups in this broader ecosystem together.
I think Heroku did a great job in the early days with their add-on store, trying to be this nexus, this glue layer between cloud servers and the cloud APIs.
You can try to be the customer standard. You want to be the standard for storage layers, standard monitoring layer, standard API framework for measuring calls to third parties. Be the standard within the company.
It helps when you're the industry de facto standard because people will say, "Hey, we have tp buy VMware, we have to buy Docker," but become the customer standard because there's value at that point and once you become the standard, you start to create non-linear value, then as you scale up consumption, sell additional products, management, security, and monitoring; these enterprise products that build on top of your core Unit of Value of being a standard, but are necessary as you sell to a CTO, CIO, CFO.
Finally, as you become a large enough platform, that large enough product is consumed in mass quantities by your customer and you're doing that across the industry. You can then try to create a platform ecosystembecause once you're everywhere, once you're on every PC, every server, every cloud, all set in third-party companies, be it other developer services, other technology services need to work with you to get access to your customer.
So again, putting it all together, this is not the only path to create value or non-linear value but it's a path that you think about. The most important thing I want to say about this slide as you think about creating non-linear value is make this a conscious choice.
Don't expect to fall into your Unit of Value. Don't expect to fall into your Go To Market strategy because if you're waiting to discover it, just waiting for a customer to come, you tend to find yourself being pushed into a Go To Market strategy or you're going to be pushed into a Unit of Value by either A- your customers, B- your partners, or C- a competitor.
Often times, you're feeling because you just do what your competitors are doing, you're going to charge on the same unit they're charging on, right? But if you can change the game dramatically on how you charge and how you Go To Market, you can be highly disruptive.
A classic example would be to go back to the Office suite. Microsoft sold Word, Excel, PowerPoint on a per user basis. Google gave away Google Docs for free but charged on a different Unit of Value, it was eyeballs. They were monetizing your attention in terms of ads and search, so make it a conscious choice of your Unit of Value.
The other takeaway here is, don't be afraid to iterate. You're gonna iterate in your product and you'll iterate and try to fail fast on your technology. You probably don't have as many different options or different cards to play when you think about Go To Market, but don't be afraid to try things, have hypothesis and then walk away from it if it's not working.
A summary of questions on takeaways and how to make this actionable for you tonight or tomorrow.
One, sit down with your team with whiteboards. What's your Unit of Value? What is that small subatomic unit of a product, of a service, of technology that our customers are consuming, that delivers value? Just be honest about it.
Do we add value at a single laptop? A single developer or really it's five developers? It's an entire application, it's an entire data center, what's your Unit of Value?
Second, how do you increase value as your customers scale? The first answer may be nothing. We're an API call for machine learning or something and as it scales consumption, it doesn't scale up and that's fine as well, but be honest about it and think, "OK, how do we change that curve from going linear to non-linear?"
Once you figure out if you're going linear or non-linear or how you get there, make sure that your Go To Market strategy matches this Unit of Value.
So if you have a small Unit of Value, small average deal sizes, don't expect to be successful with a large direct sales force. Hiring a bunch of reps, buying a lot of steak dinners, the two don't match up, right? You have to be very thoughtful about how a large Unit of Value needs a large sales force because it can justify it.
A small Unit of Value, you need some cost effective way for self-service, for discovery, for credit card purchases that can hopefully scale up over time as you're being thoughtful. Then as you think about your product road map, you're probably starting at the one technology, one service now. Think about how you start layering or stacking these things on top of each other so that you can create non-linear value over time.
So, I think that's a half hour. Again, feel free to ping me firstname.lastname@example.org or follow me at Twitter @jerrychan or learn more about Greylock and my partners at our website or our blog. With that I'll turn over for questions.
OK, so the two questions are, "Why does that 'dead zone' exist? And our theories around it," and then the second is, "Is the Unit of Value homogenous across your customers and your products or is it different?"
So why does the dead zone exist? I think that's not immutable, it's probably because the cost of support channel, be it direct or indirect right now, in terms of head count, bodies, and support, doesn't justify a price point in that middling area.
That could change over time. For example, app stores in mobile land have changed the distribution costs for getting an app to the end user. I thought long and hard in enterprise software developer technologies that a lot of what you need to pay for at the large unit values, consultants and engineers to customize technology for you to make that work.
I think with a lot of systems and technologies now, they could almost auto-configure, auto-set applications up, you can actually hit the dead zone. A good example would be some collaboration software or communication software that I need to design a workflow, because every company's different. I need to design a workflow for your company versus Fidelity versus Goldman Sachs and that typically is a labor intensive process so you have a high unit value and a large dollar amount.
But let's say I have the ability to mine your e-mail, your org chart, it'll automatically configure a workflow for you based upon some level machine learning. I can look at your traffic, understand and auto-create a workflow for you, that drops the cost to deliver my product, so maybe that can change. So, right now the labor cost and the tooling falls into those two camps and it's not immutable and that can change over time, but that's my hypothesis of why and like I say, it's an hypothesis.
Second, "Is the framework for figuring out what the right Unit of Value is or is the nix at a hundred million dollars?"
The answer's going to be no because there's many paths to heaven. But there's different risks, so if you have a high concentration of five customers generating 50 percent of your revenue, that's not healthy and that means one of two things.
One, you have high customer concentration at risk, or two, you're building a product that only five people want. Every time I look at an investment at Greylock I say, "OK, what's the market for this product? Is it 50 customers, 2,000 customers or 200,000 customers?" It's not right or wrong. If you have 50 customers you probably don't have a company.
Arguably, the top 50 companies in the world like Goldman Sachs, Google, or Facebook can hire enough engineers to support the product themselves. If you have 500 customers, you have a small company. If you have hit the 1,000 or 2,000 mark, you're going to have a real enterprise software company to monetize and if you have 100,000 customers out there, then you have a very, very big company.
That's why I looked at market shares of something similar to an enterprise software company, like VMware, that's 40 billion a market cap. Usually they have 100,000 customers plus or minus versus Teradata that's selling a data warehouse. They are selling to 1,000 or 2,000 customers, but a very very high price point.
I would say, if your mix looks too concentrated, as an investor I get nervous. As a CEO you should be nervous, too because you only really have five customers. I would look for a margin of diversity. That said, the numbers always bear out, you're going to have 10 or 20 percent of your customers generating most of your revenue.
The question of Mark from Apiary asking, "When you start out you're probably a single or small Unit of Value, probably linear and Apiary, you're the toolsets that basically manages APIs, when do you start thinking about how to create non-linear value, or if?
To be honest, I think you've got to start thinking about it earlier. You don't need to start building additional products at Apiary for creating non-linear value today but you should, like I said, make it a conscious choice.
Two things, one, you may only be a linear product and that's fine too or your non-linear factor may be very low and that's OK, it just means you have to figure out, but I don't know if that's true or not for Apiary. That means make sure your Go To Market, your channel, is priced correctly.
From the very beginning you think, "OK, we're going to start selling this set of toolsets for building APIs for our customers. At some point in time, how do we get non-linear value?" I think when you're creating an API framework there are a bunch of things for us, security, managing and metering, that are our non-linear tools.
I think once you become a standard inside or outside the enterprise, there's a way you can kind of pair APIs together. So you can have a road map now about it and a vision how you can make this bigger, that you sell to your engineers, to your customers. But you don't need to build it right away, you just need to have a path.
Make it a choice. If you don't think about it now, you're going to start building your product, building your service, and then you're going to go, "Oh shoot," after the fact, "How do we actually extract more value of the customer."
Don't be afraid to kind of try a couple of things early, but don't be the case that you didn't try.
Make it a conscious choice.
You can, at the beginning of your company, have that whole tool set, the whole set of services, but what happens is, as your customer starts consuming more, they're going to get more out of it. What we saw at VMware in the early days, the customers virtualized one server, one rack of server, and towered the entire data center. They started getting huge non-linear value from standardizing on a single platform, from the other tools they would basically be able to employ, from the other products we sold, so we had all those products from the very beginning.
The joy of non-linear value is, you have it from the beginning, your customers use it, they love it, they start consuming more of it, and they start getting even more value out of it. That's the customer delight. The more they use your product, the more they enjoy it, the more they benefit from it.
It's not necessarily saying, "I'm going to sell them something else later." The best non-linear product is something that the product itself doesn't change, but the more I consume it, the more I'm going to get value out of it.
One, there's a lot of signs and math into this chart as you can see. Number two, this is the same company. You're saying it goes below here and there's a break-even. Maybe that's true. That means you're giving away value before you capture it and that might be true, too. You try to give away as much value to your customers and try to consume at the very end.
A lot of open source technology is like, "Hey, MySQL, use it, we're not going to charge you for anything and then we're going to turn on the GPL license and take value from you." There's no magic break-even line and some lines are very steep, some aren't very steep at all, and there's no one size fits all, there's no right or wrong.
My point here is, one, be thoughtful about what your Unit of Value is, consciously. Number two, be thoughtful about how you scale that over time. There's linear and there's linear. If you think of ways to make it non-linear, then more power to you. If you have a large Unit of Value, that's great, understand that you need to charge more for it and that the way you sell it is going to be very different from when you have a small Unit of Value.
The answer's yes and it varies based upon the type of mark you play in. So let's say an infrastructure developer application technology is almost going to be open source. Think about the last time there was a closed-source database that didn't start out as open source.
The higher level in the stack, like at Salesforce.com, where your interface is less for developers more with consumers, there's a bunch of reasons why, in terms of ecosystem and network effects and developers, the higher level in the stack typically can be a closed-source service. There's open source CRM but Salesforce is the winner more or less for a couple of reasons.
One, they were there early. Number two, if you lock the platform slide, they own the customer record now and so in terms of building a platform, you can build a platform if you own the system record and if you own enough of that data. I would say in a lot of the application technologies it's almost always going to be open source for a bunch of reasons in terms of development speed, working with the ecosystem, and vendor lock in perceptions from the enterprises.
I would argue VMware is maybe one of the last kind of infrastructure technologies that are closed-source that become a de facto standard. No one is going to let that happen anymore. Docker's open source, Hadoop's open source, it's tough at this level, but it's definitely doable. You have to be thoughtful about how you build economic value around it as a closed-source product.
So the question is, "Do you change who you sell to and how you message your product?"
So I think as a small Unit of Value, you're typically selling to a developer individual and that's productivity or getting something built or done. When you sell an entire company standard, there's going to be value just standardizing on a technology, a product, or a service.
That benefits reducing friction of teaching the twentieth person on how to use this product or there's benefits on how to communicate with other companies or other technologies because now having multiple APIs you need to support, all your ecosystem, all your other vendors need to support one standard API. So the position changes and then you're definitely selling from a CSO or security person that you standardized the technology. You basically understand security paradigm,s so there's one service.
CFO for sure because you're making an enterprise-wide decision, going from someone swiping a credit card on Amazon to cutting a multimillion dollar PO, you're going to change the persona.
The classic developer tooling is Go To Market, it's hard to go directly at an app owner or administrator because he or she doesn't want tp change technologies directly.
One of the key lessons I'll teach you is the number one goal for any IT buyer in the enterprise. It's don't get fired.
I mean that's why they say, always buy IBM or Oracle because you can't get fired or Salesforce.com. So the reason why they're often resistant to trying new technologies out is because they're just resistant to change, but they'll change if there's enough value there.
The point is you're going to get grass-root adoption developers. They're going to start building applications. They're going to start hosting on Amazon.com because it's easy, it's better, it's cheaper.
You ask, "When and how you sell?" There's a couple of different selling models. One, there's a kind of open source file up call, "Hey, we know that you have 20 registered users right now using Spring framework or using Amazon Web Services, how would you like to get an enterprise license agreement or a surge on purchasing?"
There's number two, which is, "Oh, "you're using x, insta-Mongo DB, how would you like to buy the Mongo management service or this manager product? A security product?" There's the add-on sell to it.
There is a third saying, "Hey, enough of your applications are now twenty to thirty five percent running on this cloud storage technology or this cloud service. Why don't you standardize the entire thing on it? Because there's all these other benefits we can bring to bear." It's going to vary from company to company but I would say there's no magic number when you flip over.
I would say it varies on price. If you're selling 10 cents an API call you wouldn't necessarily do it at a hundred API calls. You'd have to do it at a lot higher scale.
How do you make yourself a de facto standard?
There's no silver bullet to it, so there's a combination of many paths. One, first to market. There's number two, technology and time lead. There's two as a natural axe. There's an ecosystem play where you say, "Hey, let me sign up three or four large partners or technologies that are going to depend upon my product or service, so therefore they will drag me into their customer bases."
Or say, "Hey, I'm the de facto standard for this because we work with all the technologies you've had before." That only works if you create a new category or new space that didn't exist beforehand.
Other than that we could talk offline. I don't have good case studies but there are some unnatural things you can do around biz dev marketing and partnerships. Largely it's going to be first mover advantage, potentially because often times, especially in open source, the first one benefits the most in ecosystem.
Number two, it's execution and racing to get more market share faster, so whoever gets to get more users, more developers, more partners faster can tip the scales.
With that, thank you very much and again, jerry@greylock, if you have questions. I appreciate the time.