The Mistakes That Took Us From 0 to $6B in 18 Months with Yinon Costica, Wiz

This episode is brought to you by Duplo Cloud, the leading dev and security ops. As a service platform, are you having Trouble hiring skilled DevOps engineers? Are you taking months to implement security and compliance? Or maybe you're struggling to migrate your applications to the cloud? Duplo cloud is a one stop shop solution for all your DevOps cloud automation and compliance needs, from infrastructure provisioning and application deployment to security controls, compliance, certification and alerts. For more information, visit duplocloud.com that's d u p l o c l o u d.com or get two months free access by contacting infoduplocloud.com I will build.

Only the things that I can be best in and I can maintain them over time. Have these two requirements. It's a very healthy culture to continuously remind yourself and the team what are the things that you don't build and why? When you start there are lots of things that sound really good and you always fear of missing out features that you may have done. In the end you have to choose a path and stick to it because if you start having FOMO and go too broad, you will definitely lose. I need some traction.

You need some traction.

Let's get some traction.

Hey what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction podcast host Lloyd Lobo. We're a community of over a hundred thousand people just like yourself on a mission to help you get the methods, the money and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more.

Explosive growth is every startup stream, but it's not easy, right? It's never a linear path and you see a lot of mistakes that can make or break your business's success as you're scaling your teams, troubleshooting your product and getting your first clients. And you guys have made some mistakes in the past that you've learned from that has enabled you to not only become the fastest growing cybersecurity company in the world, but also get to a 6 billion valuation in 18 months. So you're the VP of Product and Co Founder at Wiz. You come with more than 15 years experience in leading cybersecurity product development teams. You were the VP at Atalon, a leading cloud access security broker prior to its acquisition by Microsoft in 2015. And you've had a very interesting background from Israeli Defense Force to cybersecurity. Give us your backstory.

Yeah, so I'm a non Kostiga and yeah, I started in the IDF in an elite program. I studied math, computer science, physics in the Hebrew University. Then when I left the work there I did cyber. And then when I left there I founded the Adalum with the same team that I founded later on Wiz. Actually we are a team. We go for more than 20 years together and Adalum was a journey. It was a quick two something years where we've built like our first startup. It was a cloud security access broker, like a new Market Cosby and it was a quick ride and basically we grew very fast but were acquired by Microsoft in 2015. In Microsoft actually we stayed for five years and we actually grew the business from where it was in the startup, but all the way to Microsoft scale. So hundreds of millions of users, the entire piece of scaling up a product. And then two years ago we left to found Wiz. So again it's the same team at Wiz, we are running again. I was VP of products throughout the time. At Wiz we are doing cloud infrastructure security, a product that you connect to your cloud environment in minutes and basically it gives you everything you need to know about how to secure your cloud in the best way possible. So that's basically what we do.

Your experience as a veteran of the elite 8200 intelligence unit of the Israeli Defense Force, where you were heading the cyber division and you were awarded the Israel's Secretary of Defense Award for Excellence, what were some key development things you learned there that sort of shaped you as a founder? Maybe.

Wow. Lots of things. I think that you realize that in the IDF basically you realize how important it is to be the first work with the best team. And working with the best team has a lot of, I think implications on anything else you do. So it's. You're never like a lone wolf. It's always about working with the team around you and being successful in achieving like a higher goal that you work towards. And I think that also it requires you to be really the best. It's of course it's like you feel the pressure and the need to be successful right in what you do because it's important, it's. And you have the team to do it. So I think you develop some really good habits in how you think about problems practically programmatically with the team in a very, would say expensive like with expertise in mind because you want to be really better. And then I think it drives a lot of everything that goes and you can see a lot of the, actually the ecosystem in Israel that started from these type of teams that were in this very similar experience working together. High pressure, high requirements technically. And basically they formed the basis for what later on would be their startup. So that's definitely a shaping experience.

High pressure, lots of discipline and high work ethic here. So you said the best a few times. What does the best mean to you? Working with the best, being the best.

So I think in the end there is this internal need to think and you always. I think that as we grow in the space, there is so much knowledge to acquire, right? There are so many different areas and I think the need to know more the thing, the need to understand what is a true problem. How can I really solve a specific problem better than other solutions out there so I can actually have the lead? I think this is something that is essential to the way you think about and it includes a lot of things. So you think about how can I do it technically the best, but also how can I maintain it over time. So I'm building a team. You're not here for one time, you're here for the long run, right? So how do you build like an ecosystem that supports you in becoming the best? And if you think about it, in many cases, Israel has like only three years in the military. It's very short. So you have a lot of people that go in and out and you need to train them. So you need to basically have a really good understanding of what is this ecosystem that will make people successful and really good at what they do. So I think that's something that we think about and for startups it's a very similar experience, right, in many cases. So that's something we think about being the best.

Now you talked about you working with your co founders in the previous company and you've known each other for many years, but how did you meet them? How did you guys decide that this is the team? This is the one. How did you come together?

