He Bootstrapped Wrike to $10M ARR—then exited for $2.2B. | Andrew Filev, Founder of Wrike & Zencoder

Andrew Filev (00:00:00):
It was a kind of a blessing and a curse that we were bootstrapped originally. Because I think if we were venture business from day one, we would not survive. I very quickly went all in. I had prior experiences and they failed. And kind of looking at retroactively, I understood that the main failure point was not technology, it was not even product, it was just the fact that I did them as side gigs and didn't give them enough love, and focus. I didn't buy into the pivot, but I did buy in rapid evolution. I picked a niche that I think was super important for the world and that I felt I was passionate about. And then I kept grinding at that niche. Focus on people. All the good stuff in your company comes from people. Bring the right people, build the right culture, and then your life is going to be easier.

Previous Guests (00:00:46):
That's product market fit. Product market fit. Product market fit. I called it the product market fit question. Product market fit. Product market fit. Product market fit. Product market fit. I mean, the name of the show is product market fit.

Pablo Srugo (00:00:58):
Do you think the product market fit show, has product market fit? Because if you do, then there's something you just have to do. You have to take out your phone. You have to leave the show five stars. It lets us reach more founders and it lets us get better guests. Thank you. Andrew, welcome to the show, man.

Andrew Filev (00:01:13):
Hey Pablo, how are you?

Pablo Srugo (00:01:14):
Good, good, I'm excited to be speaking with what I consider a legend, man. I mean, Wrike is a household name in the world of kind of Sass, right? Where I've been playing for a while, and so you started that business. It ultimately exited for over $2 billion. Which is massive and , you know, you were you were mentioning to me earlier when chatting. That it was it was a kind of, quote, unquote, longer road. I mean, that you kind of bootstrapped and it took a while to kind of get things right before things really took off. So I'm excited to kind of dive into that with you.

Andrew Filev (00:01:46):
Yeah, same here. Where should we start?

Pablo Srugo (00:01:49):
Well, let's start at the beginning, man. I mean, it was I guess you started right, when? Like, 2006 or so? 

Andrew Filev (00:01:53):
Around that, yeah. And as you mentioned, it was a long journey for better and worse. Because in a lot of businesses, timing is one of the harder things that you can follow. Just in general life, right? You can control a lot of things, you cannot control time, and so we were a little bit ahead of the market. And so it was a kind of a blessing and a curse that we were bootstrapped originally. Because I think if we were venture business from day one, we would not survive that long haul. Venture, as you and many of your listeners know, is kind of like a growth drug. With the constantly re-upping the dose, right? And so you got to move fast and grow fast. And so if you start ahead of the market, there's no way you can keep up that pace. But on the contrary, if you're bootstrapping and you start ahead of the market. If you can survive that, then you come well prepared for when the market kind of kicks into the high gear, right? So for me, we were always grew quote on quote exponentially. No, not always but plus or minus exponentially. But if you start with small numbers, it takes a while for that to kick in. If you double $1,000, it's still only $2,000.

Pablo Srugo (00:03:13):
That's the best way to make those fastest growing companies in Excellence, by the way. Just have a really bad first year, then you can really kill it.

Andrew Filev (00:03:23):
Start with $100 and you can show 1,000x growth. If you have a real business, yeah.

Pablo Srugo (00:03:30):
And what was? Maybe just to set context, where did you start? Like, where were you based when you started Strike? Wrike, sorry, and what was happening? What leads you to start, you know, a collaboration platform?

Andrew Filev (00:03:40):
So I just moved to the Valley, and the reason I moved is. 

Pablo Srugo (00:03:46):
Where were you from originally?

Andrew Filev (00:03:47):
Originally from Russia, not the most popular choice today. But, that's another thing you can't control. Where you grow up, right?

Pablo Srugo (00:03:56):
Definitely.

Andrew Filev (00:03:57):
So I moved here, because I always wanted to build products that would be used by millions of users, right? I wanted to kind of make that impact, and I felt that back then. And to some degree still up until this point, but definitely back then. This was the place to be where most of the companies, that grew to that scale quickly came from the valley. I don't remember examples outside and so it felt like, hey, this is where I can come, and learn how the best people do it. And if I'm lucky enough, I could maybe do it myself. But if not, I'm going to keep trying and kind of keep learning. So, I came with the desire to build products that help a lot of users, and that's the difference between. By the way, invention and innovation, right? So invention is some idea that you can come up with. And back then, to a large degree, up until now. I come up with a bunch of ideas every day. So I'm one of those guys who are in a camp that ideas are cheap. Because, again, you can come with a lot of them, right? Matters is how do you bring them to market and that connotation. And that implementation, that execution, that innovation. And so, the innovation is when that invention is adopted by people, right? So the more people adopt it. The more value you create in the world, which is awesome and I'm kind of, I'm a builder. So, that's what brought me here and as I. You asked about the background of why I started this specific company, right? So back then I had a services company, that was fully digital. Which today is like, duh, everything is fully digital. But back then it was fairly new, and we were doing well. Growing fast and I kind of noticed a lot of issues in coordinating the regular digital work.

*Pablo Srugo (00:05:46):
What were you doing? Was it an ad agency? Or

Andrew Filev (00:05:49):
It was software development, so basically. 

Pablo Srugo (00:05:51):
Okay, software got it.

Andrew Filev (00:05:52):
We built an app. And by the way, that also was kind of a good backdrop. Because we were one of the first people in the world to start, to experience building real web apps. If you will, because back then I don't know. Most of your listeners might not even remember the time. But websites were like, you click on a link and then you wait till the other quote on quote page loads. So that was kind of the web, right?

Pablo Srugo (00:06:19):
It's not the fun internet.

Andrew Filev (00:06:21):
And it was like the early days of the term that again, most people either forgot or don't even know. Like Ajax, as in front of JavaScript and HTML. So you got that first web apps appearing. I think back then the best of that first wave were Google Docs and then surprisingly Microsoft Outlook Web Access. So that was kind of a true app living in the browser. Regardless of what you thought about Microsoft and Outlook, and whatnot. But it was kind of one of the first true web apps. But the rest of their stuff that people use. They mostly use the desktop, right? And so, for example, to manage work. If you ask anybody, where do I manage work? People would tell you, try Microsoft Project. 

Pablo Srugo (00:07:11):
Oh, Microsoft Project. 

Pablo Srugo (00:07:13):
That was the tool built for, I think, construction industry mostly. Or maybe like their original, you know, IBM style.

Pablo Srugo (00:07:21):
So like Gantt charts, no? That's where you built those Gantt charts?

