Mohit Aron, Cohesity & Nutanix Founder on AI Infra & Hyper-Scale Data

Thank you for having me, Grace.

I think the one thing I can point to is thinking from the customer's viewpoint, what would delight the customers, what pain they're going through, and what my companies can build to delight them and take them out of that pain. Putting yourself in the shoes of the customer is probably the one thing that results in success. Often, sometimes founders are too enthralled with their own technology and forget that the reason they are doing this is to make the customers happy. If they only keep thinking about their own technology, they've lost the plot. So if you think from the customer standpoint, you'll be more likely to be successful.

Absolutely. I go back to my time at Google. I was there from the beginning of 2003 to the end of 2007. Google was on the forefront of many technical innovations. At that time, they were seeing a problem where the networking bandwidth was really limiting them. When the compute tries to access the storage, it was really limiting them, so they came up with solutions where they would bring the two close together on one platform. I thought that could benefit the world. We can't do it the way Google did it because Google is its own customer. When you think about the external world, that's not quite true. When I did the company Nutanix along with my co-founders, we brought it out to the world through virtualization. We logically separated the compute and storage through the virtualization boundary yet brought it close together, and that was basically hyperconvergence. There was innovation beyond what I saw at Google. Innovation is about learning from the problems and thinking about how to make it accessible in a different domain. It's always thinking from the shoes of the customer: what pain they're going through as data explodes and computation needs grow while network speeds are not growing. All those came together in Nutanix, my first company.

The first thing is, if you wait until you build the whole product and then talk to customers, you're already too late because you may have built something customers don't like. You need to first think logically about whether this problem is applicable to customers and whether they are having a real pain. If you have a group of smart people and you collaborate and logically think about what the problem might be, each of you put yourself in the shoes of the customer and make a case for what you want to build. Once you've done that mind experiment, write it down into a hypothesis document. Show it to some other people, and if the majority agree there is something here, then you can go to the next step: start having actual customer conversations. The whole point is to validate that this is what we want to build and here is why we think it will benefit you, Mr. Customer. What do you think? At this point, there is no product. We have not invested any time. If the customer says that makes sense, I indeed have this problem, or at least the majority of customers say that, then you've got good validation that the direction is valid. Now you go and build the product, and along the way you're getting more validations. Building a product can take a couple of years, and during that time the market might shift. You want to continuously make sure the problem and solution are still valid, and you may do some course corrections. By the time you show the product to a real customer, you have a solid bunch of validations already done. The first real customer may come through an advisor, a venture capitalist, or lead generation. You have already done a bunch of due diligence by talking to customers and other knowledgeable people. So you're constantly putting yourself in the shoes of the customer. If you talk to a customer only after building the product, it's too late.

I think the reason people don't think of it is that it's too easy to just go with more of the same. They don't challenge the status quo. I can talk about other domains. Did we ever think that smartphones are what they are today? Back in the early 2000s, we thought the standard Nokia phone was the way to go. Nobody imagined. Then came Steve Jobs who thought differently, and now everyone uses smartphones, which are powerful computers in your hands. We never thought there would be that much power in our hands. So it's the same thing: people keep thinking that what they are using today is how it's going to be, and they often don't think about something new. Changing that thinking requires education. If it was so easy, companies would become multi-billion dollar companies on day one. First, you have to have the vision and think from the customer's shoes, get some validation, and as you roll out the product, you have to slowly educate the market that there's a new way to do things. That education itself is tough because people are so used to doing things the way they're used to. Even when the smartphone came, it took me a good two years before I bought my first smartphone. Once I saw enough of my friends benefiting, then I went for it. The marketplace is like that. You have to be good at building the product, but also at marketing and educating customers on the value. It's not like you build the product and customers come running. You have to make the effort to bring your message to the customer and educate them on the benefits. One by one, and notice that you don't build the whole product on day one. The product is being built slowly. You roll out version one and delight the customer. It's very important to delight your customer even with version one. As you build and sell, you are simultaneously building version two and three. What we have as the smartphone today is very different from what Apple built in 2007. While you're educating the market and the market is adopting your product, you're constantly building more. That's the challenge: managing both building the thing and selling and marketing it.

Absolutely. First, how did I identify the problem that Cohesity solved? If you look at the world of data and map it into an iceberg, the tip of the iceberg above the surface is production data or primary data. Bringing simplicity to that, hyperconvergence, was applicable in that space. But there is another part of data that is not production data, which you can call secondary data. This is all your backups, analytics, test and development, archival. It's actually the bigger part of the data, the lower part of the iceberg. What attracted me was that there is far more data here, almost 20% primary and 80% secondary, and there was a big mess in the secondary space. Cohesity's vision was to bring simplicity to that space, not just backups but more. Today, Cohesity is a premier vendor for simplifying backups, giving a web-scale solution, protecting against ransomware attacks, and bringing AI to them, all in one platform. You can think of it as hyperconvergence in a different way: hyperconverging different secondary workloads onto one platform. Now, to your second question about learnings from Nutanix: the first learning was the importance of people and delegation. Nutanix was my first company, and I had a hero attitude where I could do everything. Then I realized that to build phenomenal companies, you need to rely on team and delegate control. A lot of my effort at Cohesity was spent hiring the best around me and empowering them. Some things I had to learn from scratch. I was never a CEO before; Cohesity was my first time as CEO. I had to realize that the job of a CEO is different from a CTO. A CTO is a depth job, while the CEO is a breadth job, like a symphony orchestra conductor. The CEO has to make sure all units are functioning well and doesn't have the luxury to dive deep into one thing. I also had to learn how to hire beyond technologists, how to interview and select business people. If someone is unable to do their job well and I can't fix them, I had to learn to change them quickly.

