Sandhya 00:00
Our guest today is the wicked smart Wei Lien Dang. Say hello, Wei. So I'm lucky to call Wei my partner at Unusual Ventures, where he leads our seed investments in security, machine learning, and web three infrastructure startups. But before joining the dark side, Wei was the Co-Founder of StackRox, and StackRox, if you haven't heard of it, was born in about 2015 and actually became one of the first startups in the container security world to offer a Kubernetes native solution. And if you're not familiar with Kubernetes, that was also a very fast-growing movement in the DevOps industry at the time. More recently, in 2021, StackRox was acquired by Red Hat for hundreds of millions of dollars; I'm not allowed to give you an exact number. All right, Wei, how are you doing today?
Wei Lien Dang 00:57
I'm doing well today. Sandhya, thanks for having me on to chat about the story of StackRox.
Sandhya 01:02
Of course, my pleasure. So, Wei, you have had an amazing career. You were a part of really interesting technology companies like Splunk, AWS, and you were even the Head-of-Product at a startup before you ended up at StackRox. So, what drew you to take that leap to becoming the founder of a startup, and why Stack Rox in particular?
Wei Lien Dang 01:32
I've been really passionate about infrastructure for a really long time and had worked in and around some great companies that were really innovating at that layer of the stack, like you mentioned, Sandhya. I grew up around this emergence of cloud-first and cloud-native infrastructure nearly a decade ago and got excited about the problems that could solve for businesses. I mean, really around powering a new generation of modern applications and helping companies and teams think about how to scale their products in the way they really hadn't needed to before. And so you're having to work in and around this problem space. I've done stuff in infrastructure, I've done stuff in security. And in some ways, the space in which StackRox went after around container security and Kootenay security was at this perfect intersection for me in terms of what I had done previously. And so it kind of teed me up to really understand the problem deeply, and having worked in and around the space for quite some time, I felt like I was uniquely qualified to go tackle it. For me, the origination of StackRox, and the opportunity to help shape this new category, was what really was what I found really compelling in terms of wanting to be an early stage founder and builder and start something from the ground up.
Sandhya 03:02
And what was that experience? Even if your role is similar, so before StackRox, you were at CoreOS, where you were also the head of product. What is the difference when you actually are the founder of the company versus an executive? Is there a tangible difference in how you feel day to day? What conviction do you need? How stressed out are you? Paint a picture for all the aspiring founders here.
Wei Lien Dang 03:31
There are definitely hugely meaningful differences in being an executive or early leader or senior member of the team versus being a founder. As a founder, you think a lot about the responsibility that you owe to the people who have joined you on the journey. From a company standpoint, you end up wearing a ton of different hats. Really, you end up doing whatever it takes at any given point in time to help the company succeed or move forward. Even though I was sort of wearing the product hat in the company, I mean, I was involved in, , selling, I was involved in recruiting, , and I mean, those are all key functions that I think you take on as a founder. At the same time, you have a moral authority in terms of what you bring to the company in terms of vision and leadership. That is not exactly the same as if you're an early executive or if I had just been wearing the same sort of product leader hat I had worn previously. But certainly, I thought a lot about my obligations to the team and the investors to be partnered with and all the relevant folks in terms of what was necessary at any given point in time beyond my product role to make your company succeed.
Sandhya 05:03
Make sense. So one of the themes we explore in this podcast in every episode is this idea of Product-Market Fit. Because there's a lot of other things that you can kind of simplify and learn on your own, like how to hire, how to raise money, maybe even how to do good customer discovery. But almost every founder still struggles to answer the question 'do we truly have Product-Market Fit'? What does it mean? What does it feel like to have Product-Market Fit? Does it have some revenue, have some active users, what is it? So would love to just dive into that story for StackRox? What was the Product-Market Fit journey? Where did you start? And what was eventually the aha moment where you as a founding team said, 'Yes, I think we have found Product-Market Fit'?
Wei Lien Dang 06:00
Yeah, for StackRox, the journey to Product-Market Fit was more of a winding one, to be honest. And in some ways, it was somewhat circuitous. To give you a sense for how we got to Product-Market Fit, there were a couple of key milestones along that path. When we were first starting out, for one, the market was, was still very early. People were not necessarily woken up to the category of container security or needing security for cloud-native applications in an urgent, critical way. In the early days, when we were building, we initially targeted security teams as the core push persona that we were looking to serve. That was also the type of person that a lot of our network was built around. So if you looked at the circles in which myself and my Co-Founders had operated, and previously, a lot of it was around infrastructure, security folks, Chief Information, security officers, people like that. So we talked to a lot of them. We started shaping our product around runtime security for containers, which means you are looking at activity of what's happening. When containerized applications are running, they're deployed in the environment, you're looking to detect potential threats or malicious activity or things like that. We started to build up the product, we launched it, we engaged with early design partners. We got some traction, but it wasn't the type of traction where you really felt pulled to these users. In some ways our engagement was built around convincing them why they needed this type of product, or they needed to think about this space of problems that they weren't necessarily themselves initiating as an urgent or critical pain point. That was an early indicator to us that we had not hit the mark in terms of Product-Market Fit. As we dug in more, you'd find that even for customers that had been doing proof of concepts or had deployed us, they were not super engaged or using our product in a very meaningful way.
Sandhya 08:39
That is such an important point you're making because often, I'll talk to founders who have that early traction where they have someone who signed up for a design partner program, they have somebody who's using the software in production. At that point, what does great engagement feel like versus where you're like, 'well, we have traction, but it's not Product-Market Fit. This particular customer does not want our product badly.' What would be your advice to founders to differentiate between those two where both customers are technically using your product? They're signed up to be early design partners? How do you tell the difference between the two situations?
Wei Lien Dang 09:26
That's a good question. There are a couple of different ways. Someone who is really engaged and hands-on with your product and deriving value will actually push you and take you in directions that you hadn't necessarily thought about. I think early champions will often give you feedback. They'll tell you what's going well, what's missing, because they see value in your product, and they're looking to get more out of it. Those are some indications that you really hit on a pain point that your product helps solve. As opposed to when it feels like you have to pull some of the feedback out of them, or you chat with them and you get a sense for what they thought of a particular feature. If they can't speak to the details, if they can't tell you what's good and what's bad, then it's really clear that they haven't really engaged with your product in a way that you would want them to. Even though we had some early financial services companies, we had some media and entertainment companies that were using us. These were generally good early Lighthouse logos, when I took a step back and looked at it in the bigger picture, because sometimes day-to-day, you're just running. You're heads down, and you don't step back a bit. I really noticed that a lot of these early design partners that we engage with were through warm intros or people in our network. Oftentimes, you talk to these types of organizations or the decision-makers, and they'd nod their head, but would they be able to really articulate the problems or pain points or needs that they had? That's where there was definitely a gap in terms of them clearly expressing an important pain point. Then you had this issue around meaningful engagement and feedback and things like that. That really caused me and the team to reconsider our approach. Rather than continue pushing down this path where we could likely have gotten to several million in ARR long term, we didn't necessarily feel we were aligned with this market tailwind. Cloud-native applications and architectures were really taking off. Platforms like Kubernetes, which allow people to build in these newer, more modern ways for scalability and in a more declarative way, we're seeing huge adoption. At the same time, it was very obvious to see externally that there was this huge market uptake in the sort of types of apps that people were building, and yet we did not see a measurable hockey stick in terms of security. So, that was also an indicator that something was not necessarily aligned with the type of product that the market wanted or needed. When we started engaging with more folks, we actually started talking to people who were the adopters of Kubernetes and those types of platforms. What was interesting there is that was actually a different persona. These were DevOps people, these were engineering teams or platform teams who were laying the foundation for how companies were thinking about building apps in a new way. And when we talk to them, they actually had a lot to say about security, it was just very different from where we had focused because we had been engaged with the security persona. So when we talk to DevOps teams and platform teams, they actually highlighted a completely different use case as the starting point for security. Most of them wanted to simply start by scanning their container images for vulnerabilities, and that made a lot of sense that those people would bring that up. Because , that's in the stage where you're out and you're building your application that's a developer or DevOps user. What struck us was that they were already starting to think about security. So we quickly started to really plan out what would be a potential shift in moving to addressing a use case like that, and that type of Persona looked very different. It was effectively almost the polar opposite of where we had started. I think those discussions definitely had good and bad to it. I think that people were somewhat relieved in terms of addressing the unanswered question hanging in the air sometimes. It's like, we're not feeling this huge traction or pull at the same time. There's a lot of inertia. I mean we had maybe 15 to 20 people on the team. By then they had invested a lot of time and energy in terms of building out the existing product. I do think that it's actually easy for a company to not make the hard decision to move away from all that it's invested in early on. But from my perspective, it was somewhat of a sunk cost, which you have to think about, going forward, what made the most sense for the business from a product standpoint. For me, that quickly shifted my focus and energy and priorities to enable us to get a new product offering out there that was focused on this different persona, a different part of the lifecycle. What that looked like is we pulled together a tiger team of about three to four engineers out of maybe the dozen or so that we had at that time. We put them on this new project we wanted to iterate really quickly and get something out into the market. We had existing customers for the product, and we spoke to them, we engaged with them, we explained very openly and transparently why we were shifting to this product strategy to really focus on a different part of the cloud-native application lifecycle. We were able to deliver that new product in the span of about six months. It was very rough around the edges. It also caused different pain for different people for some period of time. For instance, we needed that new product to have standalone value. So it had its own UI. And so suddenly we had two separate products that had to be deployed separately with two different UIs. Customers were definitely not thrilled about that. We had to train the field — a small field — but we had to train the salesforce on how to sell these different products and the different use cases that they could align around. And so there's definitely a period where it was very difficult managing that product transition. In retrospect, it was absolutely the right move for the company. As soon as we put out that new product, it wasn't that it was perfectly on target for what people necessarily were looking for. But at the same time, it was still a relatively early market. It was wide open. And it was good enough, where we started to get a lot of users trying it out, adopting it, and then giving us feedback on how we could build it out over time.
Sandhya 17:53
Got it. So you are getting much more engagement from the early adopters of the DevOps-focused product. So even though it wasn't that you had an order of magnitude more adoption, yet, the quality of that early adoption objectively felt much better.
Wei Lien Dang 18:14
You can even see it in the reaction of people's eyes and almost emotions when you talk to them or demo the product. In the case of the new product, people would get really excited and they'd be like, ‘Okay, I can totally see how this fits in and solves a problem for us’, or ‘Can I try this right away, can I get my hands on it today?’. Versus the earlier conversations around our initial product, people would nod their heads. They weren't disagreeing with you. It's not that there was anything conceptually wrong with what we were proposing or what we had built. But, it just didn't address a pain point that they identified with.
Sandhya 19:03
Right. To me is probably the one big takeaway. If you want to put something on a t-shirt, the question ‘When can I get my hands on this?’. That's when you know that you have something that someone is really excited about, as opposed to if you ask them, ‘Oh, would you be willing to be a design partner?’ And they're like, ‘Okay, sure. Yeah, I'll give you some feedback’, which is completely different from ‘oh, gee, is this already live? Can I use it? When can I get my hands on it?’. That qualitative difference is so huge. Could you help us understand what the timeline was? How many? How much? How many years into starting the company did you guys decide you need to pivot? You said in about six months you had the second product ready to go. So what were some of the metrics after you launch that second product?
Wei Lien Dang 20:03
StackRox was formally founded at the end of 2014 and really kind of got off the ground in 2015. I joined a bit later in 2016, when the team was still very small, just a few engineers. We launched the product in 2017. I would say, after about six months, that was when we really had a good gauge on interest and these issues around engagement. So it was around late 2017 that we decided to shift our product strategy and start working on this new product, which we released in around mid-2018. Then, I would say because of that difference in terms of where the market was in the adoption interest, we hit a million in ARR within a year after releasing the newer product.So it was definitely very obvious, even in the metrics in terms of the pipeline, and the types of customers we were engaged with and things that, going from 2017, where we launched this initial product, and you didn't really see the uptake that we were hoping for. Versus, in 2018, after releasing the new product, you're seeing a lot of interest. In addition to excitement and engagement, it was just clear that with the newer product, many, many more people were looking to engage with us, looking to try out the product. Whether it was inbound requests, whether it was like demo requests, whether it was at conferences, and trade shows. So, I think part of it was just the size of the market that was interested in one product versus the other because in the initial case with our first product, even though , here and there, there may be people who were interested or excited, it was much, much fewer.
Sandhya 22:19
Got it. So it took about three years to find product-market fit, launch a product that would give you product-market fit. But then, within a year, you got to the million ARR benchmark, which I think is what top quartile startups all shoot for. Getting to a million in ARR within 12 months of GA launch just considered the minimum indicator that you are really on to something. I think what is so important to remember is that the path leading to that moment is many years of ups and downs and hard work and having to persist through that. What was the mood in the founding team, did things get easier, once you had that million in ARR?
Wei Lien Dang 23:14
Things definitely felt more upbeat and optimistic. The first few years were certainly difficult in terms of everyone was working really hard, everyone had put a lot of time and energy into wanting to make the company successful, and just not feeling like we could make a lot of forward progress. It was also a difficult period early on, because we had a leadership transition, and our initial CEO moved on. It just wasn't the right fit. We needed a different skill set to drive the company forward. That also had an impact on the team. There was definitely this period in early 2018 when all these things came to a head. We were still transitioning the product and there was some people on the team, including engineers, who were feeling really down about that. Also, there was a lot of uncertainty overhanging the company, which is, how's this new product strategy going to work out and things like that. At the same time, having one of the Co-Founders depart definitely had an impact on the team. We were small enough, where everyone still knows everyone, and you'll work closely together. So that definitely had implications, too. Managing that transition in the first six months of 2018, was probably the most precarious for the company in that period where the team composition had changed as well as we're undergoing this drastic shift in product strategy.
Sandhya 25:00
How did you define product strategy? It's fairly challenging. These really early days when you're still thinking about what the MVP is, you're in the middle of a pivot. How did you think about defining product strategy, driving clarity for the org? What matters and what to build?
Wei Lien Dang 25:23
I think it is super important to reassure the team that there is a plan, that there is something concrete that they can latch on to in terms of where the company is going. And I think that most of the team was relatively senior, and I think that they were very mature about the openness and communication, which was like, ‘hey, the first product really didn't work’. I think people understood that and appreciated the humility, but then the question always comes to what's next? What's the plan? And so there, framing the assumptions was really important. I think, in retrospect, what we had missed with the first product was we didn't recognize that the shift in application architecture to the cloud native and microservices and containers and Kubernetes, and things like that was prompting organizations and companies to think about who handles security and how that's handled differently from before. So that was a core assumption in the product strategy around shifting from security people to DevOps as the core persona. In terms of communication to the team, if that's the core assumption, what we spent a lot of time doing was not just framing that in a vacuum. We had had a lot of conversations once we decided things were not working as we had hoped. Sharing that data, sharing the feedback with the team as a whole was very helpful. Tying it to product, deliverables and milestones was also really important. In the sense that we said, ‘Okay, well, we need to focus on this type of persona, this part of the lifecycle, something around this use case. Here's how we're going to scope MVP, here's a very well defined set of user stories, here's a set of requirements’. I think anyone who's wearing the PN hat would think about it from an execution standpoint– here's something that we would like to target, maybe a bit ambitiously, but that we want to deliver in three to six months in terms of going from prototyping to beta to actual launch. That gave the team a frame of reference to rally around. They could certainly give input like, ‘Okay, I think this is doable. Here's what makes sense. Here's the technical implementation and back-end, front-end that will be necessary. And here's what's too much.’ Putting something more concrete and tangible out there where people see it's not just, ‘Okay, we're going to shift product strategy’. It's like ‘we're shifting product strategy, and here's what the initial new product offering would look like, here's who it's for,’ things like that. That was really critical to getting buy-in support from the entire team.
Sandhya 28:58
Makes sense. And I know StackRox also was open source. And that was a critical part of your product and go-to-market strategy. How did you, internally, as a team, think about open source? Were you open source from day zero? Did you do it later? Could you share more about how StackRox did it? Then given so many founders today are starting companies alongside open source projects, what would be your more generalized advice for them?
Wei Lien Dang 29:28
We were not open source from the beginning, especially around the initial product, which was more focused on security users. When it came to the newer product, we were not open source from the beginning, either, but we quickly evaluated whether it made sense and determined it did. The reason for that was we recognized that we were targeting DevOps users for whom open source is certainly a valuable way of getting to either kick the tires or start using products early on. That really resonated with the model that they were looking for. I would also say a big factor in our decision to go open source was that a lot of our immediate ecosystem was built around that model. So if you looked at Kubernetes and the Cloud Native Computing Foundation, there has been this vibrant, open source based community that was really taking off. In some respects, open source was almost table stakes by the time we started to think about the newer product. Also, the community really values open source to the extent that people can collaborate and build on it and continue to take things forward as a way of thinking about implementing newer standards. We really wanted to be the new standard for certain parts of cloud-native security, and being viewed as a good citizen was also really important in terms of giving back to that community that we wanted to work with.
Sandhya 31:26
Makes sense. So if I was an engineer today with a great open source project which has some traction and considering ‘Okay, should I start a company’? What would be some of the questions that I should think about as a potential founder? And should I reach out to you for a personal one-on-one session? But other than that what would I think about?
Wei Lien Dang 31:51
I love chatting about this type of thing early on because it can be such a pivotal decision in terms of how you're looking to build a company. I would say there's definitely some key considerations in terms of thinking about why open source. I would certainly say think about who are your users and what do they expect and how do they like to onboard to new products? I would say for many developer-focused products, open source is a tried and true way for what people are looking to do. I think the other is, also, if you're looking to put out a product that is meant to be extensible, and you want to foster a community around it, then open source is a great way to do that because you'll get contributors. You get people who are collectively working with you to solve the problem that you're looking to address in a bigger way, and they'll take you in directions that maybe you hadn't necessarily thought of, which is super valuable. The third is think about what part of the stack you're building for. There's definitely certain parts of the stack where there's standardization that's expected to happen, then open source is critical. Whether it comes to governance or Community Focus, like things being open are going to be almost essential to the audience that is looking to adopt technologies in that particular part of the stack. Whether you look at infrastructure or data or other spaces, open source has become critical where people are looking to establish a standard in terms of how something works within the stack. So that's what I would say,. You saw the same thing with Kubernetes. It originated at Google, but effectively, started to get influenced by the entire community. That really had a huge impact on its trajectory.
Sandhya 34:10
Makes sense. This has been so awesome, having you on the show Wei. I know you have a packed day full of founder pitches to get to, so thank you so much for carving out time today to chat about StackRox. I always have such a lovely time. We could go on for hours, but we'll wrap up for today. Thank you again so much for being an early guest on the Unusual Startup Field Guide.
Wei Lien Dang 34:37
Thanks so much, Sandhya. It was great chatting about the story of StackRox. We'd love to chat with any founders who are listening about all things infrastructure software-related, and we are going to be putting out an open source playbook in the next couple of months, so please be on the lookout for that. If I think there's a lot to be built and talked about in that space so we'd love to engage with early-stage builders.
.png)