So we studied together, we worked together. To be honest, when we left to found Adelom, so we just thought it was a good timing for us to work together, uh, each one of us. We didn't know what it means, I didn't know what it means to be a product manager. But when we joined the team over time that what's really important is how does a team build itself and how do, how does a team can actually face challenges that they, that we face as we build a startup. And startup is just a long journey of challenges, right? And actually as a team, you learn to see what works for you, the team in the end, is the most important thing that we have because this is like all the checks and balances. Do you have enough trust? Do you have enough brains? Do we have enough muscles? So you need to think about the team as a core capability that will allow you to overcome all sorts of challenges that you see along the way and over time. So we worked together in the IDF and we felt like this is a really good team that we get along together very well, we like working together. It's fun for us. And that's how we started over time. So we had Adalon, we had Microsoft, of course, we have 20 years of experience now. It's more than I know my partner, right? So basically you get to see that this is a team that you want to run with. And I cannot imagine myself working with others right now. It's basically this is my team. So I think that's how we chose and we continuously choose. So when we move to Microsoft, we chose to be together. When we founded Wiz, we chose to do it again together. And it's rare, it's rare.

But if you have that trust and that connection and it's hard to replace and if you add a sort of big global purpose with the connection and the relationship and the trust you've built, you can dominate the world, as you say. Now, as you were together as founders through previous startups, did you like face any low points that you were able to navigate together because of this relationship you build? Maybe one or two tips there. Because it's really hard for people founding teams together and sometimes different disagreements creep in and teams break. And a lot of stats say that one of the biggest reasons teams fall apart is because of co founders. So what are some ways you found that in the toughest times, at the lowest points we can stick together.

So the key thing in the end is trust. Even if I can argue with my co founders all day long, but they know we all come from the better intention for the team. It's never myself, it's never one or the other. We really do what we think is best for the team. And the other thing is to know also that in the end, even within a founding team, there is a process to do decision making and there are clear roles. Okay. And within S4, so we know which, like who owns what. It's very clear. Although in many teams I see that there are overlaps and CTO, R&D, product, CEO, what does it for us? It's very clear. What do we actually each one are responsible for and how do we take decisions and who has the final word right in the end? So we all agree that if our CEO says so, we just agree. Okay. That they agree to disagree and we continue and we move forward because we understand. So I think these two mechanisms, trust, deep trust. Okay, really deep trust and then ability to decide and move forward are key.

You said something beautifully early on is people bid companies and companies don't build people. So the team is the core engine that drives everything. Now let's go back to building Wiz in the early days. How did you go about early customer development? How did you get your first customers?

Yeah, it's a great. So first we founded Wiz just during COVID time. Everything was shut down. It was all zoom. But basically we, over the years we grew a lot of customer focus in mind and it's easy to say customer focus, but in the end it's really and became one of our core values in the sense that we used our vest VC network and fans from the Adalum and Microsoft days. And basically we connected with over a hundred different CISOs like security officers that would be our potential customers. For a short time, like three months, we just had calls and calls and we practiced listening. Okay, Practice listening means that we came to a call and I think it's a very effective way. We could actually use 30 minutes a call even less. I would present for five, up to 10 minutes, no more. What is our agenda? Who are we? What are we thinking? That is the problem and the proposed solution. And then talking for 20 minutes, just listening. What does the customer has to say about this? And this actually drove us to really understand. Actually we pivoted three times. Okay. In these short three months, we pivoted three times. We thought one idea, but we realized there wasn't really the sense of urgency there. So we pivoted and we realized at some point that we actually hit on a point that was repeatable. Customers actually were tuning in when we actually said these words. Describe the problem, describe the solution. And then we honed on that specific problem. Now from that moment, we actually always were looking for the next step. So how would a customer actually use Wiz? So that was a mindset. What would make the customer use Wiz today and be valuable today? No design partners, no like actually using Wiz in their environment. And I think that was what was driving us much faster than what we would have done otherwise. So that's basically where we started.

And then when you were, I guess I'm actually fascinated by this. You went through three pivots in 18 months and grew so fast, became $6 billion company. What was the first idea? What were the other two pivots?

Okay, so it's actually great in cloud security. I can talk about cloud security, but we wanted to do cloud networking. At first we had a really great idea. We thought, this is the future. And we went to our potential customers at CSUN and everybody told us that basically, it sounds fantastic idea. Everybody told us it's a fantastic idea. But when we asked, okay, so what is the next step? Nobody could tell us. They told us we don't really know our cloud. I'm not sure where it would fit in my cloud because I have no visibility to my cloud. And that's why we started pivoting actually to the area where we are today, which is basically, I'm going to give you the best cloud visibility and risk assessment that you will know what you need to do and where you need to apply controls. And that was the initial. So we had a few steps there. But I think it's funny because we came from cloud security, but putting the head of the entrepreneur and asking questions, actually, we relearned what are the problems in cloud security? Which is. I think it's a really interesting insight. We started with the wrong idea. It wasn't urgent enough for customers. They didn't know how to apply and we weren't in love with the solution. So nobody thought, oh, we raised money on that solution, now we need to proceed with it. Or the CTO didn't say, really like this technology. We just moved on with the customer. And that's actually the important thing. And it was really short. It was just three months of, let's call it, like ideation and validation. And then we felt like we clicked. So that's on that product market thing. How do we know it clicked? Customers told us, okay, let's deploy. I want to see it in action. When you have a customer that tells you, like envisions the next steps, tells you what needs to happen in order to see it in their environment, then you know you're in the right direction.

And was there like a set number of customers or a KPI, like high retention or they were paying you, like, how did you know that this pivot is going to be the thing that explodes us?

