Unit of Value with Jerry Chen | Greyscale

Crafting and executing a go to market strategy is one of the biggest challenges for an early stage startup. In this talk from Grayscale, an event hosted by Greylock Partners, Greylock Enterprise partner Jerry Chen shares his unit of value framework for taking a product to market. For more podcasts, please visit news.greylock.com thank you guys.

Hopefully the morning was productive. I think the way structured the morning was focused on kind of overview of blitzscaling or gray scaling. We'll figure out the right terminology eventually and we'll apply the right trademarks and T shirts. And then Dan and Jeff, obviously I feel blessed and lucky to work with those guys day in, day out because you don't realize how good Dan and Jeff are at their jobs until you actually spend time with them. And if you're fortunate enough like Mike Callahan to to work with both Dan Pertillou and Jeff Markowitz, you'll understand how valuable having both those guys on your team can be. So this afternoon we're switched topics, switch speeds again. I'm going to give a quick overview on a framework called unit value. We'll talk about in a second. And then we're very lucky to have after this a fireside chat with Mike Clayville, who worked with me back in the day at VMware. He's now VP of Sales for Amazon Web Services. We're talking about two things. One, probably a little bit of Amazon writ large, but also just about scaling go to market from small deal sizes to multimillion dollar deal sizes. He's seen that several times. Then after that we're going to have a panel with two CIOs to talk about the customer perspective on how they work with startups small and large. And then obviously dinner will finish the night with a fireside chat with Daniel Bushri. And again, so hopefully you're taking the time to meet each other network and compare notes and mix seats. I know, like bridge. Brian's never leaving that seat. So if you don't switch seats. So feel free to mix and mingle. Maybe after the next break sit next to somebody new, quite frankly. Okay, unit of value. I think I probably blogged and over tweeted this because I think half the folks probably have read it or seen it, but if you heard me give this spiel or talk, raise your hand. Unit value. Okay, good. So we can make this interactive and we can have conversations because it's like all frameworks, it's probably half right and half wrong. And. And the question is, you don't know which half is right. Which half is wrong? And it's meant, like my talk this morning, to spur conversations or thoughts around the market around your own go to market strategy. But specifically unit value is meant from a product perspective, engineering perspective, how to build products. So the framework from this came originally from my partner Neil Bushry, who we'll hear from tonight. He says as a startup, it's the classic battle between David and Goliath, right? Startup versus incumbent. It's your startup against Amazon, Mike Clayville and his services, EMC, Oracle, Google, Microsoft, these huge multi billion dollar giants versus 2, 3, 4, 100 people in a dream and a plan. So really what we're talking about as startup versus incumbent is technology versus distribution. So as a startup you have what I call either IP deep or operationally hard. You have a technology that gives you an advantage around AI, around security, around storage, around scale, around application process. But what the incumbents have is distribution. They have customers, they have a salesforce, they have channel, they have brand, they have all the leverages and all the weapons of an incumbent that you don't have. So then becomes a race between can you build distribution, cost effective distribution to get to your customers before the incumbents can buy or build a technology to compete. You start underneath the radar. Small company, never taken seriously. When once you do get some scale, once you hit the radar of an incumbent like a storage company or a database company or an app company like Salesforce, they're either gonna buy competitor or build their own to crush you. So what we mean is how do you scale, go to market effectively? And this is part of the blitzscaling and Reid and John alluded to this this morning is oftentimes in blitzscaling or hyperscaling, you're kind of extending your supply lines, extending your go to market way in advance of where you are. And you know this, right? So if you're running a company right now that you're in the throes of go to market, you're probably hiring sales reps, hiring inside sales reps, probably burning a huge dollar amount in the effort to build distribution. So again, you know, we, we talk about product, market fit, which quite frankly I still don't know exactly what that means. But there's basically two things. Your technology, your solution and the large market. And you're trying to match the two together. You know, you can have one but not the other. You don't have a company. Okay, so why does this matter? And why do I as a vc, as an investor, why do I think about go to market? Why do I think about unit value. And oftentimes as startups, we have the following problem. And oftentimes as investors, we often focus too much on the technology, right? We often get enamored by the product, by the technology. But we underestimate the difficulty it takes to bring this product to market. And that's, quite frankly, the hard part. No offense to the engineers and the scientists in the room, but bringing the product to market is as important, more important in determining your success of a company than just your technology. So a understanding go to market impacts how much money to raise. Is it going to be $1 million or $100 million? It understands you're setting your pricing and packaging. It understand basically determines your margins and your profits at scale. Right? Is this a 10% business at scale, 90% business at scale, or someplace in between? So things to talk about. I mean, there's channel, there's customer acquisition costs, there's partnerships, there's awareness, there's distribution. There's a whole bunch of things wrong. Go to marketing, think about. And there's great folks like Dave McJana in the room that can actually weigh on all these more than me. I'm gonna focus on this thing I call unit of value as a framework from the very beginning. And so what is a unit of value? And it's from when I was running product at previous jobs, and when I look at companies now, I say, what's the smallest measurable unit at which your product or service delivers value? Right now you can have multiple units of value, small, medium, large. And we talk about that. But the smallest unit of value is at what unit do you deliver value to your user, to your custom. It's also the unit of scaling. So you can sell one $10 billion product or, you know, a bunch of small products, but what is the unit of scaling within a customer that you think about? And then it's also what do your customers really pay for? And we talk about examples like API calls, number of seats, number of terabytes of storage, et cetera. Again, it determines the price you sell, the price of scale, and what you charge your customers. And there are small units of value and large units of value. Smaller is not better, and bigger is not necessarily better. But let's talk about a different one. So small units of value. So something like Dropbox, right? As a Dropbox user, a single user, I get value from storing my files in the cloud and Getting access anywhere. VMware one server, one VM Docker, one container. I get value from a very small unit value. Microsoft Office, Microsoft Word. I as a content creator get value value from buying Office. So very small units of value. Then there are medium units of value. So Salesforce, basically three to four sales rep in a company that are collaborating can have a small unit of value box which is really early enterprise content management, a small team marketing, a line of business, professional services, a department can all be on box for file sharing, collaboration. That's a unit value. At lastly in GitHub Developer Tools, right you're really collaborating, communicating with other developers. That's a small unit value is not the entire company, not the entire dev team, but a small unit of value or medium unit value. And there's big units of value, right? Some like mesos. You really only need kind of a scheduler when you have a large cluster of computers. Hadoop. You really only need to buy Hadoop when you have petabytes of data workday. We'll talk to Neil later today. Hcm, Human Capital Management. Your entire company should be on the same HR system or not at all. It doesn't make sense for sales and marketing engineering to be on three different HR systems. SAP, Oracle, these large ERP systems are large units of value. You're selling the entire company at once. So again, different sizes for different companies for different products. Bigger is not better, smaller is not better. You know I have startups and CEOs come in and say hey, we're going to be like Box or Dropbox or we're going to be like GitHub. You know that doesn't make any sense. If you're selling a large unit of value, make sure your go to market matches your unit value. So bigger units of value like hcm, erp, Big data have longer sales cycles. Usually they're more complicated products and you should charge more. Doesn't mean the market's bigger, doesn't mean they can be higher in revenue. It means that the minimal unit, what you're selling is a large chunk of product. And then the questions then become like how do I build a cost effective direct salesforce? But then the second question is if I have a large unit of value, takes months or weeks to sell the product, how do I build an advantage go to market? And what I mean by that is in the battle against incumbency, if you're selling ERP software or selling database software, you're going against a large incumbent with a sales force, with a channel, with a brand. You hiring 20 sales reps selling your database isn't going to be easy because you're basically fighting fire with fire. So what are ways I can build advantage go to market through open source, through partnerships, through some level of product virality. This can actually build into your your go to market to your product. So if you have smaller unit values like one user, one server, three or four teams, again you have shorter sales cycles ideally, right? But also how do you create a cost effective channel? So if you're selling Dropbox Professional Pro for small teams, you don't want to send a direct salesforce there. How do you cost effectively upgrade kind of the Freeman users to a paid user? Right. And so you want to build a self service, cost effective method. And then the next question for after you kind of crack, the first question is how do I scale up up the unit of value? How to scale up the size of my customers? So these small onesie 2Z3 person deals turn to 300, 400 company wide license agreements. Okay? So take a step back, you have small units of value, large units of value. There are multiple paths to heaven, right? And as an investor I think about okay, what would it take to get this company to 100 million in revenue? Again you can do something very small like an API call. So if you're Twilio, you're stripe, you're taking pennies on the dollar for every single unit of value, every single transaction. To hit $100 million at 10 cents a call, you need a billion API calls, right? On the flip side, if you're selling like HR software, ERP software, you're charging $100,000 per customer, you only need a thousand deals and you can probably afford a direct salesforce and then it scales up and down. So if you have 100 to 200, $300 product, like a small CRM product or maybe Dropbox for business, how do you make that as self service as possible? So you're acquiring customers, serving them without breaking the bank. And then there's this thing I call the dead zone in the middle and this is the worst place to be. And oftentimes I give this framework and they have founders going holy shit, I'm in the dead zone. Or like oh yeah, that pain I'm feeling, I'm in the dead zone. What happens in the dead zone is you have this kind of in between unit of value where the cost of server customers inside sales, direct sales is burning more cash than you're taking in. And that means either your product is too complicated for self service, right? So the API calls or the credit card via the website, it's not doing it, but it's still too Small to justify an inside sales rep, a business development rep, and way too small of a deal to justify direct sales. And so you're stuck in the dead zone. We see companies recently go public or startups that come through raising money. They're stuck in this dead zone where they're burning money. And then the question becomes, how do I get out of the dead zone once I'm in there, right? Do I a raise money and hopefully grow my average deal size so I move to the right, or do I say actually I'm overselling my unit value, I can actually reduce the product I'm selling, simplify it and move to the left. Okay, so we'll go through a couple of different case studies on how you get there. You know, the names here were eliminated to protect the innocent and the guilty. But this is one of the kind of these developer API services that we looked at. It's not a greylock portfolio company, but half their bookings are from customers paying more than $25,000 a year, even though they're charging pennies per API call. And so even though have a very small unit of value, they were able to find customers and scale them up fairly quickly to justify large ticket amounts. So again, a small unit value doesn't mean small deal sizes. It means you charge something very small. But you got to figure out how to scale it up. Same for this other cloud infrastructure service that has fewer users. 50,000. Their average monthly price is less than $50 per user, so a few hundred bucks a year. But again, they found that 5% of their customers drive half of the monthly recurring revenue. So even though they start very small, 50 bucks a month, they were able to quickly grow and identify a segment of customers to use their service to scale up to justify larger deal sizes and a higher revenue. So the takeaway when I look at business like this is if you have a small unit of value, that's okay as long as you A can service those customers cost effectively and B, scale it up profitably to some reasonable deal size. Otherwise it's going to be very hard to grow into 100 million plus revenue business. The second thing I think a lot about is how do you create nonlinear value when you grow. And so if you're selling seats or you're selling servers, if you add your product and manage the servers for like configuration management, security, you're kind of scaling up literally with your customers. But how do you create nonlinear value? What I mean by that is as your customer consumes more of your product storage security applications like a Workflow, CRM, customer support. If I start consuming more and more of the product, do I create nonlinear value for the customer? Meaning you get more value out of buying more of your product. It doesn't mean you can charge more. Right. The area under the curve is really the value created and then it's based upon pricing. Do you give that value to the customer or you increase your prices to get that value? Again, so this is non exhaustive. There's some ideas on how to go nonlinear. Basically, as you build your offerings, you can do things like management, monitor security, you can sell it to a business unit, multiple business units, multiple buyers. There's add on products you can sell on. But it's worth thinking about that as you plan out your core unit of value. What's an Act 2, Act 3, Act 4 of your company that you can sell on top of your core unit value to drive up that revenue line. Again, there's also value when you go nonlinear, when you're creating more value. So the more value I get out of consuming more product just makes you stickier, right? So your standard, your database standard like Oracle was early. If I'm all on Oracle, all my developers are using it, there's value in that for my developers. It also makes it a lot stickier to replace Oracle as a default database. There's also other ways I think about network effects, standards and platforms. And again, these are not exhaustive. And there's other ways to increase value nonlinearly that you can think about. We can talk about later too. Again, network effects is classic. I think Reid Hoffman talked about this this morning, that basically Metcalfe's law, the more users using it, the more value they get. So messaging, like email, instant messaging, Slack quip, things like that are basically using network effects. So the more people in the company using the product, increase the value of the product. And collaboration tools are largely like Dropbox and Box are using network effects standards. So we always want to be a platform. The next two ones are very related. There are de facto standards and official market standards. And de facto standards are like languages, APIs like in Amazon Office, like Doc format or the Excel format or the PPT format for the longest time are de facto standards. And so when you're the de facto standards, so you're all communicating in Word or PowerPoint or you're all on Amazon using their APIs, that's a powerful position to be in as well. And because everyone in the company can agree on a standard, in your ecosystem can use a standard. But standards also fade, right? They Change quickly if you're not careful. So browser wars, right? Netscape was a standard. So everyone was developing, testing against Netscape. Then IE got to 30, 40% market share and Microsoft basically beat Netscape because it was no longer the standard. Then Firefox, Chrome, Safari, et cetera. And so at some point in time, you have this ability to create a de facto standard. But oftentimes if you're monetizing that too aggressively, there'll be new entrants and standards fade or can actually be replaced. So platforms is actually another way we think about. And platforms are hard to build. So VMware, if you're Amazon, you're a docker, you think about being a platform, but it's not just infrastructure. Platforms also have this concept of systems of record, right? Basically, how do you be the system of record in a company? And this is really owning the critical data. So in an enterprise company, I like to think there's three systems of records that matter. Your employees, your customers and your assets. So HR is a system record for employees, CRM is a system record for your customers, and ERP is a system record for your assets. Again, workdays trying to own your employer records. Salesforce tries to own your customer records. And ERP largely Oracle and SAP, though workdays, aggressively moving to SAS as well. There's also technology platforms, infrastructure, storage, networking, monitoring. VMware went through this path, becoming the system record for all these technologies. Docker and that ecosystem around Containers is going down that path as well again. So actually we'll have Mike on stage next and talk about the cloud standards between Amazon, Azure and Google. Are these really platforms that can become a system of record for developers? Again, you can go through this journey. It's not one size fits all. You can do multiple things. You can be the standard early, you can sell additional products like management, monitor, security. And then if you actually have a huge amount of usage within a customer, you can create an ecosystem, a platform of developers and third party customers on your platform. And that's either because A, you're the de facto standard, B, you own the system record like salesforce has force.com for your customer records, or C, you actually have a technical infrastructure, networking, storage that you intercede on. You know, just kind of three things I think about on go to market, it's a conscious choice. Don't expect to fall into your go to market, don't expect to fall into your unit of value. So you want to be thoughtful about it often. The mistake I see companies often make early is they let Their customers determine the system record, they let their customers determine the pricing packaging. Way too early. One thing I want to talk about that is powerful, that doesn't happen often is you can have the same system of record or sorry, same unit values or competition, but charged differently. So unit value isn't necessarily the unit you charge for. And the classic example is the Office Suite. So Microsoft Office, PowerPoint, Word, Excel charges per user, more or less. Google Apps is also value per user, right? You get value from Google Docs per user, but even though the unit value was number of users, what they charged for is very different. Microsoft charged per user, Google gave away for free because they made money on ads. So really the unit value for Google as a company isn't users or data, it's number of eyeballs, number of people, it's you that they're selling ads to. So if you have a business where you have a competitor with the same unit of value, but you can charge something differently, then that's pretty powerful because the incumbent is now trapped by their own business model. Again, don't be afraid to iterate. You'll probably get this wrong the first time, the second time, the third time, but once you do it, you're not stuck. But, but you got to be quick about this because the worst thing to happen, you're stuck in a unit of value, you're stuck in a go to market framework that you can't get out of. And then I think a couple things, how to be honest about it. So as a CEO, as a founder, I think a couple of companies like Drew and Zach have done this with their teams. Said, what's your unit of value? Ask your developers, ask your sales reps, ask your product guys and talk about it, be honest about it, that you might have a big unit of value, you might have a small one, you might have multiple units of value. And your focus then is try to figure out what it is and then create a roadmap, right? Like be thoughtful about it. What happens next? Once you create the unit value, once you create your first customers, what do you do next? And that's it. So with that, I'll turn the questions before we go to the next conference, the next event. Questions, thoughts?

