Startup Field Guide Episode 4

In this episode of the Startup Field Guide podcast, Sandhya Hegde chats with Wei Lien Dang, a general partner at Unusual Ventures and a co-founder of StackRox, a leader in container security. StackRox became one of the first startups in the container security world to offer a Kubernetes-native solution and in 2021, it was acquired by Red Hat.

‍

Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and YouTube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit.

‍

If you are interested in learning more about some of the themes and ideas in this episode, please check out the Unusual Ventures Field Guides on starting open-source companies, developing open-source customers, and building open-source GTM.

‍

TL;DR

• Wei “grew up around cloud-first and cloud-native infrastructure.” He was excited by the problem space that StackRox was innovating in. When Stackrox began, the container security market was still early.
• As a founder, you think more about the responsibility that you owe to your employees versus as an executive. The vision and leadership you bring  as a founder is really important.  
• StackRox’s initial core persona targeted security professionals. However when they signed up design partners, they had to be convinced about why they needed Stackrox. This was an early indicator that they hadn’t found PMF.
• Early advocates and champions will see the value in your product and tell you what is missing, because they want what you are building. 
• When StackRox changed its persona to focus on DevOps users, they found much more traction, and people were excited to start using their product. Their feedback gave the StackRox team the conviction to pivot to a new product strategy.
• It was hard to pivot internally with a team of 15+, given that they had an existing product and customer base. Being transparent and laying out a plan helped unify the team and get them on board with the changes.
• Stackrox did not begin as open source; the change came when they recognized that DevOps users really valued it and that it builds a community around your product.

‍

Episode transcript

‍

Sandhya Hegde

Our guest today is the wicked smart Wei Lien Dang. Say hello, Wei!

‍

Wei Lien Dang

Hey everyone!

‍

Sandhya Hegde

So I'm lucky to call Wei my partner at Unusual Ventures, where he leads our seed investments and security, machine learning, and Web3 infrastructure startups. 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. And 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.

So Wei, you have had an amazing career. You were a part of really interesting technology companies like Splunk and AWS? 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 StackRox in particular?

‍

Wei Lien Dang

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, as you mentioned Sandhya. I kind of grew up around this emergence of cloud-first and cloud-native infrastructure nearly a decade ago, and really got excited about the problems it could solve for businesses. I mean, really around powering a new generation of modern applications and helping companies and teams thinking about how to scale their products in a way they really hadn't needed to before.

‍

And so having worked in and around this problem space, I had done stuff in infrastructure, and I had done stuff in security. In some ways, the space in which StackRox went after—around container security and Kubernetes 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. In having worked in and around the space for quite some time, I felt as though I was uniquely qualified to go tackle it. And so for me, the origination of StackRox and the opportunity to help shape this new category was what I found really compelling in terms of wanting to be an early-stage founder and builder and to start something from the ground up.

‍

Sandhya Hegde

And what was that experience like, even if your role is similar? 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 with what conviction you need and how stressed out you are? Paint us a picture for all the aspiring founders here.

‍

Wei Lien Dang

Yeah. I think there are definitely, hugely meaningful differences in being an executive or an early leader or senior member of the team versus being a founder. For one, 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. I mean, really, you end up doing whatever it takes at any given point in time to help the company succeed or move forward.

‍

And so 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. Those are all key functions that I think you take on as a founder. And at the same time, you have, I think, 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 we partnered with and other relevant folks in terms of what was necessary at any given point in time — beyond my product role — to make the company succeed.

‍

Sandhya Hegde

Makes 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 simplify and learn on your own, such as 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? I have some revenue, I have some active users… what is it? So I 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

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, I think there were a couple of key milestones along that path.

‍

When we were first starting out, for one, the market was still very early. People had not necessarily woken up to the category of container security or needing security for cloud-native applications in any sort of urgent, critical way. So in the early days when we were building, we initially targeted security teams as sort of the core 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 in previously, a lot of it was around infrastructure security folks, chief information security officers… people like that.

‍

And so we talked to a lot of them and we started shaping our product around runtime security for containers. This means that you are looking at the 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.

‍

And as 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. And so I think 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 Hegde

That is, I think, such an important point you're making because often I'll talk to founders who have that kind of early traction where they have someone who's signed up for a design partner program. They have somebody who's using the software in production. At that point, how would you think about what great engagement feels like, versus where you're thinking, “well we have traction, but it's not product-market fit. This particular customer does not want our product badly”? So what would be your advice to founders to differentiate between those two — where both customers are technically using your product and they have signed up to be early design partners, how do you tell the difference between the two situations?