We asked two questions. What are the next steps? And let's say it's all successful and we deliver up to the promise. How big of a problem is it to you? Is it a 10k problem? 100k? 1 million? Just give us an order of magnitude of the size of the budget you would allocate for that type of solution. If you have these two, you have intention and you have budget, then what's the overall area you're at? And we aimed, we aimed high, right? So I'm not saying any startup should aim, but we looked for the $1 million problem and also for the right here, right now type of. No, not the longer cycles, et cetera. We want it right here, right now and $1 million scale of problems. So that's how we actually narrowed down on this. That's how we knew we're in.

That's a good, that's a good framework to think about, especially for B2B startups. What is the size of the market, how high is the propensity to pay and what is the level of. And if you get a 10 on 10 on each of them, then you got to go, I like it.

You just go.

Now you talk about ideation validation. I want to double click on that a little bit. What are some. In your journey as a product leader, what are some key questions founders should ask potential customers as they're validating and ideating so they land on the right thing? Because they often say Steve Jobs said this, if you ask your customer what they want, they'll tell you they want a faster horse. Or Henry Ford said that they don't want a car. But it's not about asking the customers what they want, but really listening to the problems and coming up with the solutions yourself. But a lot of founders miss this. What are some key hacks or ways to find, to ideate properly and validate properly.

You're absolutely right. And that's something. It's very tricky, right? Because I think most customers, they didn't think about a solution like Wiz when they expressed like the, the problem they see in their cloud environments. But we came up with something that is different and I think there are two reasons for it. One, I think as startups we need to envision like how would an organization, it's not about the specific functionality or capability, but what would make a change in the organization your target? What would change the way things work for them? Processes, functions. I like always to think about one function and how can I really change their daily processes in a way that obviate a lot of the not doing faster things that they already do. That's only optimization, but actually doing differently things in smarter. So that's one thing that is also I think critical in getting the customers to ask what are you doing today? What do you think that you need to do differently? And the other thing is technology. I think that the access to technology that we have today, you can innovate a lot by technology. And we use some really cool technologies that enabled us to reimagine their daily processes. So the agentless technology we use, the graph technologies we use the ability to correlate very nicely the findings. So we make it easy. And the UI in Wiz is really simplifying things. And I mean I think these are key technology capabilities that we incorporated to reimagine the daily lives of any cloud security professional. And that's basically I think the two things we should have in mind, technology and changing providing them the ability to do more with their this. So these are the questions we usually ask what are using today? What would you like to do more? But you need to attentively listen and I'll just say one other less thing here, you need to emphasize with the customer in the sense that we ran also part of our role at Microsoft was running the internal cloud security. So we actually had the privilege of being in our customer's shoes for a long time. And this empathy actually creates the ability to think and understand them in a much, much more better way. So with this I would just say that it's better to do something a startup in an area you really know about and that you had the privilege of actually experiencing yourself as a customer.

Because customer empathy, you said it is really important in building products. It's just not listening but it's going deeper and feeling it with them. Understanding it and feeling it with them. There's a few questions relative to this topic that have come in that I'd like to take. What method did you use to connect with everyone to get these first few conversations? Did you have relationships in that industry that you could just reach out for the network or did you cold email? Did you use LinkedIn? And how did you pick the initial questions to ask your future customers?

So basically it's mainly through our VC network. So I think VCs today are really evolving the way they want to help customers, especially in the early phases. So we worked with the Sequoia Index cyber focused VC named Cyberstarts but they all connected us to their ESO networks and customers and that gave us the first access. I think it's you start from scratch, you don't benefit like they don't have anything specific but you do have access to this type. And I think this is the one thing when you do get funding from a vc, you should ask yourself, can they help me like get this initial network? It's very important. We also had some friends, some LinkedIn, some fans from, we knew from the past, but the majority was through the the VC network. And the other benefit of working through the VC network is actually that you work with customers that are ready in their like state of mind to work with startups. They want it okay. So it's not like they're going to be surprised. You don't have a product at all that you're just showing them slides, they know what they walk into. So that's also very important.

And a lot of people, they don't ask. And the best way to build these relationships with VC I found from my experience is just talk to them and tell them what you're working on and ask them for help even before you've taken their money. And you talk to a lot of them, you build relationships. A few will make intros, you keep them updated. It does two things. One, you get a warm intro to a potential customer or a validation partner. And the second, you've updated the VC so now you've built the relationship with the vc. So by the time you need to raise money, they're already there because they've seen you go from A to B to C. Now another question here is do you recommend paid pilots or free pilots? Like when you got these customers buy in.

I actually think everything has to translate to money in the end because it shows seriousness. So you can go on a free pilot, but it needs to be very clear that if this is successful, we're talking about a funded budget, a funded project. Okay. I wouldn't go for anything. Freeze easy, right? Anybody can engage, it's fun, it's free. We can give advice, but don't take. Another advice is don't take advices from people who don't pay you. They don't really live through your problem yet and it's, you need to see their level of engagement and a paid project is part of it. They are actually paying for it. They think it's a service, they want to get it, it is valued in their perspective. So I'm all into the paid.

I agree with you 100% and I tell this to a lot of founders because free is easy like you said. But if you build the muscle to get people to pay you, it only helps when you actually are at product market fit and have to build a sales team. It helps a lot from that perspective. Now what is your long term vision for Wiz?