Andrew Filev (00:07:24):
Yeah, if you want to build something over the next two years and kind of control the delivery. You still got to use Gantt chart, it's a perfect tool. But every tool should be used in the right context. And if you're operating a digital team, where you got everything kind of thrown at you at once and changes every day. Then that's not necessarily the best approach for you, and then it was also the time. Where I kind of got influenced a lot philosophically by several movements. So I was one of their early adopters of Agile. So Agile Manifesto came around, I think 2000 or 2001. So before that software development processes were different, but that's when that was a big change. I still remember the stuff like extreme programming. Which kind of quickly morphed into Scrum. And Scrum is the process that almost all engineers use today. So that idea of kind of moving fast and being super collaborative. And then a related but separate trend was the kind of emergence of what you can call Wikinomics. There was also a term enterprise 2.0, but basically this focus on collective intelligence. The fact that, hey, if we work together, we can build amazing things like Wikipedia, right? That are sort of, like,   you can't imagine just doing it in a traditional way. Where you build a team and a plan, and just execute. It's got to be more collaborative and more emergent, if you will. There was kind of the very popular word of like emergent. You put a bunch of smart people together and something good happens, right? So, especially if you give them the right tooling. So the idea was, hey, can we take the best of all those ones? Like, hey, could we build a solution that would be collaborative? Can we build a solution that still can help you manage that chaos. But do it in a way that kind of leverages your full collective intelligence? So that was the philosophical genesis, and as I said, there was like a technical genesis in me having good competences around building web apps. And then there was also kind of early beginnings of their business wave of, quote unquote, SaaS appearing. And then everybody's told that, that's kind of the new thing. But of course, it was a new thing. Nothing is instantly invented. There were other kind of precursors to that. But B2B SaaS was kind of getting started to the rise. And so all of those things led me to kind of where I started Wrike. And thought that, hey, it'd be really good idea to build the app that people could use to coordinate their work and teams. And kind of the rest, as they say, is a history.

Pablo Srugo (00:10:06):
And, did you do it on the side? Like, you're building apps, custom apps, right through services. So did you just kind of start this product division on the side or did you go all in? How do you think about the time split?

Andrew Filev (00:10:17):
So I very quickly went all in, because I had prior experiences. Which were super helpful where I would kind of experiment building products, and they failed. And kind of looking retroactively. I understood that the main failure point was not technology, it was not even product. It was just the fact that I did them as side gigs and didn't give them enough love and focus. And so, and which was still kind of, again great learning experience. I never regretted doing them, right? But I thought, Hey, this is what I want to do. I want to build product that's, used by millions of users. So I want to give it, my full goal and kind of allocate as much of my time and energy as I can towards that.

Pablo Srugo (00:11:01):
Where do you start? Because like 2006, also early in the stuff we take for granted today. You know, pick a niche, you know, Eric Ries, Lean Startup, MVP. All these concepts that everybody's going to use today, right or wrong. You know, I'm not sure they were very popular then. And so, this could be the sort of project that you could build so much. I mean, collaboration platform for everyone is a big idea sort of thing, a big product. Where do you start?

Andrew Filev (00:11:27):
Yeah, so the concepts that you mentioned were there and were actually kind of concept du jour. So everybody was, well, like lean was a super popular word. That I bought into, again, kind of goes well with that HL mentality. But there are some things that I didn't buy in and kind of went there the other way around. So one of them is pivot, right? So, there are brilliant people who can start selling cereal and then build the best travel business in the world. And there are people who can start building online games and then build the best B2B messaging app in the world. I was not one of those people. I picked a niche that I think was super important for the world and that I felt I was passionate about. And then I kept grinding at that niche for the next, whatever, 17, 18 years, right? Until I figured it out, and it doesn't mean you're. I'm not Steve by any means. I'm stubborn, but I'm not Steve, right? So I'm going to listen to every argument, to every data point. I'm going to change my opinions as I feel I need to. If there are inputs I change in, the output has to change. But at the same time, I feel that compounding is generally in investment. In life, in career as well, even if you're not an entrepreneur. If you're working for somebody else, I feel compounding is a much more reliable strategy than just tearing something apart and starting a new, right? So I felt that, hey, every year I work at this market. I build deeper and deeper understanding of the customers, of their challenges, of their opportunities, of the competitors, everything.

Pablo Srugo (00:13:13):
You're saying versus pivoting? Like, that's the kind?

Andrew Filev (00:13:15):
Versus pivoting, yeah. So why would I kind of drop all that knowledge and all that experience. And start something in a completely different area? But at the same time, as I said, I still feel that sort of when you're in a position where you're making important decisions that affect other people, like your employees.  You have to be intellectually flexible. So I'm not saying, hey, you're once and done, your initial product architecture or technical architecture should be there forever. You can change it tomorrow and then we should at some point get back to kind of Zencoder and AI. And what's happening today. 

Pablo Srugo (00:13:51):
We will.

Andrew Filev (00:13:52):
But even back then, in a very different world. You still have to be intellectually flexible. But I never saw it as pivot. For example, one of the key thesis that I started the business was, a lot of things were happening via email, and I built this very clever way of integrating with email. And this was kind of a lot of how I thought about it. And then it turned out like, yeah, it was kind of nice. But didn't necessarily, well, it wasn't the biggest thing. As opposed to some other thesis that I later ran, which was around kind of workflows. That, workflows are essential part of well-run businesses, and we need to figure out how to manage those digital workflows. That became a super successful thesis for our product and super helpful for our customers. So my point, you asked about what was popular back then and the theory of the business, if you will. And so for me, again, I didn't buy into the pivot. But I did buy in rapid evolution of the business, and then another thesis were. Which I consciously went against was, I love Jeff Moore's Crossing the Chasm. It's one of the best management books, business books, terror books. Fully buy into what he says. He's the grandmaster and whatnot. And I still did everything.

Pablo Srugo (00:15:16):
But I ignored it. Love it, but not for me.

Andrew Filev (00:15:21):
Yeah, so I was like, hey, I want to build product. I know there's every business moving towards digital, and I know every digital business needs this. And I'm going to build it. No matter what the theory says, right? And luckily, there were some examples that I could tap into. There were companies like Dropbox that were a little bit ahead of me, right? That showed that you could build horizontal product first. Because if you remember, the market box came after Dropbox. Not before Dropbox, right? So there were examples of how, and even Box, right? It didn't start as a documentum. It wasn't a ECM solution for pharmaceutical industry. It was like fairly horizontal platform. So I felt this was their good time to build horizontal applications that help with variety of different use cases. And I also felt that in general, the space that I was in, was that even if you. Even seemingly similar customers still had such diverse needs, that you have to be thinking about it kind of platform-wise anyways, right? It's not like, hey, I built for this specific use case and it's going to be perfect. It's more like every one of my customers is slightly different. So how do I build product architecture and technical architecture to support those differences in a good way?