I'm happy to share some, with the caveat that it's in stealth, so I won't be able to share too many details. To the audience member, please stay tuned. I would say this much: the name of the company is Scien. The name comes from 'science behind financials.' It's simple to pronounce: put an 'N' after 'sci-fi' and you get 'Scien.' Contrary to what the name might imply, it's not a financial company; it's more in the sales tax space. The problem comes from my own time as the CEO of Cohesity. I ran that for nine years and found that go-to-market execution was highly unpredictable, and there was no good platform to give good insights. My whole deal is to bring some science to it. The go-to-market function is all about financials, hence 'science behind financials.' I hope to do a company that can truly bring science to the way go-to-market is run.

Let me say a few words on that. First of all, both are true: AI brings a lot of potential, and at the same time, there's a lot of hype. If some organization is not thinking about AI, they're making a mistake. If they're doing too much AI washing, that's also a mistake. The way to think about it is that what has not changed is that eventually it's all about solving problems, whether internally or for customers. Think about AI as another tool in your arsenal that you must use to solve some of those problems. Take the example of fighting wars. There was a time when we had bows and arrows, then somebody invented the gun. It's a mistake to not use the gun to fight a war. If you go into a war with a bow and arrow, you're going to lose. It's the same with AI. If you're trying to solve problems without thinking about the latest tool, you're a little backward. But the problem needs to be real. Don't use AI for the sake of using AI. First, think about what problems you need to solve, then think about how AI can solve them. If you do that, whether it's an existing company or a new one, you can stay away from some of the hype and actually use AI for good benefit. A few things: if you're doing software engineering, it's a mistake to not use some of the new AI-assisted editors. They are phenomenal. There are multiple companies that have rolled them out, so pick the one that suits you best. If you have development teams, study how AI agents work and what they can do to help solve problems. If you're not doing that, that's a mistake. Everyone already uses ChatGPT or equivalent. You absolutely should do that. It's a game changer compared to doing a simple Google search and sifting through ten blue links. Always start with a real problem.

One thing I would start with is how my understanding changed when I started working on web-scale systems. What's different from a non-web-scale system is that in a non-web-scale system, you have the luxury to imagine that if some part of the system fails, somebody will come running and fix it in a short period of time. When designing a web-scale system, the thinking is completely opposite. Something will always fail and stay down for extended periods. You do not have the luxury to assume that somebody will come within a finite period and fix it. The system needs to be tolerant of failures and heal itself, assuming that whatever has failed will never come up or may not come up for extended periods. That's a fundamental difference. The second one is that a smaller system may have a bottleneck, but a true distributed, scale-out web-scale system cannot have the luxury of anything that can be a single bottleneck. If there is something, it better be very infrequently used. Otherwise, you're not a web-scale system. The whole system has to be designed where every part is extremely scalable, and there is no single point of bottleneck. Often people will have everything scale nicely except one database that doesn't scale, and that becomes the bottleneck. That thinking has to go out. Everything needs to scale. The only exception is if something is so infrequently used that it doesn't matter, but think a few times before making that decision. Anything heavily used has to be scalable, and you have to assume parts will go down and stay down, and the system has to heal itself. As long as those tenets are followed, you can build a web-scale system.

There is goodness in thinking about a platform that can keep expanding. That's how you grow your vision. I've also seen the flip side where companies roll out a great product, it sells for a couple of years, but with no room to grow, competitors catch up and it becomes a commodity. So you definitely should have a vision to keep growing. But what's very important is to not lose track of being master of one thing at a time, not a jack of all trades. A jack of all trades is a product that is not good at anything and doesn't delight the customer in anything, but does a lot of different things. Being master of one thing at a time means you have the ability to do multiple things, but at any given time you're doing a few things and you want to be good at that before taking on the next one. My philosophy is that unless we are delighting the customers with what's on the track already, we will not embark on too much more. By the time you make the current thing delightful, you're not doing nothing, but you limit the additional stuff being worked on. You can have an 80/20 rule: 80% working on making what's right now a delight for customers, and 20% working on something newer. As the 80% becomes delightful, you can move some of that 20% into the main track.

And then you try to delight the customer on that. So this is how you grow. But the vision absolutely, I do believe that the vision needs to be something that can grow. If the vision cannot grow, then this company will hit brakes at some point, and that's not good.

Yeah, absolutely. I can say a few words about that. First of all, please understand that sales is a distributed system itself.