I'll take one because you kind of touched on it at the end, but I know you have a few things to say about it, so I'll prompt you. You bring up an interesting point about unit of value and you mentioned at the end the notion that just because you've defined it or you acknowledge what it is doesn't mean that you can't change it. But I think that one thing that would be kind of helpful to hear your thoughts on is how do you go about like, if you've realized your unit value, you want to change it. What should be the kind of decision process on whether or not A, you can do it, but based on your existing customer base and B, what does that transition ideally look like?

The longer you wait to change your unit value or how you price, the harder it gets. And this is why incumbents are hard to change, because you're victims of your own success and you're victims of your own business model. So if you're used to selling software on a per server perpetual license basis, it's really hard to go to subscription basis, right? Per monthly or annually. And once you're a public company and you're used to reporting perpetual licenses, you, it gets really hard to change as well. So I would say for incumbents, you can use this inertia as a vulnerability against them to sell. Right. Like Google did this with Microsoft on Google Apps versus Office for you as a startup, you gotta do it early. So I would either A experiment early with different customer groups, like don't be afraid to kind of a B test it, or B as you roll out new versions. 1.0, 2.0, 3.0 is play around with it. But when I say you can change it, I mean you got to iterate. Got to iterate quickly because once you start scaling and hit that hyperscale mode, you're kind of stuck.