Pablo Srugo (00:16:48):
But it's interesting you say that. There's that quote, learn the rules like a pro so you can break them like an artist, right? And, I think there is an element, as I speak with more and more founders about. Because you could think that, okay, go get the best theories out there, learn the best books, and then every single one that you follow just increases your odds by that much. You should do what, you know, but it almost seems like every founder I speak with, it's not like they break all of the rules. But it's like, the best of them, obviously luck is a huge factor, but take luck aside for a second. You learn a bunch of this stuff and then you decide intentionally, hopefully. Which one doesn't apply to you, and that is one way to get these outlier type of results. I mean, you might also end up with a zero outlier type result, but if you want the crazy one.

Andrew Filev (00:17:34):
Yeah, and I think. At least for me, again, I'm not saying it's a requirement. Because luck is indeed a huge factor in this. But at least for me, it's important to do those things consciously. So it's less about, hey, I'm a kindergartener who knows nothing. It's more about, hey, I know this stuff. I thought through the consequences. I'm getting paid to make decisions, and this is the decision I'm making. And I'm going to bear the consequences of that decision, good and bad, right? And I feel this is kind of this CEO job, this is also product manager's job, this is architect's job. You can't just do something because, that's what somebody else did before. More likely than not, they're correct and you have to go with the wisdom of the crowd. And kind of the wisdom sometimes of literally like hundreds of years before you. But sometimes you got to say, no, you know what. My first principles, my situation is a little bit different and I'm going to try something different. So another difference is, again, back to those kind of fashionable trends and books, and thesis back then. Customer developer was big, right? In kind of that lean startup.

Pablo Srugo (00:18:46):
Yes.

Andrew Filev (00:18:47):
That idea that you kind of work very closely with, and kind of. And again, this is not in the book. But in real life, what also means is that a lot of people would kind of tap into their friends and network, right? And kind of use that. When I launched my product, my first customers were people who I never knew. I still remember my first ever customer was a storage company out of Canada, and storage, not as in digital storage. Storage as like container storage, right? So, and in part this was less conscious in the sense that I was a geek, I'm still a geek at heart. When you build a business, you have to be more and more extroverted and more kind of sales oriented, right? But I still kind of geek at heart and it was easier for me to build a good product, and drop it out. And if that product's good, then awesome, you get to pick it up, and if it's shit. I didn't necessarily want to sell it kind of despite your will to you. I wanted to hear, I was ready for the pain. Like I was, I was ready for you to tell me that it sucks, and I had enough guts to hear that. And say, okay, I'm gonna got to redo it, right?

Pablo Srugo (00:19:59):
What was that like, actually? How long did you take to build the first version? And then how did you launch it?

Andrew Filev (00:20:03):
So, it's a good question. Unfortunately. 

Pablo Srugo (00:20:07):
That was a long time ago.

Andrew Filev (00:20:08): 
it's a blur right now.

Pablo Srugo (00:20:09):
So, yeah. 

Andrew Filev (00:20:10):
So, its a long time ago. 

Pablo Srugo (00:20:12):
We're going back in time.

Andrew Filev (00:20:15):
But the interesting point, again, and we're still on your first question, but going back to that one, is how. That one, I also, it's not just their common wisdom. I knew that the right decision was probably to kind of truly sell, but I just didn't want to do it. And I found my, I rationalized my way into like, Hey, I'll just like put it on the internet and have people kind of buy it with the credit card. And if it is great, that's awesome. And if it sucks, like it's, it's my bad. It's not, it's not their bad.

Pablo Srugo (00:20:45):
But it probably led you to invest more in product at least like as a good side of that.

Andrew Filev (00:20:49):
Exactly. And one lesson that I learned later in the business as I was scaling it, so there were times in life where you kind of overcompensate for product issues with other systems. For example, you can build an awesome onboarding vest in the world, right? Or you can build a very strong customer success organization. And so it's kind of interesting where There's no perfect answer, because more likely than not, this is what you have to do just because of how the world works. But in retrospect, if you're also like, maybe I should have been in the bullet and sort of like did that hard thing on their product architecture side that I was thinking, and maybe I should have done it more aggressively and earlier, if you will, right? So because you can. overcompensate. You can win based on product or you can win based on go-to-market or, you know, ideally you win on both, right? But I feel in the long run, winning based on product always kind of wins. Especially for founders, if you want to kind of keep your heart into the business and your passion, like a lot of us are builders. Not everybody, there are founders coming from all sorts of venues, but for the builder founders, if your passion is brought up like mine, I think you got to feed that passion through the years.

Pablo Srugo (00:22:08):
I think that's right. I mean, I think I think it really is an alignment piece. Like it's hard to say sales always beats product or vice versa. But but if you're going to have a horizontal product that a lot of people use every day, that probably gets adopted, bottoms up, then product is the only way, you know, to really do that versus some kind of. And the other the other thing, and this is something I got from Aydin was one of the investors, Felicis, you know, he did Canva, Notion, a bunch of these. And here's a mistake that I thought was interesting. You know, most VCs value sales and marketing a lot because that's typically what leads to growth. So it's like, I'm going to invest a bunch of money and like, how much sales and marketing are you going to do? Like, let's go. Right? And his thing was like, You know, like invest way more of that. Now, again, funded by his idea of these like Canva, Shopify, you know, Notion. So that's his point of view. I mean, these are products that obviously are about the products. They're just kind of they're bought almost in a self-serve manner for the most part. Invest in product because product is the asset. You know, the sales and marketing stuff you do today kind of goes away tomorrow. But the stuff you do in product to actually make it better is the thing that pays dividends longer. And so I could see that. And again, especially for these bottoms up type of solutions, like I think a lot of founders probably it's tough because you can fall in love with your product and do so much work there that leads to nowhere. So that's the balancing act. But there is a lot, probably too much emphasis on just let's just go to market with it. Right. And I don't know that longer term.

Andrew Filev (00:23:34):
I got the solution for falling in love. That's an easy one.

Pablo Srugo (00:23:38):
Okay, let's hear this.

Andrew Filev (00:23:39):
Part of being Bootstrap founder is that you're broken cheap and you got money for nothing.

Andrew Filev (00:23:44):
Right.

Andrew Filev (00:23:45):
So, I was manning our phone lines for quite a while. And that gets you back to the reality very quickly. And I think, It's well-funded venture companies. I don't think these days the guys are doing that, especially the Stanford PhDs and MIT PhDs and whatnot, but it's a good experience that grounds you very, very well.

Pablo Srugo (00:24:12):
You're saying mainly in terms of the having to sell, having to make money or just hearing from customers directly?

