Shashwat Sehgal has been in the tech industry broadly for 15 years. He started out as an engineer, but eventually, worked his way towards product and the business side. Outside of tech, he enjoys spending time with his family. He's into sports, loves to play tennis, but admits he hasn't played pickle ball yet because the courts are always booked. He also enjoys reading, in particular historical narratives or autobiographies.In his prior years, Shashwat noticed that developers spend a large amount of time securing business assets in the cloud. He dreamt of a world where this was just an abstraction layer on top of the cloud, making it easier for developers to complete the task.This is the creation story of P0 Security.SponsorsP0 SecuritySpeakeasyQA WolfSnapTradeLinks https://p0.dev/https://www.linkedin.com/in/shashwatsehgal/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
Our very first deployable version of a product which we put in the hands of an actual customer was probably within three months of when we started. By February of 2023, we had our first customer deployment. It worked, thankfully, and we were able to close that customer contract by March or April of 2023.
And ever since then, it's been a stream of, okay, let's find another customer that looks like the last customer we closed and make sure the MVP works for their specific environment. I'm Shashwat Sehgal. I'm the co-founder and CEO at P0 Security.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Six months of moonlighting. There's nothing at the back end. Who share what it takes to change an industry. I don't exactly know what to do next. It took many goes to get right. Who built the teams that have their back. The company is its people. The teams help each other achieve. Most proud of our team.
Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as a group. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve. Took it off the shelf and dusted it off and tried it again. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology.
All this and more on CodeStory. I'm your host, Noah Lappart. And today, Hoshashua Tagal is helping you secure cloud access in minutes by securing and governing all forms of cloud identity. This episode is sponsored by Speakeasy. Grow your API user adoption and improve engineering velocity with friction-free integration experiences.
With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf. QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes.
With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolfpack at QAwolf.com. Shashwat Sehgal has been in the tech industry broadly for 15 years. He started out as an engineer, but eventually worked his way towards product and the business side. Outside of tech, he enjoys spending time with his family.
He's into sports, loves to play tennis, but admits he hasn't played pickleball yet because the courts are always booked. He always enjoys reading, in particular, historical narratives and autobiographies. In his prior years, Shashwat noticed that developers spend a large amount of time securing business assets in the cloud.
He dreamt of a world where this was just an abstraction layer on top of the cloud, making it easier for developers to complete the task. This is the creation story of P0 Security.
Our mission as a company is to abstract away security for developers. In our prior lives, we have seen and experienced the fact that developers spent an inordinate amount of time securing the company's most prized assets, which is the cloud. and we believe that security should just be an abstract layer which developers do not have to worry about. That is our mission.
Where do we stand as a product? What do we actually do? Our goal is to secure access in the cloud. We've observed over time that the number of identities or the number of entities that can take any sort of action in the cloud has just exploded over the last few years.
It's not just human users or groups of employees that can take action or access the cloud, but increasingly it's also workloads, service accounts, quote-unquote non-human identities. And we believe that there needs to be a product, a company that can secure access for all of these entities, right?
Be it an engineer, be it a contractor, be it a sales engineer, or be it a workload or a service account. They can secure the access for all of these entities across the lifecycle. The three co-founders in the company are myself, the co-founder and CEO, and Greg, who's the CTO, and Nathan, who's the VP of engineering.
Nathan and I used to be peers at Meraki, Cisco Meraki, where we built and led the SD-WAN business unit. And then Greg and myself both worked at Splunk for a while where we were building up the observability platform. And in each of these spaces, what we realized was that the cloud native way of application development is extremely powerful.
It gives a lot of very sophisticated primitives in the hands of developers to build things quickly like never before. But it's also got its own pitfalls, which is that it can make application development very complicated. And this gives security teams a very hard time securing access. Securing access as a use case has been around for the longest time, right?
The only thing that's evolved over the last 20-30 years is what it is that organizations are interested in securing. Before internet, securing access mostly just meant you have your physical buildings and you need to secure access to the physical workspaces.
In the early days of computers, the early days of the internet, when the most prized possession of a company used to be a data center and specifically data and applications hosted within a data center. In that world, securing access really just meant securing access to the network perimeter of the data center.
And now, as the world has become more cloud-native, the prized jewels of a company are increasingly in SaaS and in the cloud. We are firmly tackling the problem of securing cloud access. That is what we do. Help secure access to a company's crown jewels in the cloud, no matter who's trying to access that infrastructure or that data.
So let's dive into the MVP, that first version of the product you built. How long did it take to build and what sort of tools were you using to bring it to life?
It's a never-ending process, really. I wish I could say that there was a point in time when we knew we had nailed down the MVP. Our very first deployable version of a product which we put in the hands of an actual customer was probably within three months of when we started. We started the company in late 2022. We started building and by February of 2023, we had our first customer deployment
It worked, thankfully, and we were able to close that customer contract by March or April of 2023. And ever since then, it's been a stream of, okay, let's find another customer that looks like the last customer we closed and make sure the MVP works for their specific environment. That has been our philosophy ever since then.
Always keep shipping, keep building whatever is necessary, have very tight feedback loops between customers and between our engineering team so that we can iterate, get their feedback and if necessary, build the next feature that would help them gain even more value out of the product. In terms of what we used, I think we've been very nimble in using all kinds of tooling.
Like our stack for the most part is in TypeScript. We run on both GCP and AWS. We are heavy users of Terraform, of Kubernetes, and we've been experimenting very heavily with Gen AI and Copilot as well. So In short, I think our design and our product development philosophy is use the best of breed solutions, all the latest and greatest cloud native development in Gen AI usage. Just keep shipping.
This message is sponsored by SnapTrade. Link in-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This episode is sponsored by Speakeasy.
Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product. Shorten the time to live integration and provide a delightful experience for your customers.
With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination. Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag.
Visit speakeasy.com slash codestory to get started and generate your first SDK for free. So tell me about how you mature and progress the product. How have you done that? And I'm curious about how you go about building your roadmap. How do you go about deciding this is the next most important thing to build or to address with PZero?
Any decisions like these are never made in a vacuum. We almost always have customers drive our roadmap, which means that any week, we are probably speaking to at least five, if not more, customers across existing customers, new prospects, ongoing POCs, probably closer to 10, I'd say. And we let our customers define our roadmap. We are very open in...
aggressive and soliciting feedback from all kinds of customers. And from there on, we try to triangulate all the feedback that we are receiving. And we try to have an opinionated view on, OK, what are the kinds of customers that are a good fit for us right now? And let's say that's a particular segment. Let's call it segment one.
And eventually we want to go from there to all kinds of segments across customers, big and small, across verticals, across geographies, right? So then we always try to have opinionated views on, okay, how do we go from segment one to segment four, for example, right? Where segment four could be representative of the vast majority of the market.
And then we always try to sequence out the steps that we would need to take from segment one to segment two, three and eventually four. And we always we try to map what are the gaps that we have in our current product and what would it take to start selling to customers in segments two, three and four on a consistent basis. And we take all of that feedback into account for building our roadmap.
But most importantly, we ensure that this roadmap is never set in stone. And we try to be as nimble and flexible on revisiting this on some kind of an ongoing cadence.
So I hear you saying we. Tell me about how you went about building your team. And what do you look for in those people to indicate that they're the winning horses to join you?
So there are three attributes that I look for in a team. First, almost always they have to be intellectually curious. It's almost a cliche that you hire smart people, right? But I'd say you have to go one step beyond and hire not just smart, but also curious or flexible people. Because smart people sometimes can be very opinionated on, hey, this is my way or the highway, right?
This is the right way of doing things. And sometimes that may or may not be the best way of building a company. So for me, the number one attribute almost always is, hey, is this person that I'm hiring, are they intellectually curious or not? Secondly, they have to be super high integrity. That goes without saying, if you hire a bad Apple and...
very soon the disease could spread to the rest of the very small company. Having high integrity people is an absolute must have. And last but not the least, so after intellectually curious, after high integrity people, you almost have to look for People who are looking for a platform to excel in, right?
In other words, they have some kind of a chip on their shoulder or willingness to go above and beyond, right? Different people call this different things. Some call it extreme ownership. Some call it having a chip on their shoulder. For me, this third attribute is, okay, is this person going to come in and just take the bull by the horns or not? Are they willing to take extreme ownership or not?
This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf. QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes.
With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs? Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. This message is sponsored by SnapTrade.
Link in-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. So let's flip to scalability. And this will be interesting given, you know, what you've built and who you're building it for. How did you approach scalability?
Was it built to scale from day one? Or were there areas where you had to fight it as you grew?
If this company were to be super successful, then I would want to say the largest organizations of the world, let's call it, for example, the largest banks in the world, as an example, JPMorgan Chase, right? They would be using us to govern access to their cloud.
As you can imagine, at that scale, the cloud, it increases in complexity with the total number of employees as well as the total number of workloads within any particular organization.
Which means that if we, for example, have to provide visibility into AWS or we have to provide control over GCP, then we'll have to eventually build a product that scales with the total number of identities within that particular cloud.
What this means is that we are always building an architecture that we eventually want to scale to tens of thousands of employees and hundreds of thousands, if not more, of workloads and machine identities. That is where we are looking to land.
And the foundations of that architecture, when we laid down, we always wanted to make sure that, hey, we don't have to re-architect large parts of our product as and when we hit that scale. But at the same time, it's also important to not boil the ocean when you only have like 200, 300 employee companies as your customers in the early days.
So I would answer that question as by saying that we laid down some foundational elements of an architecture which will allow us to scale seamlessly to hundreds of thousands of identities over time.
But at the same time, we also did not go overboard in making sure our architecture was performant at scale, especially when we were servicing early customers, which were not more than 100, 200, 300 engineers accompanying us.
So as you step out on the balcony, you look across all that you've built with P0, what are you most proud of?
I'm proud of how far we've come. I'm proud of how many customers we have serviced, especially at scale. And more than anything, I'm proud of the culture of ownership in the team that we've been able to establish where people are stepping up to solve extremely difficult problems day in, day out. At the end of the day, what we are building is not something that has ever been attempted before.
And what I mean by that is if you look at identity as a space, there are various companies that are trying to solve small problems within the overall identity domain. And ultimately, we believe that the winner in the entire identity space will be someone who can build a performant platform as quickly as possible and get it to the market as quickly as possible.
But building a platform required is a challenge all by itself because you have to keep building. There's so many things to build and you're almost always prioritizing what needs to be built to get to your next milestone, your next landmark, your next bunch of customers. It almost always becomes a race to make sure you have what you need to be able to get to where you want to be.
And I've been extremely proud of the way our team, our small and extremely mighty team, has stepped up to the plate to be able to deliver all those challenges.
Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
I'd be very scared if we were not making a mistake. In fact, I won't even say it's almost impossible. I'd say it's absolutely impossible to have impeccable execution on your way to building a billion dollar company. It's just not possible, right? Just because there are so many unknowns, there are so many ways things could go wrong.
If anything, what's most important is to just make sure you're making the best decision in any point in time, even though you may have little to no information, little to no data points to make that decision. What's even more important is not to just rest and sit back, but it's super, super critical to make sure if the decision turns out to be wrong, you course correct as soon as possible.
Sometimes only 60 to 70% of the people you hire work out, right? And when they don't, you have to be absolutely ruthless and quick in making sure that you rectify your mistakes for the benefit of both the individual and the company. And similarly, on the customer front, you might think that a customer wants feature XYZ.
But what is often left unsaid is they might be articulating a feature just because they haven't thought of alternative ways to solve the actual underlying problem. Right. And so many times it turns out that you have misdiagnosed the problem and you are going too far out, building a feature, missing the forest for the trees.
And again, in instances like this, it is absolutely imperative to take the MVP approach. Just keep iterating, keep shipping, creating a very tight feedback loop between the customer and the R&D team so that you can rectify or you can catch the mistakes as soon as possible. And more importantly, rectify them before too much time has been lost. That's what I'd say, right?
There's no one big example that comes to mind, but I'd say lots of small mistakes that we have made over the last two years. And thankfully, we've been able to rectify quite a few of them.
What does the future look like for P0 security, the product and for your team?
So we recently raised our series A around the funding. It was led by Sin Ventures with participation from our existing investors, Lightspeed and Zscaler also came in as a strategic investor. So now having raised some cash, the focus in the short to medium term will be to start investing in our team.
In particular, we want to double our engineering team over the next six to nine months and commensurate with that. We also want to start investing in our go-to-market team by bringing in the right sales leader who can take us to the next level. We found some product market fit in a couple of customer segments. So tactically, it will mean that how do we flood the market in those customer segments?
How do we gain more traction and also start building a product for the next customer segments that we want to address? All this while, the overall vision is to build a platform that can solve for cloud access governance for all kinds of identities, right?
At the end of the day, we want to be known as the company that helps secure cloud access for customers, small and large, no matter where that access is coming from.
Let's switch to you, Shashwat. Who influences the way that you work? Name a person or many persons or something you look up to and why.
The biggest influence has probably been my mother in many ways, large and small. That's probably someone I look up to in terms of their work ethic, as well as integrity when it comes to their professionalism. And again, she's worked as an educator for most of her life. Within the tech industry, I'd say the one role model I have is probably Paul Graham.
His essays around, you know, the culture of building and startups in general. I've been through, I've gone through them all and they've definitely influenced me a lot in the early part of my life.
Last question. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world. Can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
Go for it and don't stop. Just keep pushing. There'll be a lot of obstacles. Just don't give up. Keep pushing until eventually the rock will gather an escape velocity of its own.
That's fantastic advice. Well, Shashua, thank you for being on the show today. Thank you for telling the creation story of P0 security.
Thank you. The pleasure was all mine.
And this concludes another chapter of CodeStory. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.