‍

Wei Lien Dang

It's a good question. I think there are a couple 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 and what is missing because they see value in your product and they're looking to get more out of it. And I think those are some indications that you really hit on a pain point that your product helped 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 or things like that. I mean, 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.

‍

We had some early financial services companies and we had some media and entertainment companies that were using us. These were generally good, early lighthouse logos. But when I took a step back and looked at it and took stock of the bigger picture — because sometimes day-to-day you're just running and your head's down and you don't kind of step back a bit — I really noticed that, well, one, a lot of these early design partners that we got engaged with were through warm intros. They were 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 to them.

And then you had this issue around meaningful engagement and feedback. 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, let's say. I think long term, we didn't necessarily feel we were aligned with this market tailwind because cloud-native applications and architectures were really taking off. Platforms like Kubernetes, which allowed people to build in these newer, more modern ways for scalability in a more declarative way were seeing huge adoption. And so at the same time, it was very obvious to see how externally, there was this huge market uptake in the types of apps that people were building. And yet we did not see a commensurate hockey stick in terms of security.

‍

To us 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, what we did is we started talking to people who were the adopters of Kubernetes and those types of platforms. And what was interesting there is that it 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 talked 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. And so when we talked to DevOps teams and platform teams, they highlighted a completely different use case as the starting point for security.

‍

And what they pointed out is that most of them wanted to simply start by scanning their container images for vulnerabilities. It made a lot of sense that those people would bring that up because that's in the stage where 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. After that, we started to really plan out what a potential shift in moving to addressing a use case like that would look like and what that type of persona would look like. It was very different! It was effectively almost the polar opposite of where we had started. And with those discussions, there was definitely good and bad to it. I think that people were somewhat relieved in terms of addressing almost the unanswered question hanging in the air sometime — it's like we're not feeling this huge traction or pull.

‍

At the same time, there's a lot of inertia. 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. And 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 is you have to think about going forward. You had to focus on what made the most sense for the business from a product standpoint. And so for me, I quickly shifted my focus and energy and priorities to enabling us to get a new product offering out there that was focused on this different persona in a different part of the lifecycle. And so what that looked like is we pulled together a tighter team of about three to four engineers — out of maybe the dozen or so that we had at that time — and 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 so we spoke to them and we engaged with them. We explained very openly and transparently why we were shifting this product strategy to add on and really focus on a different part of the cloud-native application lifecycle. And so we were able to deliver that new product in the span of about six months. But it was very rough around the edges. Also, it caused different pain for different people for some period of time. For instance, we needed that new product to have standalone value and so it had its own UI. And so suddenly, we had two separate products that had to be deployed separately with two different UIs. And customers were definitely not thrilled about that.

‍

We had to train 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. But 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 were necessarily 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 Hegde

Got it. So you were 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 just objectively felt much better?

‍

Wei Lien Dang

Yeah. You could 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 say, "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 now?" Versus in the earlier conversations around our initial product, people would nod their heads. They weren't disagreeing with you… I mean, 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 Hegde

Right. I think that that, to me, is probably the one big kind of takeaway. That if you want to put something on a t-shirt, it’s the question “When can I get my hands on this?” That's when you know you have something that someone is really excited about.

‍

This is opposed to if you ask them, "Oh, would you be willing to be a design partner?" And they're saying, "Okay, sure, yeah, I'll give you some feedback." That’s completely different from, "Oh, is this already live? Can I use it? When can I get my hands on it?" So I think that qualitative difference is so huge.

‍

Could you, just for the sake of having more clarity, could you help us understand what the timeline was? So how many years into starting the company did you guys decide, that actually no, you needed to pivot? And then you said in about six months, you had the second product ready to go. So what were some of the metrics after you launched that second product?

‍

Wei Lien Dang

Yeah, so StackRox was formally founded at the end of 2014 and really kind of got off the ground in 2015. I joined a bit later. I joined in 2016 when the team was still very smal l— just a few engineers. And 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. And 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. And then I would say because of that, just difference in terms of where the market was and the adoption and interest, we hit a million in ARR [annual recurring revenue] within a year after releasing the newer product. And 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 like that.

‍

We went from 2017—  where we launched this initial product and didn't really see the uptake that we were hoping for —  to 2018 after releasing the new product and 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. They were looking to try out the product and things like that, whether it was inbound requests or demo requests at conferences and trade shows and things like that. 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, while there were some people who were interested or excited, it was much, much fewer.

‍

Sandhya Hegde