Andrew Filev (00:24:16):
Hearing from customers, yeah.

Pablo Srugo (00:24:17):
Got it, okay.

Andrew Filev (00:24:18):
And by the way, selling is not a bad thing to try either. Because if you're selling what customers don't need, very quickly we'll get frustrated. But managed support as well. And what it did for me, like I didn't have to think about product roadmap. I didn't have to even write my product roadmap anywhere. Because customers would tell me every single day about the things that matter. Versus, you know, if they told me like once to the blue moon, then through very Darwinistic natural selection, those things, I would not, you know, my mind could not keep up for real, like over like 5,000 things. So naturally I would kind of focus my product efforts and our team's engineering efforts on the things that were top of mind. And again, as I was mentioning the phone lines, they were the things that were most important for our customers.

Pablo Srugo (00:25:07):
And was it just you, by the way, or did you form a team like at the outset?

Andrew Filev (00:25:11):
It was a team, yeah. It was a team. A lot of technical work was not mine. So I have not committed a lot of code there either. So I still, up until this day, I'm very deep, definitely, when it comes to things like architecture. Because a lot of it goes back and forth with product. And so I don't feel an isolated design, like, OK, let's design our product spec, and let's design our architecture spec. Sometimes it might be possible. If your architecture is completely trivial, but if so, then why didn't everybody else do it? So for example, at Zen Corner, and we'll talk more about it soon, but there's a lot of architectural decisions around how you build an agent and how you deploy them in remote versus local and how do you manage state and how does it work for zero data retention or for the customer environment that's behind the firewall and so on and so forth. So there are tons of architecture decisions that then start impacting product decisions. Like, hey, does this thing work on my mobile phone? Or does it require a laptop? And so on and so forth. Can I run a bunch of them in parallel? Can one of them call another one? So a lot of those things that are kind of product decisions, they do interplay with architecture. And another thing that also interplays with both is timing because the value of something that you ship three years from now is very, very different from the value of something that you can ship in the next three weeks. So, I'd say velocity, kind of a different topic, right? But velocity, I feel, is one of the most important things in general for the startups. And that was too long ago. So even my first ever company, I literally, I kid you not, I printed the words velocity, velocity, velocity on a cheesy page and like stuck it on the wall, right?

Pablo Srugo (00:27:04):
Is this velocity of what? Everything or just a velocity of product? Like develop, like putting features out or?

Andrew Filev (00:27:10):
Kind of everything. But again, as we discussed for me and for a lot of companies, product is at the core of it. So when I say that, I probably most likely not think about product. But as the business gets bigger, go-to-market is also important, right? Like you came up with a new product and your go-to-market team drags their feet and cannot properly articulate the messaging and sell it over eight months. Man, that's getting frustrating very quickly. So, but again, in early stage business, if technical business or many other business product matters a lot, so it comes down to the velocity frog. And now in AI world, that's like 10x. Because I kid you not, like in my space, it's like you blink, you miss something. So you got to be on your tiptoes and move very, very, very fast. And with coding agents, a lot of IP gets commoditized very quickly. So it either propagates to your competitors or propagates to open source. And so the way for you to keep that advantage is ultimately keep creating. And we had this conversation internally in our team where we discussed how, because we've got some very, very interesting IP components. We've got an applied research lab that constantly innovates and pushes the state of the art forward. And we're like, should we put the extra effort into protecting that? But that overcomplicates architecture a little bit, right? Or do our project with the assumption that somebody is going to look it up or independently come up with something like that anyways. And so the time for them to do it is going to be about the same anyway. So I like they're going to do it three months later, no matter what we do, then maybe we keep it simple and just move faster and just kind of focus everything on that on that speed and bringing value to our customers.

Pablo Srugo (00:29:01):
You mentioned a few like competition, which is a topic I want to touch on when it comes to Wrike, like Trello, Jira, Santa. Like when did these kind of come up into the picture and how did that how did that play out?

Andrew Filev (00:29:11):
I feel well-prepared for my today's category because project management was one of the most competitive categories before this one. So when I started the business, it was extremely competitive. You had the big, big guy, right? Microsoft with Microsoft Project. You had the heap company, Basecamp. 

Andrew Filev (00:20:29):
Yes.

Andrew Filev (00:20:29):
Back then, everybody even talked about Basecamp. And then you got a bunch of like, you had a hundred copycats from Basecamp. It's kind of funny, like people sometimes ask me like, hey, why isn't your product like Basecamp? And I'm like, Don't you already have like 100 copies of that?

Pablo Srugo (00:29:45):
Why would I do 100 first?

Andrew Filev (00:29:46):
If you want Basecamp, go and buy Basecamp. It's an awesome product for what it does, right? But I do different things, solve different problems. So anyways, very competitive space. Jira was there. before, but it was not there in the sense that Jira originally built product for BuckTrack. And from day one, their focus was on engineering audience. And from day one, I made deliberate focus on business audience in that product. And that meant significantly sleeker UI. That meant some other kind of interesting concepts. So basically, very, very rarely in our account, customers had Jira. And when our customers, our ICP, were forced to use Jira, they were very unhappy. So one of our very common frequent customers were marketing teams, and they did not appreciate if somebody asked them to use Jira.

Pablo Srugo (00:30:45):
I can appreciate that, yes.

Andrew Filev (00:30:46):
They hired fans of our product. By the way, Jira is an awesome product, right? So for engineering at our team, Today we do use JIRA. So love Atlas and love the product. I'm just saying, again, each tool for its own

Andrew Filev (00:31:01):
Different use case.

Andrew Filev (00:31:02):
Use case. But then what happened, so in terms of our category, Collaborative Work Management, Smartsheet was a competitor and we kind of co-created that category. And then Asana came in late and produced a very similar product. And to ours, and that was interesting, because on one hand, you're kind of like frustrated, right? Like, hey, I've been there, done that, like, why are you coming and doing exactly what I'm doing? But on the other hand, that helped establish credibility for the category. Because if you're the only one saying like, hey, this is how we're supposed to do things, people are like, eh, whatevs. And as opposed to if there are multiple competitors, especially if some of them come with like, big pedigree and media love and, you know, some of the background, then suddenly people are paying attention and that gives you validation. And so if you've got a better product, you can actually turn it to your advantage. Yes.

Pablo Srugo (00:32:00):
Actually, question on that. That makes a lot of sense to me. But if before that, these customers, they're doing what? Like, what are they? Are they just not using collaboration software or are they using the old stuff? Like what? What are they doing?