So basically I think Wiz in the end is going to enable any organization development team to secure anything that they build or run in their cloud environment. I think that we have from multiple phases, like from coding to runtime, any clouds, any architecture you can choose, VMs, serverless bus containers, doesn't matter. And we want to do it in the simplest way possible. So in the end, Wiz will simplify cloud security for any organization out there. And that's a goal that in the end just make it streamlined because today it's far from being simple.

So you went from this early validation, you leveraged some relationships, some LinkedIn, some outreach, you validated the market, you got people to pay you for these pilots. But then you went from capturing 0% to 20% of the Fortune 500 in about two years or less. How did you do that? What were some tactics you used to acquire customers?

Actually we just built a product that as we said, had a good product market fit in general. And it scaled very nicely in the sense that the engineering team that basically I didn't mention it, but like Wiz and Adalum, we have the same core engineering team. So we have the same team. It's not just four, it's like more like 30 people that were started building Wiz at the get go. And basically these are the engineers that have done cloud security at scale for years. They just built a system that scales up and we've seen like the experience in building products really shows in how Wiz operates. So this actually allowed us to get access to Fortune 500 customers in a way that not only enabled us to get specific customers, it actually created the network effect because they saw it works at their scale with all the requirements on clouds. So basically it created a network effect that brought to us many of these customers. So you can see Wiz has very little marketing today. Actually most of it is like inbound that we get from customers that heard about it from friends. And that's how we actually grew so fast. And I think it's a, you let the product speak for itself. It's not product led growth. I know it's a buzzword right now, but basically it's a customer led growth. So it's even nicer.

I like that customer led growth. So your motion, your selling motion is still very top down. You sell to the CSO or CIO in an organization, but they experience it, they love the product, they bring the word to other people and that referral has been a big driver. But if you don't have a good product, then you can't get referrals.

Exactly.

And today as you've grown, has that evolved or still most of it is coming from referrals, the relationships and the network you've invested in.

So now we are basically scaling out. So now we have, I call it the scale out phase. So now we have something, we've experienced it at Microsoft. Like we start like with Addalon. Like any product you have it now you need the machine working right now. You need to scale it up to not only the enterprise market, also mid market across different geographies, the regions. So now it's a scale out and now it's about scaling out a machine that will work. We just sell with. So that's where we are focusing today of course, side by side with continuing innovation to the next product.

So to build this machine, what are some key ingredients to get build a successful scale out machine in your opinion and your experience?

Yeah, it's the same. I think one I'll tell you. Okay, so from the product side I think it's like before you go and get like the marketing and the sales machines are all running. So first you need to really have the notion of what is a repeatable success you envision. Right. So what is a type of cell motion? How does it look like from a customer perspective? We've done these mistakes in where we actually went to market. But we reiterate, we iterated on the market after we already had sales. Now this actually creates much longer cycles from there. We try to really do all of the first sales within the product and engineering team. So that helps us to stay really closed loop. The product was selling, the CEO was closing the deals and these were all the first deals. Now from there, once we saw the repeatable success, now you can move to the next. How do you grow sales and marketing? Same way that you grow every good team. You bring leaders that you can trust, that you have the same culture and you let them actually build their team and their processes and their system same way. Okay. So it's actually you need to extend what we've done with product, what we have done with engineering also to the sales and the marketing side. And you let them grow the team with them. And that's basically what worked for us really well. And we have a really good culture I think across the different teams that actually supports it. So it's again about the team and the culture.

So when you say culture, maybe unpack that for us a little bit. What does culture mean to you and how does it play a role in scaling?

Culture is probably the most important thing, even if you have a core people, core team of people that you trust, right? And we talked about it, how important it is, in order to scale it out, you need to basically build a culture that supports your values. So I'll give you an example. If we're saying we are customer focused and we want to partner with customers, so it means that I, as a founder, as a VP of product, I have to go on customer calls every time, right. 30% of my time I'm spending with customers on calls. Why? Because I believe in it. That drives a culture of customer focus. Not because I'm doing it, because now everybody is doing it. Right. And this becomes something that people actually understand that this is like the way we do business. And that's very important. And we are always thinking, for instance, if I'm being asked about should we do this on that right or left, My only question would be, what would benefit the customer more? Okay. How is it better for the customer to do this option or that option? And that actually drives the way we think about it. So that's culture. Same thing about trust. If we want to have trust, we want to have zero tolerance for things that are not invoking trust. We want to create trust as much as possible. Same thing about giving, like making like a DNI type of environment that allows anybody to be to actually bring themselves in their whole selves to work and to feel comfortable doing so. So it's the same thing. So we drive a culture of equality, inclusion. It's very important these things. And it all comes from the culture you create. If you lose that option to create a culture, it's very hard to repair. Okay. And you can see it with teams that other teams. We could see people coming from cultures. You won't retain the good talent if they don't agree with the culture you bring to the table. So that's something very important to have. And yeah, it's a DNA of the company.

And so your values, your principles define that culture. And at the same time, if the founders and the leaders don't actually do that versus a lot of times it's just written on the wall versus people behaving that and others won't emulate it. And you've got to do that day and day out, so others emulate it as well.