I'm not sure we're there yet, but in terms of enterprise app stores, it seems like a few could emerge. I mean, you have the Amazon platform. I'm not sure how well that's working in terms of charging on top of the EC2 price or something. Do you think there's some good examples of that being done? And how does that affect your price? Because then the platform is dictating your price, right?

I think so. The question around app stores, like Amazon App Store, there's a Slack App Store, there's Google Play Store. So I think you can't rely on those things. Those things I think what we've seen, especially the mobile app stores, those are narrow windows. So I think app stores are great for distribution and discovery. And so if you're early and you get distribution through discovery, when these app stores are new, you can use that to your advantage. So I would charge, I would be aggressive early. It's not necessarily dropping a price. You can offer a discount Whatever. Because what we've seen, at least on the mobile side, it's a land grab. When you're there early, you get trial, you get promoted. But at some point in time, if the apps were successful, everybody knows it, they all crowd in. All of a sudden the value of that app store starts going away and it gets harder and harder. If you remember the slide I said this morning that kind of a lot of companies are stuck between open source and a cloud place. Rock and a hard place. Oftentimes, you know, you don't be dependent upon Amazon or Apple or Google as your distribution channel. Just like an open source, you want to have direct relation with the developer. You need some direct relationship with your user or customer. So I would say app stores are a tactic, not a strategy. They're a short term way to get to your users, but they're not a long term channel for your business model. Because let's say you're not going to be relying on App store for more than a year or two. And for sure, if it's successful for you, why doesn't like Drew or Michael someone else do the same thing?