Andrew Filev (00:32:14):
For us, it was typically Greenfield. The status quo was Greenfield. They would use spreadsheets sometimes, maybe Google Sheets, a bunch of sticks and random glue. We came and offered them a beautiful solution that worked really well and connected all the pieces. Yeah, and again, that's kind of essentially what I'm seeing today as well. Like it happens with every new category creation, right? You have this new way of doing things. And I've seen this in Mira as well. I was a tiny little part of their early journey. I was early advisor there, early investor. And that's another category creating business where today, yeah, of course you use Mira, they got a bunch of competitors, right? But when they started, people just use MyBoard and kind of

Pablo Srugo (00:33:06):
Andrew is coming on the show soon, by the way, so I'll get the full story from him, which I'm looking forward to, because it's an awesome product.

Andrew Filev (00:33:14):
He's the man. He's the legend.

Pablo Srugo (00:33:16):
And so maybe just a couple of questions I'd reckon that we're going to jump all into this AI thing. Walk me just through the ramp. Ultimately, you got to well over 100 million ARR. It was a massive exit, but how long did it take to get to a million, to 10 million, rough numbers?

Andrew Filev (00:33:29):
I don't remember the exact numbers, but I can tell you that overnight success takes seven years to build. I learned it over and over again, including recently with other companies, like I was making AI, AI is hot, right? And so all this news about all these companies, and I see this new, so like we got to $40 million in like 45 days, you know, oh my God, like, what do those guys know that I don't? And so I started research and it turns out that they're like, they're geographically biased version of perplexity that raised like $200 million and built free product over the last two years. And then they decided to monetize it and then they're like, oh, we got to $40 million in 45 days. Duh, you know. You just dumped 200 million to build your user base and now you monetize it to the 40. So anyways, I do feel that a lot of overnight successes take some ramp to build. And that was our story.

Pablo Srugo (00:34:31):
But so it probably took a few years to get to a million, for example?

Andrew Filev (00:34:34):
More than a few, yeah. It took a while. Again, I don't remember the exact details, but definitely more than three years, maybe took five. But again, for quite a while, I was truly doubling the business every year. Literally, that was the definition of my job. If you ask me, like, hey, Andrew, what's your job? I would right away tell you, my job is to double the business every year. That was it. That was the only definition of my job, right? So I did that for quite a while. And again, once you got to millions, that becomes interesting because it's easy to double the business with 100k ARR. It's not so easy to double the business with 20k ARR. That was a great journey. And as we go deeper and deeper in the journey, unfortunately, I had to shift more and more of my operating to go to market, right, as we discussed. Unfortunately, because I'm a product guy, not unfortunate because of inherent things, unfortunately, just because of my personal passion. And I think it's important to kind of feed that passion here, here and there, right? So, but the bigger the business was, the more time I as a founder had to spend on go to market to keep that momentum going.

Pablo Srugo (00:35:47):
You love this show. You don't want to miss the next episode. Why would you? So hit that follow button. Trust me, it's in your own best interest. So, moving away from the history stuff. Which I know takes a lot of time, but I'm really interested in the history of Wrike. So, how? When does the idea for Zen coder come along? What's the Back Story?

Andrew Filev (00:36:05):
Well, I can give you the short and the much further down the timeline. So, my thesis back in school, two decades ago, I built the first, or at least one of the first, automated refactoring tool for the language called C Sharp. Which back then was a new language, and I had this tool working before Microsoft shipped theirs, before JetBrains shipped theirs. So there was at least some interest two decades ago in how we can automate their coding. And then I kind of forgot about that whole thing for a couple of decades, because as we said, as we discussed with Wrike, I deliberately picked the business users as the audience, and you got to stick to your ICP to develop good products. But that passion for developer productivity always was there. And then where put the fuel and more and more fuel over the years there was my kind of product heart. Because most of the ideas that I came up with, they were never implemented. We started this conversation, right? I remember I said like, hey, a couple of ideas a day. Like even when I had several hundred people in my engineering organization, most of the ideas that I had either were not implemented or it took years to implement. And you combine that with the fact that I believe that velocity is the single most important thing for a company. 

Pablo Srugo (00:37:28):
Right, and you love product, it's like oh my god. 

Andrew Filev (00:37:30):
You can see how frustrating that could feel, right? And then when Transformers came out on big speed, it was obvious to me that a big chunk of that work could be automated. So my previous business, we had 30,000 automated tests. Yeah, writing the first one and creating the framework is probably highly intellectual labor. Creating 30,000 first one or modifying their 20,000th one to keep up with the other changes. Is not that impossible of a work to imagine that transformers could do that, right? So it was obvious to me that again, big chunks of that could be automated. Also, I have the benefit of having an actual experience of running large software organizations. So I knew where the bottlenecks were. So for example, like everybody else in the space, we started with building the agents for coding, right? And we'll talk about how the stages work and like why they're the best and whatever. But from day one, at the same time, I had a vision to cover the whole as DLC. Because coding is extremely important and intellectually engaging, but it's not necessarily your bottleneck and your release velocity. So at a lot of companies, for example, what happens is you build some code and then you commit it to repository. And then you kind of throw it over the wall to QA and QA doesn't pick it up immediately. They're busy with their own stuff. So by the time they pick it up, you already moved on to something else and they find some issue with your code. Like they turn it back to you. Now you've got to either finish the other thing that you're working or drop it. And that's like very expensive context switching. And then you kind of finish it and maybe you're lucky this time and it goes through. So that is the biggest drag on their release velocity, all those kind of steps that it needs to go through. Or even the simplest one, a lot of organizations, others including, they require engineers to pass code review by other engineers, right? So kind of that second opinion, if you will. And if you can pull some of those processes earlier, the QA, the code review, in engineering language, it's called shift left. Left, right, but the left mean kind of earlier in that work, right? If you can pull some of that stuff earlier, either automatically or at least giving developers the chance to do it, then what happens at least is that you can capture some issues early. And because of that, that increases the chances of passing it the first time. And that's incredibly important for velocity. But if you're lucky and your agent's awesome, then theoretically, eventually, you can even remove that manual step and suddenly, instead of it taking a week, it's an instant process. And I feel it's not a binary decision, it's more like building towards that. Can we build agents that first do a good enough job of at least identifying some of that stuff? And then, eventually, could they be good enough that we can trust them, that they test our solution well, that they review our solution well? So that was part of their easiest from day one. Like, we're going to build the best-in-class coordinate agents, but we're also going to build best-in-class.

Pablo Srugo (00:40:47):
And when was this, by the way?

Andrew Filev (00:40:49):
It was. I started the business in, what is it, 23. Yeah.

Pablo Srugo (00:40:53):
So right after the ChatGPT moment sort of thing?