I believe only in lead by example. I can write as many values I want on slides and walls, but we have to live according to these values. And we need to expand every day again and again, because that's what we Believe in more than this. That's what we believe will make us successful. We believe this is the right thing for us, for the company. And we need to reiterate. So actually I don't like writing values on slides and I like basically seeing the values being exemplified in our daily operation now.

Zero to six billion in 18 months, that's huge. I'm sure there were some unconventional things your team did to turn that into growth opportunities. Right? To turn any missteps or things that you saw along the way to move so fast. So let's dive into those. You said launching moments before a global health crisis. How did that turn into an opportunity for you?

Actually, that turned out great because I was basically based in the US we were like. It was. If you remember the old days, in order to have a customer session, you needed to travel quite a lot. Capacity that you could actually operate in was very low. We founded Wiz on March 2020. Okay, that's exactly when everything shut down. Stock markets are down and there was a lot of uncertainty in the air. But actually it turned out to be that we got the best garage time to work in. We got basically a full year of quarantine. Everybody's just looking for something in exciting to do. We've built Wiz, we are talking to customer. Everybody was available. We thought we won't be able to have access to customers, but it was actually the contrary. Customers loved to talk, to innovate, like changing atmosphere, giving feedback in that time. And it was much easier thanks to remote work. So that actually switched like we realized it only a few months later. But at the time we really thought it's the biggest mistake. We left Microsoft. We led the cloud security group at Microsoft. It was at least a billion and a half dollar business. And we founded Wiz. And then everything crashes. It's good, we're happy.

That's how we turned turning sort of making lemonade out of rotten lemons maybe, or lemons now, starting with the wrong name. Tell me more about that you mentioned.

So we said we started with cloud networking. Actually the initial name of Wiz was Beyond Network. So we really wanted to do cloud networking and we named Wiz Beyond Networks. We thought it's cool, but then we changed the idea. But the problem was that we kept being routed to the networking team because of our name. And then we said, wait, we have to change the name. So we actually went back to change the name. In the US it's easy, in Israel it's much harder. It took us a lot more time. But My take on this is don't start with a name that basically describes or correlates to your first idea. The idea would probably change. You don't want to change the entire company. Choose something like Wiz could describe anything. So basically choose something generic that you like and you can give it the value you think of. So that's something we also learned not to do.

How did you get the domain name?

Actually we chose the name because we got the domain name. So it was the other way around.

Basically you're saying is pick some generic name that you can get the domain to and you'll give it the meaning and the brand, which is amazing. Actually. I've rarely heard this, but this is unique and interesting. You also talked about recruiting too many employees at the start. I think you came with your whole team. Tell me more about that. How did that work or didn't work? Because most startups are very small, right?

Yeah, yeah. So usually they'll tell you start until you get to product market feed, then start like recruiting. We just, we are a team. So it means that the entire team just basically we started March, in April, we had half of the team, in May we had all of the team. So basically we had the team with us. And basically we didn't have an idea yet. We were still iterating, ideating. So actually the any according to Playbook, that's a mistake. But in fact what we actually did in this time we built some very. So think about having the best engineers building the best infrastructure, like choosing the best technologies, relearning everything they were used to, actually upgrading to the newer technologies, to the best technologies, assessing them and having enough time to set the foundations we did that actually allowed us to move so much faster once we got the idea, once we honed on the idea. So that allowed us to move so much faster. And that was critical. Okay. So that's something that we actually benefited from. So think about the cicd, the delivery pipeline, like the ability to automate testing. Everything was too thin.

The question here asked is how much did you pay for the domain name?

Not a lot. That was like quite little back then because it didn't have a brand and a name. Now I'm sure it will be more.

So now you also learn from past mistakes that you implemented at Wiz from Adalon. Let's talk about building features that aren't scalable.

Yeah. So I think that in Adelon, in startups you tend to build a lot of things that you're feeling like, okay, we're going to try it out. And I think it correlates a lot to the notion of what is an mvp. So you say let's try something small and then let's see if it sticks. It's not the idea behind an mvp. And I think that what we've learned over the years, that everything should be very deliberate when you actually ship features. So there is no trial and error in that sense. You should be very deliberate on what you deliver and how would it like, I always call it like the lifecycle cost of a feature. And that's basically something that we learned over time. We didn't do it in the past, so we used to ship a feature and then we thought, oh my God, now we need to do more to support it. Now we are very deliberate on what we ship and what we don't ship because we understand if we're going to deliver this feature now, it's actually going to require us to invest in it this much in the future. So having this really end to end view on the lifecycle cost is critical because then you can actually maintain your technical debt. So that's something that definitely.

Yeah, I want to double click on this a little bit. Right. Because sometimes, like you said rightfully, what you don't build is more important. How do you prioritize what to build and what not to build? What is the framework for that?

So for me it's simple. I will build only the things that I can be best in. So I can always literally be the best solution in doing it. And I can maintain them over time. So only when I have these two requirements and maintain them over time means that the product is round, I can support the deployment, I can support customers in using it, I can actually maintain it performance wise, cogs wise and so on. This is what it means to support it over time. And then also I want to be the best in it. I don't want to ship features that I know I'm going to be less than others and won't be able to defend them. So basically this is how you choose initially, like in the, especially in the first capabilities of the product, that's what you choose to focus. And I think it's a very healthy culture to continuously remind yourself and the team what are the things that you don't build and why? Okay, this helps you to focus. And focus is the most important thing. I call it the entrepreneurs fomo because when you start there are lots of things that sound really good and you always fear of missing out features that you may have done in the end, you have to choose a path and stick to it. Because if you start having FOMO and go too broad, you will definitely lose. Okay, you're losing time, you're losing focus, you're losing customers because you want to be the best. So that's something that is very important on what you don't build.

