All right, it's not every day that you get to sit with an extraordinary founder and get to pick his brain on what it takes to build successful companies. Mohit needs no introduction, but I'll say a few words. Mohit is no stranger to the startup ecosystem. He was the co-founder of Nutanix and is the founder and CEO of Cohesity. Both are unicorns. In fact, I was just checking, I was telling Mohit I was checking the market cap for Nutanix today morning, it's now 19 billion. So congratulations, Mohit, and we're excited and hoping to see Cohesity go public very soon. Having built like two massive companies, it's not everyone who's kind of seen that entire journey, and you're a masterclass in helping figure out like what are pain points, like how do you kind of build a company, how do you scale a company, you understand enterprise go-to-market really well. So maybe it'll be remiss if I didn't start the conversation by asking you like the more fundamental question of, you do a lot of background work before you actually start writing code. What's the framework that goes through your mind before you enter a new space and want to build a company around it?
Well, first of all, thank you for having me here. It's great to be here. So I'll give you my motivation for that framework first before I go into the framework itself. So I think people will probably identify with this. Often when we see companies failing, don't we often think, what was that founder thinking? I could have told him or her that this company is not going to succeed. Conversely, sometimes there are a lot of naysayers for companies and yet they succeed, right? So clearly there's something going on. So I crystallized all that into what I call a hypothesis document. It's almost like when you start companies, the founders should write a hypothesis. And we'll talk about a breakdown on what that should contain, but let's just say that it's a case for why the company would succeed. And if you run that hypothesis with a few objective people and if they all say that it's solid, there's a high probability that the company would succeed. That's the way to think about it. If everyone you show the hypothesis to is like, no, there's no way this is going to succeed, then there's a high probability you will not succeed and you're just drinking your own Kool-Aid. So that's what prompted me to think about this. So the way I advise people on the hypothesis, it's a formal framework that I've built. It has four sections. The first section is your elevator pitch. It is literally imagine yourself to be in the elevator with your potential customer. What are you going to say to that customer? You have 5 minutes. In those 5 minutes, what are you going to say so the customer becomes interested to at least try a product? That's your elevator pitch. If it takes you more than 5 minutes, you're doing it wrong. So that's the first section of the hypothesis. The second section is what I call the minimum lovable product, MLP, not MVP. I don't like MVP because everyone can define MVP in their own way. Minimum viable product, what does that mean? So what's the first product, the minimum lovable product that you're going to build? What are the features that will have? The reason that's important is because the company's success depends on that. Sometimes I often see founders talk about how great their company is going to be 10 years from today and they're going to do this and do that. Well, the point is you never reach there if the MLP is not successful. So it's very important to crisply define what the MLP is and make a case for why that's going to be successful before you think about what comes in the future. So that's the second section, crisply defining exactly what the MLP is going to be. The third section is your points about why do you think the company is going to succeed. So literally the title of that section is why is the company going to succeed? What are all the points behind why the company is going to succeed? And the last section is even more important and interesting. It's actually why do you think the company is not going to succeed? Put yourselves in the shoes of a naysayer. I'm sure there are lots of naysayers. What are the naysayers saying and what are your rebuttals against those? And if you can write that all down in a hypothesis, all these four sections, show to people, and the objective people at least say that it's solid, there's a higher probability this company is going to succeed, then you have a case. Otherwise, you're just playing a lottery. There's a high probability the company is not going to make it. It's all probabilistic. Some companies will probably maybe still make it, but there's a higher chance if the hypothesis is not solid, you're not going to make it. And founders, we all know that people start companies and they really badly want it to succeed. And once they start, even though they never made a hypothesis, it's not solid, then they keep putting money into it, keep putting hard work into it. Four years down the line, they have to shut down the company and they're like, why me? Why don't my companies succeed? So if they just build that hypothesis as a high probability it'll be succeeding.
That's a very, very thoughtful framework. I'm curious if you could also like put this in the perspective of a company that you've built before.
Yeah, absolutely. So let's take my first company, Nutanix, as an example. So for people who may not know, Nutanix brought into the world a concept called hyperconvergence. So before Nutanix, people used to buy compute from one vendor and then they'll buy storage from another one, right? And then they'll connect them together with networking and then run their applications on this combined infrastructure, run their virtual farms or what have you. So what Nutanix did is it collapsed all that. It basically said that the same server can run both compute and storage, and they did it through virtualization. So that was the concept of hyperconvergence at a higher level. And the very first MLP was to actually solve for virtual desktops. Virtual desktops were very expensive and as soon as Nutanix came up with this product, they became quite cheap and that was the first customers that we addressed. So the elevator pitch was simply rather than buying your compute and storage from separate vendors, you can buy it from us, it'll cut down your cost by something like 80%. That was the elevator pitch. The MLP was crisply that the first product, you can host virtual desktops on it, it'll be a virtualized product, consolidated, the same servers, it's a distributed form and on that you'll run your virtual servers and virtual desktops and it'll cut down the cost by I think something like 5x. The third section was why would it succeed? So let's speak about some of the hardware trends as an example. I think up until Nutanix was founded in 2009, Moore's law was still active. Compute bandwidths and speeds were increasing year after year. Storage speeds were increasing, storage capacities were increasing. So compute and storage were both increasing year after year. But networking, when I came to the Silicon Valley in 2000, the networking that came to my desktop was 1 gig. The networking that comes to my desktop today, 24 years later, is a gig. So the networking has not improved. Or even if you can take 10 gig, 10 gig in the data centers, it's improved by 10x. Compute speeds and storage speeds have increased by like way more than that, like order of magnitude more than that. So doesn't it make sense to get the networking out of the way and have the compute and storage which used to sit away and connected by the network to come together? And so that was a huge propeller underneath Nutanix that made it successful. Add to that the improved manageability, reduced costs, and a whole ton of other benefits. So that's the case for why it would succeed. Then if you speak to naysayers, and they were naysayers, right? So some of the naysayers said that, well, SANs are getting cheaper and your hyperconverged product will not fly because the bigger companies will kill you. Well, our rebuttal was that manageability is still going to be a problem. So for every one of the naysayer arguments, we had a rebuttal which was pretty solid, as in not just for us and I can be drinking my own Kool-Aid, right? Who knows? But if we actually show it to people, they actually blessed it that okay, this rebuttal is solid. So we had a bunch of such things and that's an example of why it was a very solid hypothesis.
Yeah, I just wanted to also like dig into that piece, right? I think you mentioned that MLP is kind of the insertion point and then you have a big vision. At Nutanix, you had the big vision of hyperconvergence. At what point in the product journey do you decide that you should, like, you need to focus on the next piece of the journey?
Yeah, because great question. So what he's saying is that the MLP is just the beginning. A lot of companies make a mistake, and this is also part of your hypothesis, what are you going to do beyond the MLP? If your vision, if your overall vision equals the MLP, it's a mistake. Because even if the MLP flies, a lot of people, there are going to be competitors who start copying and you have nowhere to go. Your vision equals your MLP. So your vision ought to be bigger than the MLP. The question then is that there might be multiple moving parts in your vision, which one do you attack first? Well, once your MLP is successful, your customers will tell you that. So literally the customers will almost become the product managers and they'll tell you exactly what you need to focus on. So you may have a bigger vision, but then what exactly to pursue in that vision, let that be driven by market forces. So it's actually not that hard a problem. All you need to do is have a bigger vision and then which one of that you're actually going to attack next, just ask your customers.
Since we are at this question of like building and building the pipeline of the and kind of the future of the product, I'd be remiss if I didn't ask you, how do you balance quality of the product versus velocity? Because at the end of the day, you want to build quickly for the market. You're seeing those trends happen in front of you, you're seeing those pain points, and you could really rush something to the market which the customers are not delighted by. But like, and how do you, what is your framework for thinking of that?
So I've learned this the hard way. I stand by strongly behind what I'm going to say now. So we have made mistakes in my companies when at certain points in the company, we sacrificed quality, or the team sacrificed quality, for the velocity. And there is a way to actually get both. And so what I do now, the methodology we use, the playbook, is we use what is called a requirement scorecard. So let me explain the concept. So people here probably know what's a design doc and what's a PR, product requirements document. So what people do is they'll build, let's say, a product requirements document, they'll write down the features or goals or whatever you may want to call them in that, or they will have it in their design docs. The problem is that nobody going to consult these documents once the product is made. And even if the product is made, the people implementing the product may make some shortcuts for the velocity. And so you don't even know what exactly the PR says that do these 10 things and they may do seven of them, they cut some corners and now it's all customers filing bugs and shouting and screaming and that's kind of how you iterate and solve the problem. That's in my mind the wrong way to do it. So the right way to do it is to actually take those, I call them requirements, I do not like calling them goals because goals tend to be best effort. Requirements are requirements. So take those requirements out of your design docs and PRs wherever you keep them and make them first-class citizens. Put them in what I call a requirement scorecard. So the requirement scorecard can be just a simple spreadsheet which captures all the requirements that that particular feature or your product, depending on where you are in your company, all the requirements are written in a requirement scorecard or spreadsheet, whatever. And then against every requirement you have, first of all, the release, when it's going out, is it going out in V1, V2, blah, blah, blah. And I need sign-offs, right? When it does go out, I need the sign-off from the technical lead, the product manager, the QA person, and the manager of that. So if that gets released, if that feature gets released and it has problems, who signed off on that? Now people are very careful about, they may postpone a feature to the next release. So when we actually do release something, we precisely know what requirements are actually met and what are not met, so that we can proactively track them. So sometimes for velocity we may shave on the requirements, we cut down the requirements that we satisfy. So we release something that meets less of the requirements, that's okay as long as it's a collaborative decision that it is still a lovable product, but we are proactively working on the missing requirements as opposed to waiting for the customer to tell us what's missing. So now you can balance the quality and the velocity quite well. That's a practice that I'll be surprised if things don't work.