Andrew Filev (00:40:57):
Yeah, exactly. That was the big moment for everybody else. And the timing was right because that's the year when I left Wrike, so I was like, oh my god, I can do multiple things that I love doing at the same time. And there was this inherent long-time passion over AI as well. My introduction to Agents was a decade ago where I had a small hobby team competing in DARPA Robotics Challenge. We were trying to kind of build semi-autonomous humanoid robots. We failed, but it was kind of fun learning experience, kind of early exploration. So their AI chops and interest and understanding of deep learning, computer vision, and NLP was there. And then the timing was there, and then the passion for the industry was there. And then I saw also some very interesting opportunities because right now, everybody's building engines. Back then, everybody was buying GPU and trying to compete with Anthropic and OpenAI. And I felt that this is not the right place to start, because they already have models that they're constantly improving, but there's so much work to do on top of those models. That is not even fun. And especially when we started with GPT-4, it needed so much scaffolding. So we built code parsers that could identify the errors, and we built special models that could apply the patches, and we built special other models that could find the right code to give to the model, and so on and so forth. And sometimes you ask one question and it literally blasts like 100 little LLMs to help with that stuff. So there was a lot of that work that went into taking that compute block of transformer and turning it into the actual agent that can do the work. And that was the differentiating part. And then the other differentiation, as we discussed, was that focus on complete life cycle. And even today, when the models are much better, I still believe that the QA part is underdeveloped in the market. Because if we're claiming that there's going to be 10 times more code written by AI than humans, then how is that code going to be tested? So For us, it's our one-two combo, like we want to build the best-in-class coding agents and we want to build the best-in-class agents that check that code, verify that code. And we feel that one feeds the other, especially when they get good enough to run autonomously, because then you can blast like 50 instances of coding agent and then just pick the best one, right? Or you can iterate like 10 times. Again, it's not going to always succeed, but at least you're moving the frontier forward

Pablo Srugo (00:43:34):
But do the other ones like Copilot, Cloud, Cursor, whatever, do they review your code as well? Or do they not play in QA as much?

Andrew Filev (00:43:40):
Well, it's a very dynamic space, right? So it's always moving targets. So I can tell you, when we started in the first three months, we already built a product that worked much better than everybody else in the market back then. And measured by, like you simply try, does the code compile or not compile, which is the basic check. I'm not saying it was awesome code that did everything for you, but I'm saying, can it even compile, right? And we had like three times better rate than some providers and infinitely better rates than some other providers whose code didn't compile in any of our tests. So now the world is different. Of course, that bar has moved significantly. And we're moving with it. And again, for example, as far as I know, like, you know, Cursor, Copilot, they don't offer you, in addition to Coordination, they don't offer you like the Specialized Unit Testing Agent, M2M Testing Agent, whatnot. We have our product, unlike Cursor, you can kind of drop us in your CICD. So for example, at our own company, we have a review agent that runs, as we discussed, on every code that an engineer submits. We have that code review agent. We're right now internally also trying to deploy automatic, that end-to-end testing agent. So that would automatically kind of generate that. So a lot of that, it's a game of velocity where that baseline moves up every month, but we're staying ahead of it and coming up with more features. And I feel that the category, despite all the hype and all the effort, is still significantly underdeveloped by us or anybody else. Meaning, for example, collaborative features, which was my bread and butter, at Wrike, they're not there, simply. And that's not necessarily a bad thing, just because there's so much gain you can get on individual productivity, that industry just hasn't yet moved to that team productivity. But it will, absolutely. And it's kind of repeating the journey of overall software that took like 20 years, we're just now compacting it in two years, where, again, first there was desktop Excel, and then there was Google Sheets, right? So it wasn't there the other way around, like you first need to unlock individual productivity, and then you build a more sophisticated collaborative cloud solution. So I feel the same goes for the agents, like you first unlock that individual productivity, but then Nobody works as individual, we work as teams, and so now you have to come up with some interesting technical solutions and UI paradigms, like how could you collaborate between humans and AI. And then also to the point we discussed about verification, like those agents are imperfect, so how could you potentially orchestrate multiple different agents to improve the quality of your work? How can you break down the work in little pieces and have agents execute those little pieces with the right context? Because one of the big problems with agents is that it's super easy to overflow their context. Anybody who's done AI engineering for real knows that one of your, as human, one of your secret weapons, one of your biggest value that you can add is you have the right context. Context doesn't equal small MD file. You have your life context, your industry context, your product context, your project context, all your mistakes, all your successes, and that's worth a lot. And you're ultimately becoming that director or conductor of that orchestra. And you're telling the agents, look here and look there. You cannot, unfortunately, you cannot just dump everything at them and let them figure it out. That promise has not. 

Pablo Srugo (00:47:16):
Because that's what I was going to ask you. You're thinking on, you know, there's like the co-pilot positioning, then there's like the, I believe, Christian, I'm not an engineer, so I don't use these proxies, but that will just do everything for you. There's different positioning on the kind of augment versus replace. Where do you see human developers? Are there less of them in the future? Are there more? What roles do they play, do you think?

Andrew Filev (00:47:36):
I think it's going to be both. You know, like with photography, everybody is a photographer today, right? But you still have professional photographers. And on top of that, you have artists, which is a completely different level, right? And so I feel the same is going to stay true with coding. I think everybody will be able to create applications. And there are amazing things that you can vibe code today and a lot of people do. Then there's going to be professional engineers and they will work on more complex products because if you ever try vibe coding, you're going to hit the wall. If you never touch the code and just rely on agents, at some point, you're not going to be able to go forward unless you're a professional engineer who can unblock the agents and then kind of direct them in the right way. So there's still that massive job for engineers. And again, with AI, what AI is going to do is going to democratize the process of creation software. So there's going to be more software created, which essentially means that the job of that professional engineer will shift. but it will not necessarily become easier or harder. It's like now again, now the harder part, the easier part is now you don't necessarily need to know Go and Rust and Kotlin and JavaScript and this and that in like deep level of detail. That's the agent's job. So that's going to be easier, right? But what's going to be harder is that, hey, I got to put this all together, like going to make sure it all doesn't fall apart, right? So think about architecture, think about user experience, think about testing strategy, because if my agent is not doing a good enough job, then it will not see the mistakes, and so it cannot self-correct if it's blind. So the job of the pro engineer will shift, and they're going to have to deal with much bigger and more massive amounts of code, they're going to deal more with specifications, if you will, that will allow agents to better manage context and so on. And then there's always going to be artists, the people who invent the stuff, right? Those are going to be people who write agents, operating system or containers, because this whole stuff is still going to run somewhere, right? And so there's still going to be system programming and AI ML work and whatnot on top of their regular full stack engineering.