I like that. Be an inch wide and a mile deep rather than going too broad and losing focus, which caused many companies to fail. Now, you mentioned product debt here and technical debt. How do you determine product debt in a company?

Okay, so product debt is. I don't know if it's a common term. I actually invented it for myself and the team. But actually product debt is a. If we think about life cycle costs. So product debt is anything that is not covered today. So product debt would be, for instance, lack of support for scale, lack of technology debt for sure. But also things around. You cannot build a product that is not round. You cannot build a product that is not feature complete. So you can start with one feature, but if you go too far and now you are leaving two space behind you, you need to go back and implement all of these features. And now you created a product gap because the product doesn't feel right, doesn't feel like it's complete. You're missing buttons, you're missing functionality, and that's something bad. Okay? That's something that customers are very sensitive to and you really don't want to be in that position. So product debt is the overall debt that you have in supporting the product and making it like complete.

Now talk to me about signing the wrong customers. That sounds very interesting. And maybe some, some sort of, as you look back, some. Laughs.

Yeah, signing some wrong customer. I think that there is, in the beginning of a startup, it's you're eager to sign customers. And what we have learned that we did some, we went to like with some customers that actually dragged us into direction that we didn't want to go to. That's in the Adelon days and we invent, we found ourselves investing in areas that actually we're really far from where we thought we should be investing just because we had this and that customer. So that's something that you should be very mindful of if you are seeing like outlier customers. It's not that there are bad customers, it's not that they're wrong, but these may not be the right customers for you at the current time. And it's very important because you don't want to have customers that will churn on you or will expect one and say there was one CISO that we worked with and afterwards we like basically. So we asked why Wiz? In the end it was a Fortune 100 customer. And he said something that was actually fascinated me. He told me Wiz was the only vendor I ever worked with that consistently under promised but over delivered. And when he said that, I realized that it's keep your focus. You don't want to go with the customers, that you won't be able to live up to their expectation. You don't want to over promise, stay very focused with the customers that you know they will be happy with you. And that's, I think, how you choose customers wisely.

Now, cybersecurity and specifically cloud security is very hot these days. What is your view on the market and what are some interesting trends you're seeing in the space overall?

So we accrued some. I think there are three motions. Okay, One, digital transformation. We're using technology more than ever. Second, cloud is happening, right? So most of the technology we use is either in the cloud or in the process of migrating to the cloud. And obviously cloud grows accordingly. And the third thing is that I think that most of the technology that we built in the past was not really with security in mind in the sense that security came after the fact. So we created a whole lot of, I think security gap. And it's like a global warming, right? It's like the climate change. We keep on building, but we don't close the security gap. And we're seeing the impact of this in the daily life. I think cyber is becoming much more present in the sense that we feel it, we hear about it and we know it's there. And we were, many of the folks I know were impacted by it directly either as PII leaking, either as their company was breached. So that's something that we really need to understand. And the gap that was formed is like a huge vacuum that the market will need to close over the next few few years. It's a must. So you can see now with the executive orders in the US like the market is shifting dramatically to close this. But that's basically, I think my view, at least on the cybersecurity market. We created a gap, we are paying for that gap and now there is a huge shift in closing that. And it's great. Like we realize there is a problem and we are here to solve it. So that's definitely there.

As you build your product and your company, what do you think in the product made it different from Everything else in your market because they're also competitors. Right. And when you build a $6 billion company in such a short time frame, you start attracting all kinds of competitors. So what makes it different than others?

Yeah, we went into a red ocean in the sense that there were dozens of companies doing the same thing, even some very big ones. But we realized all of them, I call it like first generation. They solved some of the problems, but they didn't get the real problem. Okay. And in order to solve it right, I think what was missing is simplicity overall. So making it simpler to do cloud security and the way to do it simpler, and that's the technology we applied is basically first, forget about agents. Agents is just complexity. It's a nightmare. So we removed the need for an agent because we developed like this agentless technology that helps you like analyze workloads, containers, serverless without running a single agent. That's again thanks to cloud APIs. That's fantastic. It removes like 90% of the friction of any other cloud security tool. Now the second thing is ease of use. I think that most of the world today, most of the security teams, they don't know cloud security to the level they are expected to know because it's simply too complex. So one of the key roles of Wiz is to simplify their crawl, walk, run process in a way that doesn't make them feel left out, in a way that supports them in that journey. And I think that ease of use was actually different than anything else in the market. And the third thing is like, how do we think about delivering a really actionable type of view and security? His done the scene of I'm going to show you everything that is bad in your environment and you're going to be bombarded with alerts. That's the wrong approach, period. Okay. The right approach is to tell you I'm going to show you everything that is wrong in your environment, but I will show you where to start from. And that's key. I will help you find what are the key things you need to focus on. And that's basically, I think, where Wiz really differs from others. And it shows when a customer just connects with, even though they had other solutions in place, they're saying, oh, this is completely different. This gives me the ability to do so much more than what I was doing until today. And I think that's a differentiation.