How does unit of value sort of apply when you start thinking about SMB versus Enterprise? So the two examples that you used were essentially could potentially be self service SMB based products, but in both cases their revenue came from the enterprise or at least from larger sales. So I mean the question's vague, but I think if you're trying to build an SMB based business, is that a bad idea at a startup stage?

Let's talk SMB specifically Ray, and then how univally applies. So regardless of unit value, what SMB in my mind means the number of units you scale up to is limited, right? Because if let's say number of employees you're selling to SMB, there's by definition so many employees less in SMB than large enterprise. And if it's number of servers, there are fewer servers used by the SMB than enterprise. So SMB versus enterprise doesn't determine what the unit value is in terms of the ceiling of the number of units you scale to number one. And so knowing that the number of units you scale to is capped when you target the SMB, the problem is always the following. Knowing that the deal sizes are going to be capped, how do you actually cost effectively sell to the SMB, which is how do you acquire them, eg, market to them, how do you sell to them and service them pre sales and post sales and it's okay to spend a lot of dollars on a direct sales force and acquiring customers on the enterprise side, even though you have a small unit of value, because if you're successful, you can scale up to thousands of users. But it makes no sense in the long run if you're captain SMB. So I think SMB is not the unit of value. SMB is okay. If I'm capped in the deal size, I got to create a cost effective channel. Can you talk a little bit about the platform units of value and maybe even specifically you mentioned system of record and glue layer. Are they mutually exclusive and what are the approaches there? Nothing's not mutually exclusive. So platform is kind of controversial term, right? It's like everybody wants to be a platform at some point of scale. Not everybody, but people talk about it and people have different definitions of platform. That said, very few customers wake up and go, you know what? I need to I need a new freaking platform. I need a new content management platform, I need a new database platform. Very often they don't think that they actually think I need an application. I need to solve a business problem. First and foremost, platforms come after the fact usually. But we can talk about that jujitsu if you want. Now or later. Now there's different ways to build a platform. In my mind, platform is when you have a layer of technology in which other people build on top of that are not you, right? And so that means there are applications or other ecosystems to plug on top of it. And so in order to build that either a, you have to have the data, for example, the system records. So if you own all the customer data in CRM marketing apps, customer support apps are built on top of it. If you own all the HR data a la hcm, then recruiting apps, performance review apps, payment apps, right? For salaries, are built on top of it. And so because you own that data, a platform layer outside of data and infrastructure is the glue layer means that you sit between networking, storage, right? Between compute between different parts of technology at a layer below. And what that means is like VMware did this well and the cloud guys try and do this. You actually are the layer between different technology components, storage, networking, computer that you can actually have ecosystem on top of you. So VMware does this well. Microsoft operating systems do this well. Windows iOS, Android does as well. They become a platform layer because they own the layer technology between the hardware and everything else. They're not mutually exclusive. You can do both.