Pablo Srugo (00:50:02):
And then what do you think Cursor, like what do you think led to the incredible adoption of Cursor over the last couple of years in your opinion?

Andrew Filev (00:50:10):
So it's one of those, again, it's not, it's not seven years, right. But, but it is several, it's several years before Reunited's success. So we, we knew about them way, way before kind of their, the big market jump. And I think. Kind of comparing them to us, right? So they did have a couple of years of early start. Now we, at this point, I feel we not only caught up, but in many areas kind of moved much further, specifically when it comes to kind of professional engineer, enterprise code basis, corporate customers, where there's some technologies that we support much better, like Java developers and whatnot. But the reason for their success is kind of interesting. I've made a lot of right bets, but there's some bets that I made where our advances actually played against us. So, we and Windsurf as well, Codium back then, We invested a lot in building very robust and unique IP around finding the best information possible for those coordinating agents. Versus Cursor did not have that. And instead, so with Cursor it was like much simpler. You just like point the agent to the file manually. but they focused on some other things, like some UI things and this and that. And then Sonnet came out last year and it turned out to do by itself a good enough job at finding some of that information. And for us, we were still investing in that stack, which made us move slower to unlock the best features of the new stack. And as we discussed, velocity is that component. So it took us a couple of months to kind of change that. And that couple of months meant everything in the AI world kind of from that hype and penetration. So today you can actually, there's tons of customers who use us and like, oh my God, like Zen Quarter did for me in like 10 minutes where cursor has been kind of running in circles for hours. So we got a lot of that sentiment, right? But there's also the reality that their big brand in the market. And so we now need to build our brand and so on. And again, the way I'm thinking about it is we just focus more on you use that expertise in sort of real world engineering in understanding of that complete software development lifecycle and kind of better support for the full process again. better support for quality, better support for your CICD, for that collaborative capabilities as well, where you can create custom agents, share them in the organization. So there are a lot of things that we today do better. And then again, hopefully the fact that we were able to kind of intersect that trajectory tells you that, hey, we're moving faster and could outrun them in the long run. And then again, the coin is also flipped because if I told you that, hey, some of the decisions we made, we kind of cost us a couple of months, but the opposite is also true where right now we can make the decisions as we rebuild our platform, we made some decisions that will make us run faster right now, right? As opposed to they have their own architectural choices that they made. That they got to live with. And again, for the second generation of agents that's in the market today, those choices worked well, but they're not going to be the best choices for the wave that's coming next. And that wave, every single next wave is 10 times bigger. So it all started with kind of cold completion. And everybody thought that that was big and then agents in IDE came out and that became at least 10 times bigger and there's a wave coming with kind of more autonomous agents that's going to be another 10x bigger and so we want to ride that.

Pablo Srugo (00:54:14):
What's the difference actually if you don't mind going deeper on that between the autonomous AI agents and the current agents?

Andrew Filev (00:54:19):
So the differences, the primary one is capability and quality, right? And they're sort of getting to the level where you can trust execution either directly or what's going to be more important, you're able to orchestrate pipelines or regions. So hey, this agent is going to design the spec, and this agent is going to break it down into these pieces, and this agent is going to execute the piece, and that agent is going to check that piece. So that ability, either on the user interface level, or ideally later on their agentic layer, level to help with that orchestration. And then as that happening in parallel, being able to take some of those pieces and put it on kind of like auto trigger working in the background. So say you have a new ticket coming up, like new bug appearing in your sentry or whatever, like have trash agent try to understand if it's worth to like try to deploy AI for that. And then like it can like trigger that autonomous pipeline. And we today already have all the plumbing for that. So as I said, like for example, in our company, some of our customers, we have agents that automate code reviews, right? Or automate kind of adding the tasks to everything that happens in the pipeline. So we can already put those agents on triggers. And as we, develop them to be more powerful, you can kind of trust more and more of that to them autonomously. It is a journey. It's a journey for us. It's a journey for models. And it's also probably most importantly journey for the customers, because the customers are still discovering kind of what is the best way to use the agents and what is the best way to orchestrate them. And to some degree, they're in the same position as we are, where you blink, you miss, meaning they got to design it for today, but it's also gonna be better and slightly different tomorrow, right? But you cannot wait till then, because one, you'll be behind the train. And second, it takes time to build that skill and experience. It is a skill, and one metaphor that I recently used, Steph Curry, I'll relearn him, he's three-point shot. I think at high school, right? Where like you got to go backward a little bit to then kind of redefine the whole MBA, right? So a little bit of that is here as well. Like if you want to fully unlock the value of AI, you first need to kind of go through that learning journey, if you will. And in some cases, you got to smartly persist. Well, like if something doesn't work on the first try, instead of just doing it the old way, you might have to think about creative ways like how to still make it work in kind of AI-first way. But anyways, I think what's happening now is that we are in the world where by the end of this year for sure, and probably already today, there will be nice software products that are fully built in AI-first way. But it doesn't mean that there's no engineers, right? So they're going to be engineers and they're going to be some of the smartest engineers working on them, right? But I'm saying that, and they will review the code and maybe surgically correct it. But I'm saying most of the code will be written by the AI agents directed by those engineers. And when it happens, the parallel thing that's going to happen is that their competitors are going to lose in the market, right? Because again, this is, it's one of those things where, you know, one step backward, one step forward. Like, yeah, they got to go through that initial journey, but they're going to be so much faster after that. Like, even internally, there was literally two days conversation about some particular topic. And I'm like, Hey, we got to do this in their spec first way. Cause the question that you have right now, should it be this language or that language? There wouldn't be a question anyways, because then if it's done AI first, spec first, then we just, yeah, we would do it in this language. But if tomorrow you change the decision, it's super easy. I just click the button and suddenly it becomes a different language, right? And that was impossible before. I lived it in the past where we made some decision about our language and it wasn't the best decision and it was super hard. Can't reverse it, yeah. So good architecture still matters a lot from personal experience, from customer experience. Let me rephrase it, it matters even more. So it not only matters a lot, but it matters even more and that's a big chunk of it human. But even in good architecture, when I'm thinking about architecture, I'm running agents like one, two, three, five agents in parallel just answering my questions. So I'm in the driving seat, but there are a bunch of agents that are looking through my code base, trying to find me a solution, looking through open source comparable, finding a solution. or for the topics that I had no prior experience to, like, hey, I'm trying to understand what's the best implementation for gRPC or what is the fallback option if the firewall blocks it, right? Like something that I haven't personally touched. Instead of calling my guy or scheduling a whole, like scheduling a call, Zoom call in three days, right? I just like fire it off to agent that is gonna give me an awesome answer. And then later I can run it up through my peers to see if I'm hallucinating or if I'm hallucinating, or if I'm right. But the reality is, more often than not, it's not a hallucination anymore. Like a year ago, it was a hallucination. Today, I feel kind of empowered to produce good quality work. And I feel, to some degree, being superhuman. Not in comparison to any other human, but in comparison to myself. There's some things that I can do in Zen Quarter that I was not able to do in my previous company. I could not keep up with our code base. There was no way. At the later years of the company, I was either building the business, Or I would be focused on code. Because we had a lot of engineers, it moved so fast. And if I did one hour a day, then I would have to spend all that hour trying to catch up. As opposed to today, we have a very sizable engineering team, one of the largest in the space, about 50 people on the engineering side. And I can run an agent that will find me any information I need around my code base and build me nice diagrams and whatever and explain it to me. So that empowers me to do my job much better. And I feel that it also illustrates one of my key theses for AI, which is it relates to that context conversation which we had, which is the best career opportunities and the best impact on the world you'll be able to make by connecting different pieces, right? So that's the job of the conductor, that's their big context and your big brains, right? And that's the stuff we discussed, like I don't have to be an expert in Go or Rust, right? I have my agents for that. But I have something that they don't, is that my industry understanding, my customer understanding, my life's experiences. So I connect those pieces. And I can come from product perspective and use agents to augment my technical chops. Or vice versa, I could come from the technical chops and use agents to augment my product perspective. Right. But, but the key point there is that agents can, uh, make, can, can, can help you connect those dots. And, and that's the next level of the human job of the evolution of the white collar. If you will, right? So maybe that'd be a good point to wrap up.