You talk about simplicity a bunch and I want to unpack that because as companies are building products from idea to product, market fit and potentially hyper growth, they often Think about, oh, I got to add this feature, the other feature, they make it inevitably very complex. And that complexity was maybe good back in the day. But complexity doesn't equal growth. So unpack simplicity for us. How should startups think about building their products towards hyper growth with simplicity?

So I can tell you, simplicity is everything. Complexity is the enemy and you should really think about it that way. Complexity is an enemy in the sense that it will prevent you from doing things right as you scale. So there was a saying in Hebrew, if it won't be simple, it's simply not going to be okay. So basically you should really, I think appreciate the value of simplicity in anything that you do, in the products you deliver, in how you build your products, in how you think about the problem. You have to be able to explain everything in a simple manner. If it's not simple, then it's probably not there yet. Okay, so it's a key component to not only to how we build products for scale, but in anything that we do. And that's like really one of the. You talked about values and culture. Simplicity is a value. Don't tolerate complexity, it doesn't have to be that way.

So what are some examples? Maybe in products you've seen that can be complex, but then if you were to take a stab at it, you would remove some things, maybe just one or two things to make it, crystallize it for the audience.

You can get a lot with an agent, okay, but the agentless piece makes things simpler because you don't need the agent, you can get a whole lot without the agent. So why would you go with the agent piece? That simplifies 90% of the headache. So that's simplicity, another thing of simplicity. So I'll give you an example. With security, I don't know why security products love bombarding you with technical details, but to be honest, the people who are actually consuming the feeds from the security products, usually they don't care about the technical details, they just want to know how to fix it. And I think this is something else that we did. We basically used a graph instead of explaining everything, we use like a very simple graph that tells you here is a problem, here is why you should take care of it, and here is the one point you should take an action on. So making it simple, using visuals, using more analysis in the, in the like back end, don't make your users work to drive value out of your product. Just make sure it's valuable at the get go. So that's like the type of simplicity that you want.

A question here? Anil asks is, how do you measure what is complex versus simple? Because maybe you need a number of features to serve the customer, to get that core outcome for them.

So you can always be more complex, right? You can always build more complex, but it's much harder to build simpler. So the question is, in general, the way I think about it is again, going back to the lifecycle costs, do an exercise with yourself and think about how would it scale, how would it work, how would I be able to support it, how would I be able to deploy it? How much time does it take to deploy? So ask yourself all of the tough questions on the lifecycle cost and then multiply it by the number of customers you want to have. Of course you will have some features, they have to be complex. But actually, if you put simplicity as a value, you will see that you can do things easier. You can give up some of the functionality in order to make it simpler. And it's better. Simpler is better. So that's like the exercise that I'm doing. And I can give you another exercise. When we have LPMs and we have multiple products in the products within the portal, but when there is a need for a new page, okay. Or a new UI construct or a new area in the product, it always has to go through a, like, through me to question, okay, why do we need a new page? Couldn't we use one of the other constructs? Couldn't we basically double down on what we already have to simplify it? And that's like another practice that you can do. You can take it to your environment, but in general it has to be simpler.

Now, tied to that, as startups are building from idea to product, market fit and potentially hyper growth, what are some key KPIs you recommend measuring, especially from the product side? And what are some key KPIs that are top of the mind for you?

Yeah, I measure three things in the end value, like how much value do I give to the customer? That's mainly like the question on the, you know, budget, is it like a 1k, 10k, 100k, $1,000,000 problem? Tell me how valuable it is for you. So that's one second is time to value. How much time would it take you to get to this value with an average customer? Would it be tweez? It's five minutes. With other tools, it may take months, maybe years to deploy across your environment. So ask yourself your time to value question. And the third thing is, how much debt did you accrue along the way like if you are building fast and you accrue a lot of debt, you're just going to suffocate yourself very soon. So you need to make sure that as you go forward you don't accrue too much debt, so you can continue and run fast. The other way to measure debt by the way, is like dev velocity. Are you seeing your devs running fast and not slowing down? Because if they are slowing down, basically you accrued too much debt and now they are starting to pay to it for it. So that's basically the three factors, at least that I think. If I think about KPIs, that's the way I think about it.

Value, meaning size of the problem, time to value, which is huge. I think it's a massive one. And that time to value is also the leading indicator of retention. Probably right. Customers don't get a time to value, chances of them churning are higher. And the technical debt, how do you determine though that you've accrued some technical debt?

Only the velocity. How do you put this? In the end, it's the velocity I can share with you. Like in Adelon we grew like in the first startup we grew from 20 developers to 60 developers but the productivity didn't grow. Like we kept the same pace of feature releases. And the reason is that we accrued too much debt and we had to pay like the 40 developers to close the gap of the first year. So basically you can really measure like how many engineers do you have, what's the capacity, the velocity that they have. And you have to see that it's not slowing down. If it slows down, just ask your VP, R&D, what do we need to do to improve velocity? And then you should invest in closing that debt. It's important, it's really important. If you run, you want to run a marathon, not a sprint. If you want to run a sprint, do whatever you want. If you want to run to a unicorn to grow to bigger, so then you basically have to run, prepare for a marathon.

Beautifully said. Life and business is a marathon, not a sprint. And you gotta pace yourself to run that. Now your organization you mentioned is flat and that is very interesting because a lot of companies are very hierarchical and they think that it's needed. Tell me more about how the company is structured and why this flat structure is beneficial.