When you bootstrap and you don't effectively define your unit of value, that would land you in the dead Zone, isn't it?

You can get lucky. Okay, I mean, I'd rather be. I mean, look, you can get lucky. Some companies do, right? The first two or three customers they land on say, hey, you know, Matt, I want to pay per server. Pay this. And it scales. But my comment the last couple slides was like, don't count on being lucky because you're not. If you pick the wrong customers or you pick the wrong unit value, you could be in the dead zone quickly.

And at certain times you might not have the liberty to make that shift late in the game. And the consequence that you might face face is a negative adversity if you've built a consumer base. And to quote with illustration, GitHub has shifted its unit of value from repo to per user and repo. And there is a side effect to this. So how would you deal with that side effect, especially with your consumers?

Yeah, it's similar to Adam's question how you shift these unit values. And it's not easy. It determines a on a relationship with your customer number one. So here are the pauses. If you are a powerful platform because you own the data or you own the APIs, you can do things that are unnatural, shifting unit value. And your customers have no choice but stick around because you own their data, right? Not everyone does that. GitHub owns all the code and so they can play around with it. It's really hard to get off of GitHub once you're on it, so they have some flexibility. So if you're ready this kind of platform, you have more degrees of freedom. That said, if you don't have that early in your journey, you can't do that. I said to Adam is you either iterate early, you find different customer segments, or wait to release a new product. So an example enterprises do, and this may not be an answer. You have good, better, best, gold, silver, bronze. And so the unit value, how you're charging for the first product, when you sell it to larger companies, SMB versus enterprise. You change how you charge. So maybe SMB is fixed fee, right? Because up to X number of users, because you don't want to count, want to source them, swipe your credit card. But your unit value for above 1,000 users, you're going to charge per terabyte per user, per server, per workflow, per VPN tunnel. And so you can segment by good, better, best segment by markets. And that's your next best thing. And then if you get more advanced, you can try things like changing brands and changing products. And so what the non technology brands do this? Well, car companies do this all the time. Your Toyota and your Honda, whatever, they have multiple platforms, they're all the same car, all the same engine. But just because you have a Lexus or an Audi or something on it, it's really the same car. But they segment people by brands, so that's powerful too. Other questions? Well, we can find me earlier. Thank you for that. And then we're going to bring a mic.