Pablo Srugo (01:01:57):
Yeah, no, definitely. I think that's a good place to start. Stop it. Let me ask the last few questions that we always end on. The first one actually is, you know, tell me just a little bit about going back to Wrike for a second. Like it was sold twice, right? Is that right? Like Vista bought it and then it was resold. Is that more or less right?

Andrew Filev (01:02:15):
I forgot the right term we should use, majority investment. But yes, the reason I like to say majority investment is because for us it was like 100% continuity in vision, employees, commitment. Everything.  And I rolled a lot of my equity into the deal. I wasn't running away from it. I was running towards scaling the business further, right? So it wasn't like your traditional.

Pablo Srugo (01:02:43):
So that's helpful. What was, I guess my question is, you know, because a lot of, I mean, a lot of founders want to build a big business, but obviously there very often is an exit outcome, whether it's an IPO and you keep going or whether it's an exit, like you had, like, what did it feel like to have that, that finishing piece, right? In 2021, you sold the business. What was that like from a founder perspective?

Andrew Filev (01:03:01):
So when that 21, when we sold to Citrix, I think it's as usual in those moments, it's kind of a combination of feelings, right? On one hand, you feel excited about the deal and the opportunity, you feel grateful to life and employees that you got such a amazing moment. You feel proud of yourself and your team. You feel happy for people who made their life dream come true. If you haven't been there, don't underestimate it. It's such an amazing feeling where you give people options and then they get that exit moment and they can afford something that they dreamed of. Once you can afford what you can dream of, that's the best thing, right? Helping other people get to their dreams. So that was all great. There was also a lot of work. I knew that post-acquisition time is always tough for everybody. So I knew that it's going to be a rough ride for the year or two after. Just because it's like a lot of change and companies have human systems and humans generally don't like change. Yeah, so a mix, but definitely kind of a heavily positive, exciting mix, if you will.

Pablo Srugo (01:04:28):
And then tell me a bit, one of the questions you asked, when was the time when you felt like you had true product market fit? And that can be for Zen Quarter or for Wrike.

Andrew Filev (01:04:36):
For Zen Quarter, I felt that moment earlier this year when we launched on Product Hunt and got product number one. But more importantly, in the metrics, we did nothing and we had our conversions for X. And I say literally nothing. I have tons of go-to-market experience, but I paid zero attention to go-to-market deliberately, because I know that I'm only going to win here on the merits of the product. So I deliberately, like I'm in a bunker, like I'm building the best product. That's my job, number one, and then the only job I have, right? And so we're not doing a lot of things that otherwise I would do. And conversions still go up like 4%. Usage kind of shoots, I forgot the actual number, but like probably 10x, right? And so you're like, okay, all right. So now we're cooking, right? And by the way, a similar moment was in a little bit different shape and form, but it was in my previous business where I was lucky to have this guy working with me. He started in product marketing, but later for a period of time I had a product and he came to me and said, Andrew, Look at their metrics we see with our marketing audience. They have better conversions, they have better usage, they have better network retention, and they have better revenue per seat. So like every single metric is better. And so that was kind of an aha moment for us. Like, hey, we got to build a lot of towards that, that ICP. And to your point that we didn't think about it that way. But to your point, like that meant like a very, very good product market fit where. So it's a little bit different Zencoder versus them.Because then it was like a discovery, if you will. We had thesis around that audience. Right. But it was more like a discovery versus in Zencoder. It's more like I'm in a bunker, I'm building, I know that I'm going to When I know that I'm going to build the best product, it's just, and then at some point it's like, boom, and you're like, okay, all right.

Pablo Srugo (01:06:36):
There you go.

Andrew Filev (01:06:36):
Now, still waiting for a couple other nice inflection points, but it's good to get that first one under the belt.

Pablo Srugo (01:06:45):
And last question, what would you say with all your experience would be like one of your top pieces of advice for early stage founders specifically?

Andrew Filev (01:06:55):
Focus on people. Ultimately, business is about people. And I'm telling you as a guy who last week I was in the bunker with like 10 agents running in parallel to just focus on technology. But people is the most important thing. All the good stuff in your company comes from people like that. ICP conversation we just had, like one of our guys discovering it, right? The architecture decisions that people are going to make, product decisions. So all the good stuff you can usually trace to some decision that was made by somebody on the team and then all the bad stuff as well. Like you could have the most headaches probably from the folks one way or another.
So bring the right people, build the right culture and then your life is going to be easier and everybody's going to enjoy.

Pablo Srugo (01:07:39):
Right. Awesome. Well, Andrew, thanks so much for coming on the show, man. It's been great.

Andrew Filev (01:07:42):
Thank you.

Pablo Srugo (01:07:43):
So guess what? I met this founder who listened to every single episode of the Product Market Fit Show. He just called me and he sold his company for over a billion dollars. That's right. If you listen to every episode of the Product Market Fit Show, that's what's going to happen. I can't say it's guaranteed, but It's what I've seen. It's just, it's what I've seen in the past, but you won't know for sure unless you, you know, try it out for yourself. So go back cause there's over a hundred episodes of the product market fit show and you haven't listened to most of them. Check them out.