Got it. So it took about three years to find the product-market fit or, rather, launch the product that would give you product-market fit. But then within a year, you got to the million ARR benchmark. I think that is what top quarter startups all shoot for — getting to a million in ARR within 12 months of GA launch. That is considered, I would say, kind of the minimum indicator that you are really onto something. But 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 you just have to persist through that.

What was the mood in the founding team like? Did things get easier once you had that million in ARR?

‍

Wei Lien Dang

Things definitely felt more upbeat and optimistic. The first few years were certainly difficult in terms of everyone 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 — who just wasn't the right fit — and we needed a different skillset to drive the company forward. And that also had an impact on the team.

‍

So I think there was definitely this period in early 2018 when all these things came to a head. We were still transitioning the product and there were some people on the team, including engineers, who I think were feeling really down about that. And also there was a lot of uncertainty overhanging the company… which was “how is this new product strategy going to work out?” and things like that.

‍

At the same time, I think having one of the co-founders depart definitely has an impact on the team. I mean, we were small enough where everyone still knows everyone and worked closely together, and so that definitely had implications too. And so I think managing that transition in the first six months of 2018 were probably the most precarious for the company. In that period where the team composition had changed as well as we were undergoing this really drastic shift in product strategy.

‍

Sandhya Hegde

And how did you define product strategy? I think it's fairly challenging in these really early days when you're still thinking about “what's the MVP?” and you're in the middle of a pivot. How did you think about defining product strategy and driving clarity for the organization on what matters and what to build?

‍

Wei Lien Dang

I think that especially when it comes to a transition like that, Sandhya, I think it is super important to reassure the team that there is a plan — that there is something concrete that they can latch onto in terms of where the company is going. And most of the team was relatively senior. I think that they were very mature about the openness in communication, which was like, "Hey, the first product really didn't work." And I think people understood that and appreciated the humility.

‍

But then the questions alway come: "Well then what? What's next? What's the plan?" And so framing the assumptions was really important. I think in retrospect, what we had missed with the first product is we didn't recognize that this 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 how it was before.

‍

And so I think 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 a 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. And so sharing that data and feedback with the team as a whole I think was very helpful. And then I think tying it to product deliverables and milestones is also really important, in the sense that we said, "Okay, well we need to focus on this type of persona, this part of the life cycle… something around this use case. Here's how we're going to scope MVP?"

‍

And how I thought about it was this: here's a well-defined set of user stories and here's a set of requirements. I think anyone who's wearing the PM [product manager] hat would think about it from an execution standpoint. Here's something that we would like to target — maybe a bit ambitiously — that we want to deliver in three to six months in terms of going from prototyping, to beta, to actual launch. And that gave the team a frame of reference to rally around. They could suddenly give input, like, "Okay, I think this is doable! Here's what makes sense. Here's the technical implementation and backend and front end that'll be necessary. And here's what's too much." So I think 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 going to shift product strategy — 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, I think, buy-in and support from the entire team.

‍

Sandhya Hegde

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 just A) how StackRox did it, and then B) given so many founders today are starting companies alongside open source projects, what would be your more generalized advice for them?

‍

Wei Lien Dang

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. And 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. I think 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.

‍

And so I think in some respects, open source was almost table stakes by the time we started to think about the newer product. And then I'd also say that 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. And so for us, 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 Hegde

Makes sense. And so if I was an engineer today with a great open source project, which has some traction and considering if I should start a company, what would be some of the questions that I should think about as a potential founder? And, obviously, I should reach out to you for a personal one-on-one session, but other than that, what would I think about?

‍

Wei Lien Dang

I love chatting about this type of thing early on because it can be such a pivotal decision in the early days 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 you’d go the open source route. I would certainly say you should think about who your users are, what they expect and how they like to onboard to new products. I would say that 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 and 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 that I think about what part of the stack you're building for. There's definitely certain parts of the stack where if there's standardization that's expected to happen, then open source is critical because whether it comes to governance or community focus, 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. And so, I think, whether you look at infrastructure or in data or security in many other spaces, open source has become critical for people who are looking to establish a standard in terms of how something works within the stack. So that's what I was saying. And you saw the same thing with Kubernetes. It was one company that originated at Google, but effectively, started to get influenced by the entire community. And that really had a huge impact on its trajectory.

‍

Sandhya Hegde

Makes sense. Well, 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 and 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

Thanks so much, Sandhya, it was great chatting about the story of StackRox and would love to chat with any founders who are listening about all things infrastructure software related! We are going to be putting out an open-source playbook in the next couple months, so please be on the lookout for that. I think there's a lot to be built and talked about in that space, so I would love to engage with early stage builders.

‍