Chapters
Shownotes Transcript
Hello, LPs. We are here with a very fun episode here at the beginning of 2023 with Vijay Raji, the founder and CEO of Statsig. And before that, formerly a very, very senior executive at Facebook.
So senior. In fact, you're the most senior person in Facebook Seattle, where you were head of entertainment for all of Facebook and concurrently head of the Facebook Seattle office. So we have a lot of fun stuff to talk about here. Welcome to the show. Thanks for having me, Ben and David. Yeah, it's our privilege. The thing that I'm really excited to talk about today is, you know, you worked at Microsoft before Facebook.
And we share that in common. And you were an engineer there and you worked purely on technical problems. Then when you went to Facebook, obviously you had a business role and an overview over a lot of very important products for Facebook strategically at the time. And while you were site lead for Seattle, about how many people worked in the region? Yeah, when I was leaving Facebook as the head of Facebook Seattle, we had about 6,500 people in the region. So this is Seattle and Bellevue all combined together. Yeah.
your role sort of escalated from technical problems to human problems and lots of scale problems. And then you left to start Statsig and decided to go from one of the biggest roles in our industry to one of the smallest. And I think a big crux of what we're going to talk about today is your calculus for that decision, what surprised you, what you've liked about it, and what you wish you knew if you could go back and do it again. Absolutely. It was quite a journey, and I'm excited to talk about all of it.
Well, at the tip of the spear here, I want to talk about something that came up on our prep call that I know you feel very strongly about. You are an in-office person. So maybe tell us a little bit about how Statsig operates. And we'll get into the business and the product and what you guys build later, but what your culture looks like. Yeah, this is very interesting because we started our company Statsig in the middle of the pandemic. This was February 2021. And
And we decided like, hey, this is early days. You know, we have like seven people. So let's get an office. Let's get together, grab some whiteboards and get started.
And what started that way kind of led to me believing that this is going to be important to be in person, to make decisions very, very quickly and to move very fast. And then we started seeing people also opt into an in-office culture. So we started hiring people with like-minded set. And so I decided, let's keep going. As long as we can hire people that want to be in office, we'll be in a good shape.
And you started with a pretty serious critical mass. There were like eight of you that all sort of left Facebook to start the company together, right? Yeah, that's right. We all left at the same day and we started the company the very next day.
It's awesome. And you're 55 people today all in person? Well, probably 56 because we hired someone yesterday. There's lots of benefits to being in person. How do you think about the set of trade-offs you're making and why? Choosing to be in person is a big trade-off, and especially in this weather and climate where people are expecting to be remote or at least hybrid. There are lots of folks that I would have to say no to because they want to be remote.
These are like world-class engineers, data scientists, and product managers that I am saying no to. And that's a big negative. I do strongly believe that culture drives a lot of like what you do on a day-to-day basis, including how fast you move.
You know, when I was at Facebook for 10 years, then Facebook is one of the strongest engineering cultural companies. And so when I think about like, what is the definition of culture? It's like a set of unwritten rules that you absorb by observing. It's literally like you have to see other people do things a certain way, talk a certain way, use tools a certain way, build a relationship a certain way. And you absorb that and you think, OK, well, this is the right way to do it.
If you start writing it down, then it becomes a set of rules. It loses its magic. So I feel like when you're in the office, you're able to absorb that much faster than when you're on Zoom calls. And you guys are like truly five days a week, everyone physically present. Do you think that that is more important for a company of your stage that is right around this product market fit precipice than it is for a bigger, more established company?
Yeah, I think so. It's a fun story. When I was in Facebook, Seattle, Seattle was kind of like the epicenter of COVID. And then we have this process called boot camp at Facebook, where, you know, you go for six weeks, you kind of like get a lot of like orientation and cultural assimilation at that point. And so we started doing it all remotely.
That worked. And the reason why it worked was because a lot of processes and tools and documentation and the materials were there and we could onboard people. And when I think about how something like that would happen at Static when you have absolutely nothing, we have not written down anything. Yeah. I mean, Facebook probably has at least a thousand people just in HR alone, right? Yeah, right. This is really interesting as a specific example.
example of the conversation about leaving Facebook to start a startup. Given where you were at Facebook, I think of a few examples, I won't say names, but of similarly senior executives at top five big tech, broadly FANG type companies who then leave and start a startup.
And they run the startup like they ran their division at the big tech company. They're in a big fancy office and they're doing all this stuff. And those startups never work. They never work. So I'm curious, what was your, A, just general thought process about leaving and starting Statsync? But you must have known, given the decisions you've now made, clearly you didn't want to take that approach. You're taking a very different approach at Statsync. Yeah.
Oh yeah, yeah, we're very scrappy, so much so that I annoy our people.
So when I joined Facebook in 2011, Facebook was still considered a startup. There were about 1,500 people and there's a lot of scrappiness in there. Things were not quite as well. So I moved from Microsoft where we at that point, probably like 80 or 90,000 people where you walk into a meeting room, the conference room is all set up. There's a big screen. There's like devices on the table. You press a button, you get connected to your phone.
video conferencing and then real estate and facilities may have even worked with catering to have the drinks ready for them yeah i know so and then you you go walk into a startup you're like uh first day we have to put together desks because we don't have desk all we have is like a large office room i think a lot of that came from like okay well the good old days of like a startup starting to imagine like what was the snapshot of like how i felt
when I walked into an early, early Facebook office. And so I'm just trying to recreate a lot of that from memory. In 2011, did Facebook still have elements of that?
Yeah. Now, there was only, at that time, 600 engineers, and we had two offices in Palo Alto. I remember going to the Palo Alto office, and then I also remember doing boot camp in a boot cave, which is literally like, you know, there's no windows or anything, and so they put all the boot camp folks in the boot cave. It was very small. It was very small, very scrappy, and it was moving very fast. So, yeah, a lot of
going from a large company to that kind. And then like actually then scaling it down all the way down, you know, eight people. Right. Cause even that's a difference than, you know, certainly 1500 or 600 people.
It is. It really is. I wouldn't say like I had it all right. There's a lot of mistakes I make, but there's an element of like what you're describing. You need to like definitely leave behind the comfort of like, oh yeah, everything is already done for you. The really good way to think about this is like a large company where you start a project is something like you spin up a virtual machine on AWS, right?
Whereas a company that you start on your own from scratch is like, okay, you take a blade server, you go connect your Ethernet cable, update your OS, and make sure the security is all fine, firewalls open. You identify the best colo in your area that you can drive to easily to do the maintenance. Exactly, right. And so I think that's the big difference. There's no facilities team. There's no recruiting team. You don't have a bunch of people waiting to join your project. You have to figure all that out.
Including like, you know, the janitorial and including like when the trash goes out, how many trash bags do we got to buy? I'm not kidding. So I'm assuming maybe I'm wrong, but I'm assuming the decision to do this wasn't because you wanted to take out the trash, but because you, I'm assuming, thought, hey, it's going to be worth it for me to go back to taking out the trash to do something. Yeah.
Yeah, definitely. The decision process is a lot about like, you know, you, your family, your life situation, and then what do you want to do next, really? So as I thought about 10 years at Microsoft, I learned a lot about software engineering.
And then I went to Facebook. And that was 2001 to 2011? Yeah, 2001 to 2011. Everything that I learned about software engineering. So I was a compiler engineer. So I was working on language services and Visual Studio. I wanted to do a lot of hardcore coding. And that's what I did at Microsoft. And then I went to Facebook. It's like at that point, it was a big jump going from a large company to a small company with lots of like, you know, ad hoc processes. And I just happened to work.
And were you a manager at Microsoft or literally just an IC engineer? No, literally an IC. And then even at Facebook for like four or five years, I was an IC and then decided to become a manager. So it was an interesting journey. And then I started learning about, you know, businesses and people and people management. There's a lot to unpack there. Yeah.
So that was 10 years at Facebook where I was able to like, you know, go try out various things and expand my comfort boundaries and add value. And just so listeners get a sense, you mentioned compilers at Microsoft. What were some of the products that you led at Facebook? Yeah, it was completely different. So when I started at Facebook, I was working on Messenger. So I was building a new client for Messenger. That was like, you know, web client back in the day. We didn't have a mobile app. HTML5. Yeah.
Yeah, I know. What was fascinating was that we put a link on the site. It was like a tiny link on the site on the Facebook homepage. And all of a sudden I saw like the very next day we had more users than MSN Messenger. MSN Messenger was the biggest client at that time. We had more. I was blown away. How is this even possible? It's just like how powerful a link on the homepage is. You get to learn that. Yeah.
Then I went on to do some ads. So I built the first app install ad product at Facebook. So that was a pretty interesting jump because that was the first time I did mobile and taking desktop traffic to mobile and sending people a install link. I mean, and that was when Facebook discovered its business model. Yeah, I mean, that like saved Facebook. Yeah.
A little bit. The mobile app install ads, that took off. You know, I was so lucky to be at that right time in the right space and just being able to bridge the gap that everybody was feeling the pain. The sales team just...
Ate it up. They just took it and sold it. And that became a billion dollar business in 14 months. I was like blown away. And we had six engineers. We used to joke like, you know, per engineer in terms of like net revenue, this is probably the highest that we've ever seen.
Wow. Were all six of you in Seattle? Yeah, all six of us. We built the team in Seattle. I mean, that's actually that's a good challenge for listeners. If anybody can think of a better example than what was it? $1.4 billion of revenue from six engineers. We'd love to hear it.
This was when we were building on top of like the existing ads platform, the existing newsfeed, which was the distribution model. And so there's a lot of like, you know, we're building on top of abstractions. And so those were all done before us in order for us to come in and build that product.
And after that, I started expanding that particular product into an ad network that was audience network. And so we built and shipped audience network. And that also, it kind of like became a competitor for DoubleClick from Facebook.
We want to thank our longtime friend of the show, Vanta, the leading trust management platform. Vanta, of course, automates your security reviews and compliance efforts. So frameworks like SOC 2, ISO 27001, GDPR, and HIPAA compliance and monitoring, Vanta takes care of these otherwise incredibly time and resource draining efforts for your organization and makes them fast and simple.
Yep, Vanta is the perfect example of the quote that we talk about all the time here on Acquired. Jeff Bezos, his idea that a company should only focus on what actually makes your beer taste better, i.e. spend your time and resources only on what's actually going to move the needle for your product and your customers and outsource everything else that doesn't. Every company needs compliance and trust with their vendors and customers.
It plays a major role in enabling revenue because customers and partners demand it, but yet it adds zero flavor to your actual product. Vanta takes care of all of it for you. No more spreadsheets, no fragmented tools, no manual reviews to cobble together your security and compliance requirements. It is one single software pane of glass that connects to all of your services via APIs and eliminates conflux.
countless hours of work for your organization. There are now AI capabilities to make this even more powerful, and they even integrate with over 300 external tools. Plus, they let customers build private integrations with their internal systems. And perhaps most importantly, your security reviews are now real-time instead of static, so you can monitor and share with your customers and partners to give them added confidence. So whether you're a startup or a large enterprise, and your company is ready to automate compliance and streamline security reviews, let's
like Vanta's 7,000 customers around the globe and go back to making your beer taste better, head on over to vanta.com slash acquired and just tell them that Ben and David sent you. And thanks to friend of the show, Christina, Vanta's CEO, all acquired listeners get $1,000 of free credit. Vanta.com slash acquired.
I didn't realize that you and your team had built the app install product. How did that start? That was such a non-obvious thing, right? Like the app store should have done this and like completely whiffed in not doing it. And then Facebook took this ginormous market. Like how did that all come about?
It's an interesting digression. So the thing that I was trying to do was to take desktop traffic and then send them to mobile. So we were working on figuring out how to get people to install our Facebook app, which
And the way we were doing that is to send a link to the app store. As we were doing that, we figured out that we could potentially send a link to Facebook app itself. So imagine you're on the browser and you click a link and imagine you get a notification on your mobile app. So that was the thing that I was trying to solve. So we called it Send to Mobile. So literally like a push notification that you can trigger from your desktop browser.
Once you got that, the idea of like, oh, what if we could do an ad not just for Facebook app, but for other people to install? Because then on the mobile app, you could redirect them to the app store.
And then once you connect the dots, you're like, okay, I guess we have an ads product here. And then the next step was like, okay, well, instead of even using the desktop app, let's move the ad to the mobile app itself and then redirect people to the app store because we do have a lot of, you know, user information, users' interest and, you know,
They show interest in a specific app or a game, then we can use that to show the right targeted ads. That was the sequence how we actually got to the app install. That's so cool that it was like a organic kind of product driven, whereas from the outside, especially now in retrospect, Miss Lasky and Blake Robbins are doing this great history of the gaming industry podcast called GameCraft. Their most recent episode talked about all this.
you look at it strategically and you're like, oh, there's this huge strategic reason, this business opportunity of all these mobile game developers need to get app installs. But this just, it was a product driven thing. Yeah, the product drove it, but there was a demand. And the use case, you were not trying to solve this problem. You invented a technology that,
that was trying to solve a different problem and then repurpose the technology to build an ad platform. Yeah, this is why I say we were super lucky. I was super lucky to be at the right time at the right place because there was an existing demand for not just app install ads, but mobile ads. So at that time at Facebook, we were 2012, we were figuring out how to get mobile to monetize. Because if you get more and more people on mobile and you're not showing ads, you're actually losing revenue. So the biggest thing that
Everybody was trying to figure out, it's like, how do you monetize mobile? And here comes a technology that is like, oh, look, we can actually drive installs. And the equation is like, as long as these installs cost less than the lifetime value of the user on the app,
even like one cent less people will use this forever and infinitely and it turns out the LTVs of some of these users can be a lot of money a lot right and the game developers were the first ones to adopt this and so it was great like I got to learn about all the gaming like the sophisticated mobile gaming industry where everything is driven by data and I was so fascinated by that
Yeah, that was a combination of a set of things. Like the demand was there. The idea was there to monetize mobile. And we were figuring out. And then I was able to connect a bunch of these stuff together. And the technology and the product was there. Yeah, right.
That just blew up. I would say that was one of the seminal moments of my career where I was able to see a lot of the business side of things, the way you take a product and that turns into a real revenue stream for the company that hits the bottom line, which was great. And that kind of propelled me into, okay, now I was able to go and get projects and I want to go build an ad network and let's go build it. Yeah.
A lot of the reputation comes from a few successes and you build on top of that and you kind of like, you know, go and establish if you have new ideas and go explore those. And so how did that lead to you running a lot of the media products at Facebook? Crazy. There's absolutely no connection. So yeah, I was doing ad network and then about like three or four years in, I was like, okay, well, I want to do something different than ads. And that was literally it. I was like a motivation. I want to go do something different than ads.
So Deb Liu, who was my product manager at that time, she was the PM and I was the engineering lead. We were talking about, she was always wanting to do a marketplace. And so we were like, okay, well, let's go build a marketplace for people where people can buy and sell on Facebook. And so we did. I was literally on Facebook marketplace this morning, right before we recorded. I've been looking for a new car. Yeah.
I was looking for a rug, but you know. It's so awesome because what we saw was there was this organic intent. The people were buying and selling on Facebook without us even like building a product around it. So if you think about like groups like Buy Nothing and Swaps and there's so many of these things that were cropping up in every town.
We noticed that and kind of like, there's an opportunity here for us to actually open this up and actually build a marketplace. So we literally built Marketplace. And that was also a Seattle team. The team that built the Marketplace as you see it was an entirely Seattle team that I gathered together in Seattle. I mean, that's got to be a huge portion of Facebook's traffic now, right? Oh, yeah.
One of the things that really helped Marketplace was we got a tab. So getting a tab on Facebook is like really, really hard because, you know, there's so many products competing for a tab. And Marketplace got its... Marketplace and video were the two that were the first tabs. And so when the tab arrived, Marketplace just took off. The number of people buying and selling was just...
Are the tabs static or do I see different tabs depending on like what experimentation group I'm in? It's dynamic. So it depends on what you, no, it's not about experimentation group. It's about what you use, what you use frequently. Ah.
Interesting. Yeah, so it's personalized. Marketplace, for sure. Yeah, that was fascinating, right? So the marketplace was just growing and we were building a large org and that was the engineering lead for the large org. So I think at some point I probably had a couple hundred people in my org.
And at that time, there was a push to consolidate a set of products from platform at that point. So the gaming was actually part of platform gaming at that point. It was all about, if you remember, Canvas games, the Flash games, Mafia Wars and Farmville and things like that.
Flash was dying and there was really nowhere to go other than having everyone update their games to HTML5 and so on. Gaming was trying to pivot and figure out what to do next. I saw that as an opportunity. I was like, okay, I want to go solve that problem first.
And so I left Marketplace and I picked up gaming. At that point, I also went from an engineering lead to a product and engineering lead. So taking care of the P&L and the business as well. And so that was also interesting for me to learn a lot on the business side of things.
But gaming was also something that I thought needed help, needed some kind of a push and somebody needed to just keep it going because I thought it was a very important segment that we should not forget. So I went and invested in gaming. So at that point we invested in videos. So gaming videos, Twitch was big, people were watching other people play games. And then we were trying to revive some of the canvas gaming on HTML5 on mobile. So we built this thing called Instant Games.
So that was another year and a half as I was building it. My manager was getting a promotion and she wanted me to pick up the rest of the stuff that she was holding on to. This is Fiji Simo. She was the head of entertainment and monetization at that point. And Fiji went on to become the Instacart CEO? Yeah, Fiji went on to run all of Facebook advertising.
app. And then after that, the blue app. Yeah. And then after that, she's now the CEO of Instacart and just killing it there. When she was going to go become the head of Facebook app, she asked me if I would take over all of entertainment. So that meant video, live, and then any investment that we're going to go make it music and movies and so on. So that's how I picked up all of entertainment. And then I invested in like a lot of things around premium music
videos, a bunch of sports. And also some of these, you know, if you are watching Stephen Colbert clips and stuff like that. So those are all like my investments in entertainment. So
So how did you start to see the opportunity for what would eventually become Statsig? And maybe give us a little bit of background on the incredible amount of internal tooling available to Facebook engineers. This is a really good question. If I were to think about my transition from Microsoft to Facebook...
I told you that I learned all of the software engineering at Microsoft, right? So, you know, what I learned was the waterfall model where you have a product manager that goes and does some research and then, you know, writes a design doc and like what the product should look like. Then the engineers or the architects will come in and like write up the architecture design doc, right?
And then there will be some milestones of coding and then people will code. And then there'll be a stabilization milestone where they'll toss it over to the QA team. The QA team will test it and file bugs. And then you fix the bugs. And this iteration happens three or four times. And then you send it to literally the manufacturing where they print the disks and ship them to retail. Yeah. And then it sits on Best Buy shelves or goes to the OEMs and the CDs go out.
The whole cycle takes like two, three years. And then when you're done, you increment the version. It's like you will go from v0 to v1 to v2 to v3. And the cycle happens and it works. And it's a miracle of modern humanity that a 5,000 person organization can hit a ship date defined three years earlier all at the same time. Yeah, no, it is a major feat.
If you actually think about it, all of that process started from hardware. Hardware is still operating the same way. And so a lot of the processes that we just borrowed from hardware engineering, going from there to Facebook, where on day one, I was given six tasks in production. And then I had the entire Facebook running on my laptop. I had to go figure out those bugs and
and write some code, send out a diff. Someone accepted my diff the next day. And I said, okay, commit it. So I don't remember the days, but a couple of days later, my code hit 600 million people.
And I was like, something's wrong. Something's wrong. This can't be true. This should not be true. If this was the case, nothing should ever be working. The site is going to come down any moment now. There was a lot of disbelief that this could even work. And I thought this was completely crazy. At any moment, something's going to break because it goes against everything that I've learned.
But that never happened. Things never broke. Things continue to work. And despite the company's motto in those days. Yeah. The idea is that if you're moving really, really fast and even if things break, you can fix those things fast. And that is better than like, you know, moving slowly or deliberately. And it worked. It worked for the time when we were that small. We're growing really fast now.
It's so much so that I thought shipping every week was crazy. About a couple of years later, they actually changed that to shipping every day. And another six months went by and then, oh, we're going to ship two times a day because, you know, there's a London office and they want to ship as well. So code goes out two times a day. And then, you know, a year later, they changed that to code goes out continuously. Any code you write and you ship instantly hits three billion people.
And that's nuts. And so then... Yeah. I could see how that could be a problem. Yeah. Or could create a problem, at least. Yeah, it would. It definitely would. This is my fascination. I was like, okay, well, when you come in from a different perspective and you start to understand how this works and you start to appreciate...
all the tooling behind this to keep everything working. When you distill it down, it boils down to like a set of tools that someone had the foresight to invest in in the infrastructure long before I even arrived.
The fascinating thing is like, you know, most of the folks that go straight from college or, you know, another company like Facebook to Facebook take it for granted. They don't understand. They're just like, this is how you produce software. This is how you do software. And then when you come from a different world, you have that perspective. You start to appreciate it and you want to like, okay, really understand how is this thing going to work? How is this held up? That was my fascination of like...
the tooling behind all of the things that we had at Facebook, the tools that allow you to control the release of features. So they literally decoupled code shipping from feature shipping. And that is controlled by this thing called Gatekeeper. In real time, you can turn on feature...
or turn off features for a very, very, very specific set of folks. So you can turn on features to only Washington state or to Seattle folks, or even like, you know, a lot of times we turn on every feature to New Zealand because it's English speaking. You don't have to invest in localization. You can test it out. Yeah, it's a sandbox. And even if things break, you know, it takes, you know, 12 hours for the news cycle to hit so we can like fix things before. Literally, those are the kinds of conversations...
But you have to know that if you open up Facebook, there's about...
600, 700, 800 features that are lying dormant in that app that could be turned on any time when the team decides that it's actually the right time to turn on. So they may be testing it. And that's a paradigm shift. The notion of code ships but may not be active. That really is what enables all sorts of interesting on-the-fly and very targeted experiments to happen. It's like
Look, all the code's in production, but most people are just having the same experience they've always had. Exactly. That's the foundation of this new paradigm of software development. Once you understand that, then you start to like, okay, build on top of that. And Facebook did. And then most of the industry is still like, you know, still figuring out feature flags, which is kind of like what this is, feature gansing and feature flags. We called it gatekeeper at Facebook.
But what Facebook did was we invested even further. So beyond just being able to control a feature, you could also measure the impact of the feature. So when you launch it to just 1% of the population, there's 99% of the population that don't see the feature, which means you've already created a set of split of the metrics and the behavior of the people that see the feature. Compare that with the people that don't see the feature, you can find statistical differences there.
and when you're able to find statistical differences in metrics, you can quantify the impact of that feature. So this like literally tells you like, okay, this particular feature that I invested so much time and effort in is actually going to be beneficial for the users or not. And if yes or no, by how much? And that makes you take data informed decisions about should I ship this thing? Should I continue investing in this thing or should I roll it back?
This is the crux of the cultural shift of software development where people no longer are interested in just shipping code or shipping features, but they're interested in quantifying how well
The thing that I worked on is improving people's lives. And if I think back, in order to be able to do this end-to-end, there's not enough integration to pull it off as a startup, typically. You've got some analytics package on your website. You've got something like Google Analytics in your product. You've got something like Amplitude. And then your whole engineering stack is pretty disconnected from whatever your analytics stack is. So even if in your engineering stack,
Codebase, you have a good system for turning on the ability to just show something to 1% of the users. It's pretty hard to then tell your analytics, hey, I need you to segment out all these users and treat this as an experiment so that I can learn from it.
Like I can see why having a big internal team at Facebook is helpful for creating that end-to-end platform you need to actually make sense of this. Yeah, exactly. If you don't connect the product metrics back to the features and provide a causal direction to like, okay, why is my metric doing this? Oh, it's because this team shipped this feature online.
to this set of population. If you don't connect those two things, then it's extremely hard. Then you're like looking at, you know, graphs and trying to make sense out of it without the tool telling you exactly what really happened. That's the important part. There are tools out there that'll tell you like an amplitude is a great tool that'll give you product analytics.
And then there are tools out there that will do feature flagging. But when you connect those two things, it's where the magic is. I mean, obviously, you have to do the causal analysis and actually be able to point out this is the reason, the root cause analysis. So that's the power that we had inside Facebook. That's the one when I started thinking about the perspective, like, OK, outside of Facebook in the industry,
There are not very many tools like that. There are A/B testing tools, but then you have to really know what your hypothesis is. Then you have to really build the A and B variants and put it out there and then have your data science team measure and go debug and all of that stuff. That takes a long time. And most people will run one or two A/B tests for whatever the critical features are. Whereas what we were able to do inside Facebook is like every single code change.
You have a metric associated with it. You have not just one, it's a set of metrics. And these are business level metrics, business critical metrics. Do you know roughly how many engineers at Facebook are dedicated just to infrastructure like this? A lot. Like I'm imagining like a couple thousand probably. Yeah. The other interesting thing that I also noticed is that the best engineers at Facebook want to go work on the infrastructure side of things, including the developer infrastructure industry.
Usually my experience before that is like, you know, the internal tools team is considered like, you know, usually not the, everybody wants to be in the customer facing team. Internal tools team is not quite like, you know, as sexy or magical. But it flipped at a certain point. It did. It did. And most senior engineers kind of like gravitated towards like solving these problems, scale problems and internal developer problems. And you can see that.
You could tell the difference, the quality of the stuff that comes out of the infrastructure team in Facebook was just ridiculously good. Okay, so how did you then think like, okay, clearly there's like a product opportunity here, probably a business opportunity around this. What made you think that you're like, okay, we can go start a new startup and create this? Like, this seems really hard. Yeah.
I mean, the opportunity and, you know, once you start examining the industry and what is the market potential for something like this, you know, there's a lot of like analysis there. Let me also say that if you anybody that is doing a startup, there's a little bit of crazy in them. Right. There's a crazy bit. Otherwise, look, if you're if you're entirely rational.
If you're constantly doing what is my expected outcome, if ever you do that math, nobody should ever start startups. Right, because of course expected value is the probability of success multiplied by the magnitude if you are successful. And the probability of success, it's unknowable, but it's probably pretty low. It's not high. Yeah.
It's very low. And so if people are rational, everybody should be like joining large companies. Nobody should be ever doing a startup. So yeah, so there has to be some amount of craziness.
Along with that, there's some amount of blind faith as well. You can do as much market research, you can convince yourself that there is a market out there, but there's an element of like, you know what? I believe in this so strongly that I'm willing to give up whatever that I have to go do this crazy thing. It's kind of like,
not unlike jumping off a cliff, a lot of things came in together. So part of it is like, you know, I have two kids, they're grown up and, you know, there wasn't ever a good time for me. Like, you know, we had the first one and I was like, okay, well maybe when our first born grows up, I don't know,
I can go. And then we had our second one kind of like, okay, well, let's reset the timeline. And then you also have to like consider financially too. You don't want to put your family at risk. Once you have two kids, you're kind of like, you know, I don't want to like go without a salary for a while until you save up enough. And then like, okay, well, now I have some cushion that I could go do some crazy. So a lot of factors come into play.
Secondly, I was like 10 years at Microsoft, 10 years at Facebook. What am I going to do next? And that was like, OK, well, I don't really want to go work for a large company. And so then it became like, OK, this is my last shot at like going and building a startup. Otherwise, the next 10 years goes by. I may not have the energy or the capacity. So that was like all the combination of that plus a strong idea that made me go do this.
Did the desire to do a startup come before the idea or was the idea so good that you were like, I got to chase this? I know the desire to do a startup came first. It's one of those things where you kind of like, okay, there's a part that comes from your heart, which is like, I will regret if I didn't do a startup.
So that part was always nagging. And then the idea was more, it came from the brain. Kind of like, it's logical. It's like, okay, well, if I were to do a startup, what is the maximum probability of success? And so let's go pick that one. Yeah, I love that. Marriage of the brain and the heart.
first part of the decision matrix you were talking about there on the family side, just because I'm in this now too. And like, I now understand in like such a real way that like when it's academic, it's very different than actually raising a kid. How old was your youngest kid when you decided, okay, I'm going to go
do a startup there. Four. Yeah. That makes sense to me. Right. So she's now six. It's been two years in this journey of stats. It'll be two years in about two weeks. So I'm kind of like excited for this podcast to align with that. We'll commemorate your anniversary. Before having kids like, oh, I could do startup. And now I'm like,
Yeah, that's his first year, especially two years. Like, yeah, I mean, you can, but you probably shouldn't. You could barely do a podcast. Or you could do a podcast.
That's why you kind of like see a whole bunch of people. It's so much easier. You're straight out of college. You can get like, you know, there's not very many responsibilities in a way. And you're kind of like almost free to go explore. And, you know, there's not very much to lose. And then there comes a part in time where you've gathered a set of like commitments and responsibilities. And so then you have to like make sure those are all taken care of. So in a way,
You've gathered experience and connections that comes in handy when you're doing the startups. That's what I'm noticing is like, you know, the benefits of like me out there building the stuff is I have gathered 20 years of software building and people coaching, growing, scaling, a lot of experience that I wouldn't have had if I had done something like this early on.
So I want to take us into the product itself of Statsig. You were witnessing a wide variety of amazing tools built by some of the best engineers in the world at Facebook. How did you analyze what subset of these tools can solve what specific problem that warrants starting a new startup in the world?
Yeah. So when you're trying to think about what to start with, this is not where you would end with. Where you start is kind of like important because you want to understand what is the friction to adoption? What is the wow moment? How soon can we bring the wow moment to the people? And so the quicker you can, the faster the adoption is and the more traction you'll get.
And so for me, Gatekeeper was the simplest thing to help people understand and also applies to everyone. It doesn't have to be like a specific industry. It doesn't have to be a specific stage in the startup. It applies to everyone. Most people, when they look at it, they're like, OK, I understand the value of this. So that's where we started. So we started with just Feature Gates.
where you can control the release of your features and you can decouple your code releases from your feature releases. Very simple, very good value proposition. And then once somebody has a FeatureGate installed, then for us to provide more value by actually like, you know, showing the metric impact, that's kind of like what we did next. So organically, we kind of like built. So I got to tell you, it was nerve wracking. Like I can tell you that this is the sequence that we took,
But when we were doing it, there's a lot of doubt. It's something that I guess all founders and all startup teams go through, where for the first four months, you're building in vacuum. Nobody is telling you this is what we need. A lot of it is coming from intuition. A lot of it is like, okay, well, we think this is what people want and then build it and pray and hope that somebody really wants that.
We tried really hard to get people to give us a shot. We wanted to give it out for free so we can get some feedback. So we were looking for design partners and nobody came. So I would say six or seven months in, that was the lowest point in our startup where we started to doubt, okay, is this really even going to work? Let's give it another end of the year. What did you do at that moment in time?
Yeah, I was talking to like everyone. If I can get someone on a phone call or a Zoom call, I would like, you know, hey, try this out. You know, have you used this other competitive tool? We can do the same things and we'll give it to you for free. You try every approach that you can. I'll come to your office. I'll install it for you. Oh, yeah. We'll do hackathons. We'll like, you know, code it up for you. If it's a specific feature that you're using in a competitive tool, we'll just go build it for you.
it's nerve-wracking if you've heard of the startup dip that was kind of like and i would say we were at that dip we were kind of like starting to really wonder if this is going to take off and then you kind of like so at this particular moment there was some traffic coming from indonesia singapore like southeast asia at first we were like okay well is it some sort of like
someone trying out from there and like using our SDK. And then the traffic started increasing. We thought like, oh my God, somebody's trying to DDoS our system. And then we realized like, nobody even cares about us. Why would they DDoS our system? So what happened was an ex-Facebook engineer built an app in Singapore to order food. This was like during the pandemic. So to order food over WhatsApp and that uses our feature gating system. And that was ex-Facebook engineer. Yeah.
And I was like, aha, interesting. That could be a good target market. Exactly. So then we started like, okay, well, if anyone left Facebook to go join another company, I'm pretty sure they're missing the tools that they had access to inside Facebook. So let's actually sell it that way. Let's go and find all those folks and give it to them. And it's so much easier to sell. Like, look, this is exactly like Gatekeeper. Yeah.
If you miss Gatekeeper... You've got this shared language. Yeah. There's no market education. Exactly. So our first contract came from Headspace where an ex-Facebook product manager was the head of product. And he's still the head of product at Headspace. And so he was like,
oh yeah, this makes sense. And so let's give it a shot. I'm so grateful for that first contract that we had from Headspace because that really gave us a legitimate reason to be alive and kind of like, you know, validated some of the early, early hypothesis we had. And then since then, you know, we've grown, we've had like,
you know, a couple hundred customers now. So we're pretty on our way and we're building more and more. Now, this time around, we always listen to our customers and they can tell us what they want instead of us building in vacuum. So that's the big difference. Leading up to that dip before the WhatsApp food ordering in Singapore, had you raised money? Like, what set of stakeholders did you have to worry about?
Again, I was very lucky in this respect. This is part of like, you know, being in the industry for a couple of decades and you build connections and people help out. And so Mike Vernal, who is my manager at Facebook, had left and gone and become a partner, a GP at Sequoia.
And he and I chatted a few times even before I really started Statsig. And so he was very excited about this idea of like the developer tools, bringing it out. And so, yeah, I got to say, I'm very grateful for him to believe in Statsig to like invest the first check. And that's how we were able to like, you know, hire people and start building this stuff. In a way, we thought about this as like, it's a seed investment. So let's actually build what we believe is the product. And then we built it.
Good thing for us is like we didn't have to design it. There's a lot that we already know that we had to go build. And so it was easy for us to just get started and run fast. I think there's an interesting Rorschach thing going on with the way that you just described this journey. If someone wanted the confirmation bias of I'm a visionary, they could totally interpret everything you just said as, well, they went and they built it in a vacuum because they knew exactly what to build and they went
heads down for months and then they shipped it and then they worked with customers who clearly wanted what they had but if you have a lean startup methodology and you're looking for confirmation bias on that you can also listen to what you just said and say well they were aggressively pounding down the doors of anyone who would listen and trying to work with design partners and coding stuff up specifically to what customers were asking them for so
In this sort of holy war of lean startup versus Steve Jobs, where do you think you actually put the truth of your approach on that spectrum? Oh, I am so far away from Steve Jobs. I am like, you know, I don't know. No, no.
I often appreciate that when what you believe actually goes wrong and you're not attached to it, you have the humility to say, okay, I was wrong and I'm going to drop that and then go build. So I didn't go into the details. There's so many things that we built and shipped and then killed and that's okay. And I would any day, any day,
take. Someone that tells me, okay, I want this. Okay, I don't like this. That feedback to me is extremely important. In fact, so much so that is the ethos of Static. It's about iterative development. Like I said, Facebook, 80% of the code that we wrote was not working the way or didn't do what we expected to do. And so we always have to rewrite the feature or rework it or just plain throw it out.
When data is making those calls, it's a cultural element of like, you don't get attached to what you write. I know that there are people out there that are visionaries with amazing product intuition that could probably say like, oh yeah, this is what we're going to go build and we're going to build it for the next two, three years and we're going to ship it. You know, Steve Jobs does it. Right.
Right, there are people who could do it, but like, yeah. Right, but I think it's very rare. The majority of us would benefit from like actually iteratively developing, take the next step, figure out if it's actually the right step, if not course correct, and then change the direction.
How early could you start self-hosting during the development of Statsig? Like how early when you guys were coding up Statsig, could you start using Statsig to make decisions about if customers wanted that feature of your product or not? Yeah, so we were using Statsig from day one, not for making product decisions, but for gating features. You know, as we were in development, you know, features may not be fully done, so it's gated out.
And then we will do dogfooding to make sure that there are no bugs and such. And then we roll it out. A lot of times, the understanding of the impact is important. But even before that comes, you want to catch...
big major issues big interactions and side effects and bugs when you launch something when you open it up to one percent or two percent of the population if there are bugs you'll immediately notice that that something is tanking some metric is destroyed and you want to like pause the rollout or roll it back and then go fix that issue so we used stats the entire time from day one that's cool
So what's some of the cool stuff you can do once you have that infrastructure of basic feature flagging built? I mean, I assume that in talking with these hundreds of customers now, you're getting all sorts of crazy ideas of like new abstraction layers you can build on top of it.
The most important thing is if you are constantly measuring. So what we're talking about this is like, you know, let's take an example of like observability. When people talk about observability, like companies like Datadog have made it extremely easy for you to identify an issue that happens in one server out of 100,000 servers in real time and then be able to like go fix that and then identify and take away the problem.
That's like fixing your infrastructure. Yeah, that's the infrastructure side of things. But when it comes to product, we're still like in Stone Age where we build up or bundle up a bunch of features and then we launch it as a version. And then you put it up in the app store and then you wait for adoption and critical mass adoption to happen. And then you have some data scientists go back and like, okay, what day did the product launch? And then draw a vertical line in the graph and then see, did any of my metrics change?
you know, change or, you know, is there inflection in the trajectory? And that's like super not scientific. And so I think where the immediate thing, once you have feature flags is to be able to like, you know,
with precision, with confidence, tell which of my 10 features that I launched yesterday are impacting what metrics and by how much. And that is incredibly valuable. So that's kind of like, that's what we call is product observability. So you observe, you understand what your product is doing without any doubt, without any confusion with the causal prediction. And so to be able to like go and say, these four features are actually tanking our revenue, let's turn it off
and then immediately get the revenue boost that you were missing is important. The next step is to be able to identify anomalies. So outliers is an important aspect of debugging. So imagine you shipped a new registration flow and your number of conversions have gone up by 5%. Everybody's happy, everybody's celebrating. And that's the average number. What if a tool can tell you that even though the average is 5%,
On Android devices that have screen sizes smaller than five inch, you're actually seeing a 20% drop in your registration conversion. Now that's an outlier. How would you even know to ask that question? The tools should be able to like identify that anomaly or outlier and tell you. Just like Datadog is telling you which server is running out of memory.
We should be able to tell you win the product with precision. So those are the kinds of things that we're building, those are the kinds of things we're investing in. We did our big episode on Amazon. I got deep into the sort of perf engineering blogs of some of the engineers who worked on the site in the late 90s and early 2000s. And this was one of the big things that they sort of had a vendetta against averages because averages hide the distribution. And how do we figure out how,
how we didn't make something less performant for a potentially very important segment of e-commerce customers when all the numbers look good overall. Exactly. That hits the nail. The idea of being able to identify these outliers and then bring it to the product team. Look, the whole idea is to bring all that data to you so you make data-informed decisions. At the end of the day, the decision is still for the product team.
Sometimes shipping it will continue to make sense because, you know, the trade-offs are worth it. So then taking it even further of like, once you understand the outliers, can the system automatically roll back? So, you know, you could set guardrails and say like, you know, I don't ever want to ship anything that'll tank my ship.
retention metrics by more than 5%. If my retention metrics, I set a guardrail 5% is the range that I'm willing to give up. And if it goes beyond that, if the system can automatically roll back that particular feature, now those are powerful.
Now we're talking. Now we're in the real observability space. And so that's why we're taking our product. We're building a lot of the real-time analytics. We're building a lot of guardrails and alerting and notifications. And then eventually we want to get to automatic rollouts and rollbacks.
It's cool getting this level of depth on the show because for Acquired, we tell these big three, four hour stories of companies where we're looking 20, 30, 40 years in the past and getting these big beats of story. And so it's cool to sort of hear what the state of the art of how would one go about actually building a scale product today and what are the set of tools and what infrastructure is available if you're not Facebook. Yeah, exactly. So we've been talking here about all the
increasing set of product features for Statsig. I want to talk about your go-to-market too, because obviously you are an enterprise software company. It's very different than Facebook and enterprise software go-to-market is a thing with playbooks, rules and whatnot. You've made some interesting decisions there too. Specifically, you both have an enterprise go-to-market and
and a self-serve go-to-market at the same time as a startup. Tell us about that. When we started, we were a bunch of engineers, right, together in a room. There was no world in our mind that
that you cannot have a self-serve product that is focused on developers. So when you think about engineers, typically, what do you think? They have inspiration and they just want to go code it up. They don't want to talk to enterprise software people. Yeah. You put a 1-800 number in between your inspiration and your motivation to code something up. That
something doesn't work. That just doesn't work. And oftentimes, inspiration hits you at like midnight and you're furiously coding past midnight.
Imagine calling a 1-800 number during that time. So the decision to have a self-serve was a no-brainer. It has to be. And this tool has to be self-serve. And a lot of the stuff, you know, the SDKs and the documentation, all of those are open source. So we want everybody to be able to like, you know, just open it up, understand how we do this and like, you know, change it if they want to. It's not even debatable. It has to happen.
And then, you know, what I learned after that is like, okay, there are people that will go download the SDK. They'll integrate that into the app, like the food ordering app that happened in Singapore. That's all good. But then the moment we started talking to a serious company, the first thing they asked was like, where's your NDA?
We want to sign an NDA. Where's your DPA? Do you have SOC 2 compliance? And we're like, what are those? We spent about three, four months actually preparing those because, you know, hey, SOC 2 compliance doesn't happen overnight. Can we ask how did you become SOC 2 compliant? We went to Vanta and said like, please help. Yes.
Christina will be very happy. Did not orchestrate that. I just sort of, listeners, cast the line out. Yeah, we're very happy customers of Vanta. And they helped us out. They expedited it. And so within a month or so, we had SOC 2 compliance certification. I got to tell you this, though. You visit websites and you see all these badges at the bottom. You make fun until you actually have to put those in.
Until they become a big part of your revenue generating story. So now we have badges. We proudly display those badges. You either die a hero or you display badges on your website. That was kind of like a moment for me to pause. Okay, I think we're now talking to serious, large companies that operate very differently than self-serve.
And that's how we started building a sales team. We hired some SDRs to like go get some prospects. And then I was so lucky. I had someone connect me with Sam, who is our sales lead now. He was in segment. And so I was able to convince him to come and like run sales for us.
Stats Egg was a great fit and he had connections, lots of connections and people, you know, great leaders, people follow. And so we now have a very strong sales team that is covering pretty much all of sales. To me, my mind, these two things are not mutually exclusive. The self-serve and enterprise motion, they both exist and they both serve very different set of people. Self-serve has been very good for all those people that want to like just build a hobby app and then like try it out.
including people or engineers from large companies that are just testing things out. Like, you know, it's so much nicer to be able to like just download stuff and play around with the console, play around with the tool, understand the benefits of it and the limitations of it, and then go to your manager and say like, hey, I think you should use Static. And then like, you know, the sales team gets engaged and so on. Yeah, I was gonna ask, how does that handoff happen?
When does something go from the KPI that the self-serve person owns to the KPI that the sales team owns? The self-serve has actually become a kind of a funnel for the sales team. That worked out really well, so much so that we created a commercial AE team. So what this commercial AE team does is like, you know, there is the enterprise AE team that is taking care of like, you know,
starting conversations, doing outbound prospects and then working with them on like a proof of concept and so on. The commercial AE team is interesting because they take people that are already onboarded through the self-serve and then go to them and say like, hey, look, if you sign a 12-month contract, we will give you even better rates and stuff. And then plus you get like support. So for them, it's easy for them to convert like people that have already understood the value of Statsync into a contract, right?
And we're landing a lot of good small-sized contracts, a good number of them, and I've been very happy with them. So we've doubled our commercial AE team from one person to two person recently. I'm actually pretty bullish on this model. I mean, literally, you're kind of doing all three major go-to-market strategies for enterprise software. You're doing big enterprise sales, you're doing self-serve, and you're doing the bottoms-up adoption all through the same org. Yeah.
Yeah. And we're doubling down even further. And so recently we've packaged out the most commonly used self-serve product, which is feature flagging. So for us, the feature flagging part of it is a stepping stone. It's the first step you take, you know, to integrate your product. And then beyond that, the value we add is all about the analytics and the impact analysis and the quantification of the impact, right? So feature flagging is like,
commodity. And I think everybody should have it. We believe everyone should have access to feature flags. And so we're giving it out for free. So we just launched a feature management package where we're giving out basically the entire set of like all the capabilities of the feature management system packaged out and do for self-serve purposes. Anybody can like pick it up and, and use it up to 500 million events. So, which is a pretty generous offer, which kind of like
It takes away a lot of what you would need to spend, especially if you're small, if you're a startup, to some of our competitors. You can feel free to not answer this if it's sort of digging up dirty laundry, but is this something that incurs material cost to you and therefore has to really work? Or is this something that you can actually do pretty cheap, so why not offer it for free?
Yeah, so the majority of our costs are the analysis, the data analysis part. Feature flagging by itself is extremely cheap. And it's kind of like, you know, usually when you're running server SDKs, it runs on your servers. And so it doesn't even cost very much until...
we are collecting exporter events and doing the analysis and stuff. So, but we do want you to like, you know, start using those features. So part of the equation is like, yeah, we can give it out. It's very cheap, very easy for us to run. And it's probably like the right thing for everyone to have access to just the feature flagging part of it.
We also have a pricing philosophy where we don't charge anyone anything that doesn't cost us money. It's a very simple pricing philosophy. It's like seats or SSO or MAUs. None of those things cost us any money.
You have unlimited seats, unlimited SSO. It doesn't matter. The thing that we charge you on like, okay, if we process your data and we actually do a pipeline analysis, that costs us infrastructure dollars. We add a margin on top of that and we charge our customers.
So you basically are, the feature flag is an SDK that runs in their infrastructure, but then all of the analysis stuff needs to get pumped through your Statsig-hosted cloud. Correct. There is a small cost for us to be able to host the config and then be able to download and make sure that the throughput and the QPS and all of that is maintained, but to us it's negligible.
Speaking of you lived long enough to become the villain, I am so curious if we were to talk to you in five years, if your entire pricing model will still exclusively be cost plus margin, or if you'll have figured out how to dial it in where you're like, look, we actually can be a lot more profitable here. And there's plenty of customers that are happy to pay us for things that don't cost us a lot of money. Look,
I've also been around for a while to know that I wouldn't have to, I shouldn't say anything that is set in stone. Things are bound to change. And, you know, I'm a pragmatic person. The interesting thing is, like, I believe the model that we have now is scalable. And when we talk to people, when we talk to our current customers that are using StatsSync,
they are comfortable with that margin and they're comfortable because the value that we provide and the value they get is really good. It benefits us as well because when you don't charge for seats,
everyone in the company will use it. It just travels. The tool just travels. Your product managers, your engineers, your data scientists, your designers, your execs. We want everyone to just hang out in the tool and use the tool. You get embedded in their culture then. Yep, exactly. Well, kind of like the Facebook culture expert, the ultimate goal is you become the standard way of doing things. And as people leave companies, go to new companies, start new companies, the tool comes with them.
Yeah, exactly. We've seen that happen. A few of the engineers that have switched jobs, they've taken Statsig to their new companies. I've had Deb send me photos of her board meeting where they're presenting Statsig charts. To me...
That's success. That's what we want. We want people to be able to generate a report and send it to their managers and send it to their CEOs. At Facebook, we used to call, where's the Deltoid link? For every feature somebody wants to ship, where's the Deltoid link? And so we want everybody to like, where's the StatsLink link?
MARK MANDEL: Oh, interesting. And what's the deltoid link? MARK MIRCHANDANI: It's the quantification of the metrics for a feature. So if anybody says, hey, I want to ship this feature, the first question somebody's like, where's my deltoid link?
Because you do want to take a look at that deltoid link and say, if this feature is positive entirely, it doesn't hurt the company critical metrics, then there's no reason to not ship it. It's beneficial for the users. It's valuable. So let's ship it. Same way I want the conversation to be like, okay, if somebody wants to ship some new features in a company, they should ask, where's that link?
I love it. Well, I think one beat that I want to hit before we close is after reflecting back on all of this, for other people who are in your position, 20 years at very successful companies, technical background, and there's lots of folks who listen to this show that have executive leadership roles, what would you tell them? Or maybe what would you tell your former self two or three years ago that you wish you knew then?
The first thing is, like I said, I knew I would regret if I didn't do something crazy like this. It would always haunt me. And so if you ever have that kind of like an inkling, I think it's beneficial to go explore it.
It is nerve wracking. I wouldn't sugarcoat this. I made a ton of mistakes and I even explained like the first six, seven months of our journey was pretty rough and hard and you need to go through that. Chances are we may still fail and that's okay. And chances are there's a lot of unknowns and I've made a lot of mistakes.
But what I've felt so far in the last two years is like, I am so much better than I was before in learning these things, in understanding the mistakes that I've made. It's humbling. You build a humility and you see the world very differently. I mean, you shed the bubble that you were brought up in, right? It's kind of like, you know, any large company you spend long enough, you build a bubble around. Yeah.
You see things as they are. It's very different. I would never trade these two years for anything else. Even if Statsy doesn't succeed, even if we don't go anywhere, I would still fondly remember these. At the end of the day, these are memories that we're creating.
Yeah, you put yourself into a situation where you had to learn or die, right? Like, there's no other option. Like, I assume you didn't know how to do enterprise sales before starting Stats Inc. Oh, no. I made probably every single mistake in the book. The other aspect that I would also mention is like,
At some point in my life, early, early career, I chose to chase technology. And so I was like, I want to be a compiler dev because compiler engineers are like gods. I mean, I want to be like... The most hardcore graveyards. Yeah, I want to be like them. And then I actually like worked on compilers, worked on language services, you know, incremental parsing. A lot of that stuff. It's great that I did that.
And at some point you realize that people problems, user problems are more interesting than technical problems. And so you kind of like figure out how you chase them, chase user problems. And after a while, you kind of like want to chase people. You find good people and you want to stick with them because you enjoy working with them. You learn a lot from them and then they kind of like become your mentor and sponsor and you kind of like grow with them. At some point, the equation flips. You
You'll start to notice there are people following you, people that are looking up to you. And when that happens, just make sure that you take care of them much like somebody took care of you. When I think about the company that I'm building, who I am bringing along, how can I help them? That is definitely top of mind. It's something that you're paying forward. I love it.
Well, Vijay, where should we direct listeners if they want to learn more about you or Statsig or perhaps try out the newly available free functionality of Statsig? Yeah, so Statsig.com is our marketing site. If you go there, you should be able to get a feel for what we are, what we're building, and what you could get out of it. So that's where I would go. Great. Well, Vijay, thank you so much for joining us.
Thanks, guys. This was really fun. I enjoyed having this conversation and digging up the past. So thanks for having me. Thanks for doing it with us. We love this. We'll take Facebook war stories anytime. Awesome. Well, listeners, we'll see you next time. We'll see you next time.