So we love, we appreciate independence and accountability and responsibility in every individual. So in order to achieve that we basic inefficiency, of course. So in order to do that we actually created a flat Organization where everybody is working, everybody is working in squads. So it means that if I have a PM, 1, 2 devs, a researcher, they don't have like team leads to watch them over, they just work as a squad to accomplish like a feature set and so on. And they work in the long run together. And we actually. So that allows us to move very fast. We don't have layers of communications. If I need something to get done, I can go to the developer, just talk to them and they can basically implement it. Same thing about the pm. So it's very flat in that sense. The flip side of having a flat organization is that we need to recruit a certain type of people that can actually manage themselves very holistically, see the end to end prioritize and do all of this themselves. And also, most importantly, they should know when to raise a flag when they need help. They need to know when they need help. So that's like another skill that you really want to attribute that you want to have when you recruit. But as to it, we are still flat. We're growing very fast and still flat. That's within the R and D org, Right. In the marketing, sales, obviously it's a bit different, but in the R and D organization we kept flat.

How big is the company right now? How many people?

So we are over 300 people.

Wow. And what portion of that is R and D?

About a third.

About a third. So keeping 100% flat organization. And I like the squad structure. You have a pm, you have a few devs, you have a UX person, and they know the mission, the values, the purpose and the metrics and they're autonomously driving that goal. You're not micromanaging them and you can ask a bunch of people. But how do you find this kind of people? Chris asks here, do you do some sort of personality profiling? Because some people like to work, or it's not that they like to work in a hierarchical structure, but rather years and years of conditioning has made people accustomed to working in a hierarchical culture or structure where they're looking for direction and they're looking for praise, feedback and approval. So how do you profile and find these kind of people?

You're right, it's tough. It's part of the challenge in recruiting to the team is actually profiling. Exactly. Those that are independent, they love working in a team. Okay. So they have to be team players, they have to self pace really good. So yeah, we profile them and it's part of the challenge of building like an A team. Right. You Want to really make sure that you created this fabric of really good people that can actually work together in any crossing you have. So that's again, going back to culture and how you maintain a culture across your team.

Now when you interview people, are they like on your product team, are there one or two things people say or signals like that you're like, okay, I want to work with her, I want to work with this person. Or there are some things they may say that you're like, ah, this is not going to jive here.

So I actually love many things. I love the curiosity, the humbleness, right, the ability to say, listen, I don't know, I love this. I'm talking to PMs who have done, I don't know, container security for years now and I'm asking them so about this space and they start by saying, listen, I'm not an expert in this, but guess what? You are an expert. But you see that they have this curiosity to know more and you see that they are eager to learn. And the other thing that I'm always looking at is, are you listening? Are you, do you really listen? Do you try to understand? Do you pause to make sure you got the right things? Are you a team player? So these are the type of things that I'm very sensitive to in ams, for instance. But of course R and D is a bit different but for PMs for sure.

Now, as you look back at your awesome career across successful startups and working at a large company, is there anything you wish you did more of or wish you did less of?

So I'm going to say something about myself, right? I don't know if it's true to him, but I always feel like we. I could have gone faster. I was in many cases, I think I was waiting for a feedback loop that came eventually but in the end I realized that I could have gone faster. And when you see like the cycles in whiz, it's like in Adelome but on speeds. Like we basically didn't wait for the feedback loop. We just. So we can recruit good people. Great, we're going to recruit all of them. We can raise money. Great. We're going to raise money. We don't have product market fit. Great. We're going to keep iterating with custom with customers to get it right. So it's only pushing for faster and faster. It's almost like the realization that you can lose the market by not running fast enough and you can run faster. So that's something we realized. I think that it's easier said than done, but it's. I feel that this is something that I wish I did more like run faster every moment.

I don't know how much faster you can run in 18 months getting from 0 to 6 billion, but it seems like you've ran on fire here. What's one piece of unconventional advice that founders ignore but should. I'm sure you talk to and mentor dozens of founders. And what is one thing you've found that people don't listen to but actually should focus on?

So I talked about a lot about team building. Right. And I know, I think people realize that it's less about the idea and more about the team. Build a team. But actually an unconventional. I know it's not said much, but it's almost not like not learning from failures, not stopping to learn from failures. It's actually doubling down faster on success. Success. Okay. So I think it's very human to look back and interrogate and think what did you do? Where could you have done better? But actually the question is always like, what worked for us and how can we do this more and faster? And don't stop to pause about. There is too much done with like mistakes going back. Just go faster and faster. Right. And that way you improve. You realize what's working for you, what is good. So double down on success. That's one piece I don't know of.

Advice that's actually great. Don't belabor on things that didn't work and do like analysis paralysis. Just keep doubling down on success. Because every little bit you do better on successes, it compounds and help you grow effectively. Has compound interest here. Are you active on any social channels? Where does the audience follow you?

Oh, LinkedIn mainly and the Wiz blog of course.

Wishing you all the best. Hopefully the next time we speak. It's double the six. It's a $12 billion company. Thank you so much for joining us.

Thank you for listening and we hope you enjoyed this week's episode of the Traction podcast. If you enjoyed the show show, please leave us a five star review and you can find all the information mentioned in Today's episode at TractionCoff IO that's T R A C T I O N C O N F IO.