He launched a free product for enterprise customers—then grew to $12M ARR in 2 years. | Bhaskar Sunkara, Co-Founder of AppDynamics

Bhaskar Sunkara (00:00:00) :
Let's just say take Amazon through a fifteen year journey. When they started off, they had some architecture, they're measuring that, they're measuring some database queries and stuff like that. Take that forward fifteen years, the whole architecture will be completely different, the application will be completely different. But what is consistent is people are logging in, people are adding items to cart, people are checking out, right? So that's where we came up with this unit of monitoring called business transactions. We were like, let's not sell to developers because they will give you the most feedback, right? I mean, if you go talk to them about features, et cetera, et cetera. They will give you the most feedback. But for us, the buyer was the obsolete.

Pablo Srugo (00:00:36) :
When did you feel you'd found true product market fit?

Bhaskar Sunkara (00:00:39) :
Once the product out of the box started working. Once people who were very happy with us deployed on one application were like, hey, can we get this onto some of our other applications? Once people who were at a company where they were using AppD left their job and went somewhere else, and said, hey, can we get AppD into this company? Those are probably some of the signs that I would think about. I think, you know, we have something, we have the fit.

Previous Guests (00:01:04) :
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:01:16) :
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. Bhaskar, welcome to the show, man.

Bhaskar Sunkara (00:01:32) :
Thanks, Pablo. Thanks for having me.

Pablo Srugo (00:01:33) :
So you're one of the founders of AppDynamics, a company that was acquired. I guess, in the late 2010s for nearly $4 billion. So a massive, massive company started in the late 2000s, if I have that right and then since then, you've gone on to start Bicycle AI. Which is the company you're working on now and have been working on for the last few years. So we'll definitely talk about the new company. We'll talk a lot about AppDynamics because that's obviously a well-known name. So maybe let's go back to that time, right? As a starting point, if we're talking mid-late 2000. What was going on in your world? How do you end up kind of becoming part of AppDynamics?

Bhaskar Sunkara (00:02:11) :
Yeah, absolutely. So AppD was started in 2008, by Jyoti Bansal. Who everybody knows, sort of like a multi-unicorn founder. So Jyoti and I were working together at a company called, Wily Technology. This was in South San Francisco, Brisbane and they were at that time the leaders in application performance monitoring. If you go back to about 2005, 2006, what's really happening is more of software is basically running business, right? And Java was one of the predominant sort of ways you would build an application. And what they would do is instrument Java application. And when I say instrument, really add probes into the code that is actually executing in Java. And use that to sort of really monitor the application to tell you, hey, is it healthy? How is it sort of with respect to how it has been doing? Set up dashboards around it and things like that. So Jyoti and I were both at Wily. And in 2008, when Jyoti started AppDynamics, I was the first one he brought on. We were friends, so in a way, we really disrupted the category that was application performance monitoring. You know, which Wily was really good at and the way we were thinking about it is applications just around 2007-2008, were getting super distributed. Initially, you would have a few servers running the application and then as you started going into 2008, 2009, applications were getting really, really distributed. And so the way monitoring was done wasn't working anymore. So typically, the way monitoring was done was you started with CPU, you would then say, hey, you know, how's my database doing? How are my queries? And then Wily was really good at basically monitoring your code, like here are my key methods, here's my code, here's my key methods. You tell me your key methods, I'll monitor them for you and I think one of the frustrations with sort of how the space was growing was everything was getting distributed. And also the rate of change was super high. So you would change your applications, you would change your code, you would change your database architectures, et cetera. And people had a hard time keeping up with how do you now track something new that I've added, and it was really hard to manage. So that was kind of the thing that we really anchored on and said, hey, look, this old way is not really working. You need a unit of monitoring. You need to approach monitoring in a little bit of a different way where it represents something that is constant. So take Amazon, right? Let's just say take Amazon through a fifteen year journey and, when they started off. Let's say they had some architecture, they're measuring that, they're measuring some database queries and stuff like that. Take that forward fifteen years, you know, the whole architecture will be completely different, the application will be completely different. But what is consistent is people are logging in, people are adding items to cart, people are checking out, right? So that's where we came up with this unit of monitoring called business transactions and that really gave it this anchor on, you know, with the change, with the architecture. It basically is a very, very manageable unit and that was kind of really the core thesis behind our bet. Does that make sense?

Pablo Srugo (00:05:12) :
You know, I'm non-technical. So maybe let's kind of, some of those examples were helpful but maybe just as a very basic question. When you're talking about monitoring and the old versus the new, you know, of AppD. Obviously there's so many different things you can monitor. What exactly are you talking about that you guys were focused on monitoring?

Bhaskar Sunkara (00:05:28) :
Yeah, yeah, so the old is basically saying, hey, my CPU is thirty percent, right? I'm writing a bunch of code. Here's a bunch of my methods and they're very, very specific to the company. And then you're like, yeah, this is running at twenty milliseconds, this is running at thirty milliseconds and then you're like, that's good, that's bad, or whatever that is, right? But that's a lot of noise and what we were saying is, when somebody logs in, it takes them x amount of time. When somebody checks out, it takes them x amount of time and what you're doing is you're basically looking at overall for the system saying in an hour there were one hundred thousand checkouts, let's say, and the average performance of those checkouts was x, right? So that gave a different way of looking at how you would look at monitoring and then also what was happening around that time was there was starting to be a specialization in people who would build apps, and people who would run apps, right? So there were the ops teams and they hadn't built apps, and you couldn't give them code constructs to say, hey, you know, monitor this because they hadn't written the code. But everybody in the company was very comfortable understanding that when people do a checkout, how much time does it take? It's as simple as that, right?

Pablo Srugo (00:06:40) :
And so you were tying performance to specific user actions, like, logging in or checking out, for example?

Bhaskar Sunkara (00:06:45) :
Yeah, I think user action is the right way to describe it and so we were basically tying to that. But the next step there was you tie it to that, and then you use that as the anchor to say, hey, are things good or bad, right? So some sort of detection of good state and bad state. But when we would detect that something's off, then we would almost start profiling individual transactions, right? So aggregate is basically saying, one hundred thousand checkouts, you know, what's the average, right? And you don't know the story of individual transactions. But when we detect a pattern, and we had really, really fine grained sensors running on every server. We would then start profiling transactions and basically get to the depth of looking at a slow transaction or a transaction that failed. And then would give you deeper profiling information, right? And typically something like that would only happen in dev or test scenarios. We brought that into production, saying if you do it safely, if you do it with the right heuristics. You can actually go down to that type of level and that's really what gave us the incredible momentum to, one, introduce the unit of business action, but two, really do deep dive diagnostics when you needed to.

Pablo Srugo (00:07:59) :
So going back to kind of the storyline. I mean, the first thing I want to ask about is, you're starting a company mid-2008. What was the impact of, let's say the financial crash and the financial recession or whatever on AppD? Did you guys feel it, or was it just kind of like that's going on over there and we're over here and they're kind of not that tied together?

Bhaskar Sunkara (00:08:16) :
No, I think I would say that at that time we were very passionate about the field, right? We spent about three years in Wily. We were very sort of deep into the space on what's happening with monitoring, where is it going next, and so something like that. And so we almost had tunnel vision on just focusing on the problem. We did kind of understand what was kind of really going on. But one of the things we talked about also was this is, if anything, helps sort of companies who are looking at costs, who are looking at. Because, you know, you cannot afford downtime because that's sort of loss of revenue and that's one of the reasons why we thought about, in terms of who we focus on. Wherever the application or software is more critical to running the business. That's what we wanted to focus on. Because you can't really afford to mess with it and that was a good sentiment during that time. In hindsight, that helped us really, really well and, you know, we did kind of think about that being an angle.

Pablo Srugo (00:09:08) :
And what types of companies were that? Was that an e-commerce company like an Amazon or?

Bhaskar Sunkara (00:09:12) :
Yeah, so in short, if you say, hey, you know, the software is most critical to running the business or software defined businesses. That could be somebody like a Netflix, who was one of our early customers. Because again, software runs everything, or somebody like Priceline, who was an early customer. So those are two good examples. So take retail, take travel, take subscription services that just depend on software. That was kind of our sweet spot.

Pablo Srugo (00:09:36) :
Tell me a bit about the beginning of that. I mean, it was a different area in terms of the venture capital world. But did you go out and kind of raise money right away? Did you build for a while? Did you do the classic, like, MVP? How did you guys kind of set things up at the outset?

Bhaskar Sunkara (00:09:51) :
Yeah, so I think when Jyoti started out, he did actually raise a first round pretty soon. So when both of us walked into our first office post, sort of Jyoti starting out in his garage, his apartment type of thing. We had sort of the Series A locked down at that time. So we raised pretty early just with the credibility Jyoti had and sort of everything else. So we started off with the Series A, you know, in the back.

Pablo Srugo (00:10:16) :
What was his background before? What had he done?

Bhaskar Sunkara (00:10:19) :
Yeah, he was pretty early at a number of companies. This was his first venture. He was super senior at what he was doing with Wily. He was sort of, you know, almost the chief architect in that level. So just with some of that credibility, I think he did a fantastic job in raising before we actually built out something really, really concrete.

Pablo Srugo (00:10:39) :
And how early did you join?

Bhaskar Sunkara (00:10:42) :
Pretty early. I think, you know, I was the first one he brought on and so before we had any basic sort of proof of concept, et cetera. And Jyoti and I were talking about this in terms of some of the passion in terms of how we want to address some of it while we were at Wily. But yeah, pretty early on, I think probably if we were founded about April of 08, I'd say May or June I joined.

Pablo Srugo (00:11:04) :
Do you remember more or less how much you guys raised that first round?

Bhaskar Sunkara (00:11:07) :
Yeah, yeah, yeah, yeah. So five and a half was the first round, basically.

Pablo Srugo (00:11:11) :
Which is a massive check back then.

Bhaskar Sunkara (00:11:13) :
Yeah, yeah, absolutely. From Greylock and Lightspeed. But yeah, that was a good check back then. Gave us the right kind of space and gave us the freedom to sort of do what we really wanted to do.

Pablo Srugo (00:11:25) :
How do you start something like this? You just go heads down, you build product for a while, do you kind of get an anchor customer that lets you do stuff on their environment?

Bhaskar Sunkara (00:11:33) :
Yeah, so I think a few things that we started thinking about in terms of execution, right? So number one, we wanted to find what's the first ICP and we were very sort of eager to go into the market and really start sort of deploying stuff. And our first ICP, when we thought about it was number one, look at distributed environments. Like I was saying, things getting more complex, and that's where we really wanted to differentiate. So that's one, second, we only wanted to build this for Java, right? So there's obviously multiple languages, things like Ruby on Rails and all of that type of stuff was also very popular back then. But we saw that the core of the enterprise, you know, we wanted to really go after enterprise, and that was basically Java, right? And so we said, let's only do Java. Let's not even think about any other language. Let's only do Java and win that first. And then very clear sort of persona in mind. So we were like, let's not sell to developers, because they will give you the most feedback, right? I mean, if you go talk to them about features, et cetera, et cetera, you know, they will give you the most feedback. But for us, the buyer was the ops lead.

Pablo Srugo (00:12:41) :
By the way, why is that the persona? Tell me, because that is critical, right? Figuring out who exactly you should be selling to within an organization. What was it about that ops leader? What KPI did they care about that made them the ideal buyer?

Bhaskar Sunkara (00:12:55) :
I mean, they cared the most about uptime. They cared the most about response time, right? They cared the most about availability and sort of error rate, and all of that type of stuff. And that is the core of running the business. If that's not working, nothing's basically working, and they're the ones tasked to basically do that. And so that's what really made us think in terms of talking to them or in terms of having them as the ICP. We did talk to a bunch of them, just asking them how their sort of, you know, day to day with monitoring is like, right? And the more we talked about it, one of the things that they were not so comfortable with is trying to manage a bunch of, technical constructs like queries, like code, and everything else. That they didn't really know how important they were or the context behind them and so from those conversations was born this sort of, business transactions concept. On once they said, yeah, you know, I understand checkout, I understand login, I understand add movies to queue or something like that.

Pablo Srugo (00:13:53) :
What were they used to seeing? They were used to seeing uptime as well, but what was the before, let's say?

Bhaskar Sunkara (00:13:58) :
Yeah, the before was, you know, what I described earlier, like CPU, code, queries. How the query is doing.

Pablo Srugo (00:14:05) :
Right.

Bhaskar Sunkara (00:14:06) :
And those were very deep constructs that they didn't really understand. And that used to change all the time. So it was really sort of working through something that they were not fully comfortable with versus something that resists the change, right? The business transaction was something that they're like, OK, you know, this is something constant versus I don't know what I have to do to keep up with all of this, now that I'm monitoring.

Pablo Srugo (00:14:26) :
Why was that the status quo? I mean, it's like many things. Once you describe the after, it's like, yeah, obviously that's how it should work, right? But why were things set up that way? Was there something technical that you guys had to figure out to set it up the new way?

Bhaskar Sunkara (00:14:38) :
Yeah, no, I think the monitoring part really comes from a very technical background, right? It comes from profiling, it comes from how devs used to measure how things work versus the link back to sort of the fact that the application is really serving the business, right? And as that started becoming more and more. It's the link between software and business, right? That became more apparent. That wasn't as obvious to some of the vendors at the time, and so they kept focusing on technical constructs, right? It's a good segue to think about packaging, in some sense, and how we packaged it, right? So if you look at everybody else at that time, they had multiple versions of the product, like one was in prod, one was in dev, one was in UAT, one was in test, things like that, right? And what used to happen was there used to be very similar features across all of those. Does that make sense to you? In terms of how the packaging was for other companies. What we said was, let's only do production. Let's not even bother to have a dev version. Let's not even bother to have, a test version, et cetera, et cetera. Let's only do production and there's only one cost. So if you want to run it in development, we can give you a developer mode that's sort of a profiling all the time type of thing. But you have to pay the same cost, right? And I think a lot of people think about packaging to be, you know, marketing or whatever but packaging is also focus, right? What do you focus on?

Pablo Srugo (00:16:07) :
What drove that, by the way? You'd think uptime only matters in production. That would be my simple way of thinking about it, but why not?

Bhaskar Sunkara (00:16:14) :
Yeah, you know, when you think about performance. So if you step out of uptime, if you think about performance. If you think about, profiling an application and making it better.

Pablo Srugo (00:16:22) :
Right.

Bhaskar Sunkara (00:16:23) :
That's more of a lifecycle construct than only thinking about production. So if you can think, oh, I'm going to improve this performance when I'm testing it out and everything else. Then it becomes a lifecycle play. But for a startup, when you're going in, you can't come up with this four product suite that has all the features sort of really distributed in different stages, right? So we said, let's just do that. Let's go to market in about a year or so, we'll have this product ready and so it meant focus for us. And it also meant that's where the budget was. Because who knows what happens when you go into dev and test environments, based on who's going to buy, are they going to buy? The other thing to think about is, a development license, you could do it per seat, et cetera. But a production license is based on how big your environment is. How many servers are you running and things like that. So that's another reason why we kind of really anchored on that. But that was the starting point of packaging, where we're like, okay, let's only do production. If you want to run it in anything else, you'll have to pay the same price.

Pablo Srugo (00:17:25) :
Was that strictly to help you guys focus, or did that also help you sell by simplifying the offering?

Bhaskar Sunkara (00:17:33) :
It did, you know, also because it only gave us the core persona of the ops leader. It was much easier building features around them. It was much easier. So I'll give you another example, right? So JVMs are very notorious. Well, not just JVMs, right? Generally speaking, memory leaks are an issue that can happen in applications. Because every application, you know, manages memory. So one of the feature decisions we had to make was we used to get a lot of, noise from developers on, hey, I'm trying to fix a memory leak and I'm having this particular issue, et cetera, et cetera. But a memory leak is a very sort of, like, you can run a product, you can run a tool, a solution on a particular JVM, like one server and diagnose whether there's a memory leak there, and why it's happening, and things like that. But it's not a distributed construct. It's not sort of something that's more complex, which is like, I don't really know where the slowness is because I have twenty servers, I have fifty servers, I have one hundred servers and they're all very distributed. It's hopping from one server to the other, and I'm having a hard time figuring out where the issue is. So that's a much harder issue and, you know, it kind of makes it easier for you to make a case on the ROI. Because it's just much harder versus you build a memory leak feature and go very deep into it. You can just run it on one server and once it's done, you can take it on to another place, and you can literally buy one seat for it, and you're done, right? So we looked at what is sort of a distributed problem versus what is an isolated problem, and let's focus on the distributed problem. Because that's what lends us to say we're building more value because doing that, especially when there is downtime actively going on, is much harder.

Pablo Srugo (00:19:16) :
How did you set up the first build? Did you work with a customer? Because you have to get, this is one of the things when you're kind of working in an existing market. I mean, you've got to get to that feature parity before you get to, you know, above kind of whatever exists today. So how do you get there?

Bhaskar Sunkara (00:19:32) :
Yeah, I mean, to start with, we actually started figuring out which of our friends had test applications or whatever running on their laptops, or wherever they were working on. Because what we had built was an agent. I mean, not like an AI agent but an agent that was instrumenting applications and so we were looking at friendly apps wherever we could get. But then, you know, slowly we started finding the early set of customers who were very keen on having sort of more and more smarter sort of production monitoring. And Netflix was actually one of the early ones. Priceline actually was one of the early ones. You know, Williams-Sonoma was one of the early ones and once we started figuring out that they had real pain with, what they were doing and they needed to sort of get on top of it. We started working with them. But we had a pretty good thesis on what the initial MVP was, but we had the MVP, and then we refined that a little bit. And we worked with them to make sure that it's kind of running pretty solid in their environments. So those were a few of the names that we worked with, but we did have an initial thesis.

Pablo Srugo (00:20:37) :
How did you get like, whether it's Netflix or Priceline. One of these large enterprises that you got really early on, tell me that story.

Bhaskar Sunkara (00:20:44) :
Yeah, yeah, absolutely. So we had a team that was really calling into them. Mainly LinkedIn, pretty guerrilla in some sense and so a lot of it was just really having the clear value prop. And then to finding out the fact that, hey, we're targeting the ops people. We targeted sort of that ops persona and clearly they had a lot of pain. And so it was actually a pretty quick hit.

Pablo Srugo (00:21:06) :
I'm going to ask you for a small favor, a tiny little favor. In fact, it's not even. Now that I think about it, it's not even really a favor for me. I'm actually trying to help you do a favor for you. Just hit the follow button. You won't miss out on the next episode. You'll see everything that we release. If you don't want to listen to an episode, you just skip it. But at least you don't miss out. And by the way, the ops persona is like, what role is that exactly? What's the title of that role?

Bhaskar Sunkara (00:21:30) :
Yeah, let's just say VP of Ops, right? This was before, everything became DevOps. So think of it as IT Ops, right? IT Ops was traditionally what the department was and, it was like a head of Ops or something like that. A lot of times head of engineering also kind of runs Ops and they're also focused on, hey, you know, how do I do the uptime thing? How do I do the availability thing? But a lot of times it was basically just head of Ops and so you hit that persona. And that's how we got some of the early engagement, some of the early engagement going.

Pablo Srugo (00:22:02) :
How do you communicate? Do you have a sense of how you communicate that value prop at that time? You know, the whole thing is you're transitioning from, hey, you don't really understand your analytics to you're going to understand what this means and, I could see how once you see it. It would be a stark difference. But when you're going out cold to a large enterprise, how are you messaging this?

Bhaskar Sunkara (00:22:21) :
Yeah, no, I think the concept of sort of using a business transaction and, you know, really anchoring around that made it much easier. Where you're like, what are you tracking, right? If you're tracking twenty things, and those twenty things are changing all the time. Which is what used to happen, that was kind of an easier way for us to get through the message. The other thing that really also happened was the agents which were living in your application. So the agents are actually living in your application inside Javan and so how reliable they are, the quality of them was also super important because you're basically running in the application's memory. Does that make sense? You're actually sharing memory with the application that's running and so if you add sort of memory. If you add any overhead, you're actually making it worse when there are performance problems, right? And so existing solutions also had some issues with that. Where sometimes it would crash, sometimes it would actually add latency and we put a lot of thought into how do you make an agent that literally kind of like the performance, and the overhead part of it was a huge deal. So you take those two things, right? Number one, you know, what do you monitor? The whole business and transaction concept, which appealed to the VP of Ops much more than working with, queries and code, right? So that's number one and second, it was the overhead part of it on. Look, I mean, you barely add one to two percent and you can try this out. And the third thing we said, which was, I think, surprising to a lot of people. Is that, why don't we do a POC in production, right? That was the biggest thing that I would say got people to take notice. Because they're like, they're this sure of what they built. We had nothing to lose, right? So we said, why don't we just say, you know, do a production POC?

Pablo Srugo (00:24:04) :
That's a good segue. How do you structure that? Do you just run alongside their existing analytics, and so now they have both views?

Bhaskar Sunkara (00:24:09) :
Typically what would happen is they would have to take that out and then put our solution in. You know, it's very tricky for two agents to coexist. Because then both agents are messing with the code that's being deployed, and that becomes very tricky.

Pablo Srugo (00:24:21) :
And so how do you scope that out? Because that's a big risk for them if the PLC doesn't go well. If you don't, you know what I mean?

Bhaskar Sunkara (00:24:27) :
Yeah, absolutely and what we said was start small, take a part of the application, see what visibility you get. See how much time does it take for us to get up and running. And with the other tools, the experience that they had was basically, you know, it took a really long time for them to get up and running. They used to get professional services in, they used to get, like, spend all of this time before they went live. So they saw this opportunity of, hey, there's this solution which basically says, do like a POC production. They're that sure of the overhead, they're that sure of, not crashing the app or doing something. So it's a risk we took, right?

Pablo Srugo (00:25:04) :
But for them, they would just put you on a specific part of the app. That maybe isn't the least critical part, let's say, and just see how you monitor that.

Bhaskar Sunkara (00:25:11) :
Yeah, and most people actually put us on to, a pretty reasonably critical ones. Just because, again, when you have pain, you can do that and also, by the way, our credibility at Wily really helped.

Pablo Srugo (00:25:20) :
Right.

Bhaskar Sunkara (00:25:21) :
Because we had spent multiple years at Wily doing this thing. So we were not building this for the first time. We understood agents and we understood sort of what that space was, and what needs to be done. So I think that really helped. But if you think about Netflix, they put us on to their main application. So this was when Netflix was not even on AWS, right? They were running in their own data center. They had about one hundred plus servers, and they put us on to one of those. And in fact, one of the tests they did was basically looking at the CPU, looking at the performance of a server that did not have, you know, AppD, and looking at one that had AppD. And literally you couldn't tell which one was which. Which is the win, right? Because you're like, you're an agent, you're tracking, you're monitoring, but it's almost like you're not there.

Pablo Srugo (00:26:09) :
And then the ROI, how did they measure that? Because it's a visibility ROI, but is it measured on just, oh, I'm like, wow, I'm getting stuff I never knew, and so therefore I'll pay you? Or is it more, because I have this, now I can act on it, and now my performance is higher than it would have been? How did they think about, you know, paying what I assume are pretty big contracts or something like this?

Bhaskar Sunkara (00:26:29) :
Yeah, absolutely. See, visibility, I would break it into two parts, right? One is monitoring, which is first of all, you are monitoring a construct that you're understanding with business transactions. So that was different from what they were doing. But the second part of it is the diagnostics visibility, right? Which is, without them having to do anything. If they're automatically saying, hey, I noticed that, you know, logins or checkouts are slowing down at a particular time. Especially with respect to the seasonality, right? Seasonality is super important, and we brought seasonality into it. Which is we used to call it dynamic baselining, which is kind of ML during that time, right? And what that used to do was, what is login performance like on a Monday morning at ten a.m., eleven a.m., twelve noon, et cetera. And so since we brought in all those constructs, it would measure it and would come up with like, hey, this is good, this is sort of off. But when it's off, the second part of the visibility is the diagnostics visibility. Which is a deep dive into what's really happening. Take an example of a particular transaction and show them why is it slow. This piece of code is slow. This query is basically slow. You're making too many calls across servers and that's the visibility that they really cared about because without turning off the application and without sort of, you know, doing something on the side. Your production tool is telling you what you need to fix in production and that was sort of, you know, worth everything to them.

Pablo Srugo (00:27:51) :
And how big were the ACVs early on?

Bhaskar Sunkara (00:27:54) :
Yeah, I think in the beginning, we were in the fifty to one hundred type of range because we wanted velocity. You know, we did some twenty fives also in the beginning, but we wanted velocity. We wanted, really quick sales cycles because what we really thought of was, how quickly can we do a POC? And in the beginning, we did a lot of single-day POCs, which was just unheard of in application monitoring at that time. And there's some stories in terms of, more tactics and specificity in how we approached the POCs, how we aligned that with the roadmap, et cetera. Which I can go into but that really gave us the velocity, and we wanted. We always wanted to go in with a land and expand mentality on let's land in one application, right? And then we can get to the other ones because once people see how easy it is on the first app, you know, more people are going to come for it.

Pablo Srugo (00:28:44) :
How fast did you guys grow? At the beginning, how fast did you get to a million? How fast did you get to ten? What was that curve like?

Bhaskar Sunkara (00:28:50) :
Yeah, I think in the first year we started in '08, as you know and it's been a while. But just from my memory, the first year we did about a couple million and then in the second year we did about twelve.

Pablo Srugo (00:28:59) :
Wow.

Bhaskar Sunkara (00:29:00) :
And the following year, we doubled, the following year, we tripled again. So we grew pretty fast. I'm counting some, multi-year contracts, et cetera, in there. So it's more revenue versus, pure ARR but that's what we were measuring at that point. But it was pretty quick. You know, I think especially in the second year, we grew pretty quickly and a lot of it was because the production POC part of it. Which was very quick, focus on enterprise but also another thing. Which I actually haven't talked about yet, is in 2010. So we started in 2008, right? So 2010, early we basically launched, you know, a free to use product that was like, just to think of it as a freemium thing. But it was called AppD Lite, AppDynamics Lite, right? It was one of those where you can go on the website, you could download it to your machine, and then you could run it only on a single JVM. But it would literally take a couple minutes for you to get going, right? You could just go in, attach that to the script that you're starting a server with, and then it would enable AppDynamics Lite in your server and start running. And instantly start showing you visibility, right? And so once we launched that, again, that was unheard of because nobody in our space had this sort of, you know, free trial. You had to call them, like a sales guy would reach out to you, then they would set up a meeting, they would scope everything and even then they said, oh, you know what? Let's sort of do a demo test POC, because then we'll learn and then we'll go to prod, right? So in an atmosphere like that, when we came in and say, go to the website and download it, right? So that sort of really gave us that momentum because sixty percent plus of our leads from then on started coming in from that. Oh, wow. You know, so that was a huge piece that we did and we never cautioned people on, hey, don't run this for prod or whatever, right? And we never said run it in prod. We would say this is an offering that you can try out, gives you visibility, right? And what was funny was that in the early days, when we would call someone and they were a light lead, were already using AppDynamics Lite. We would just mention casually that, hey, you know, by the way, you could run it in prod also. This is the same agent that we're actually shipping with the regular product and to our surprise, some of them basically said, it's already running in prod. Because they had tried it out and they were already running that, right? So one that gave us a lot of confidence, but I think it was a great way of, really disrupting the market, of putting something out there that was just super easy. Get started in a couple minutes, takes less than one hundred megs of disk space. Uses a very, very low amount of memory and we were very specific about that. Like, this is how much disk space it's going to take, this is how much memory it's going to take. Just go run it and you don't need to be an expert at running it.

Pablo Srugo (00:31:49) :
And then jumping kind of fast forwarding a lot, like from 2010 to I guess 2019. Tell me about the acquisition. How did that come about and then what was it like when that moment really happens, and the company exits for many billions.

Bhaskar Sunkara (00:32:04) :
Yeah absolutely. So I think the whole thing started off with Cisco being a customer, right? So in our selling cycle, Cisco was a lead. One of our apps was basically really working with the internal IT team there to sell AppDynamics to them and in fact, I did a bunch of sessions with them to get to the point where they made the buying decision on, hey, we're going to get AppD into our internal IT. That's how they started seeing the tool. That's how they started seeing how powerful it was and as they started thinking about, hey, this is something that we want to have as part of our suite, as part of our company. That's when the conversation started. But by then we were pretty much on our way to, because I mean, in startups, as you know, you'd run things parallelly. You never stop one or the other and you keep going in multiple directions. We had filed the S-1, we were pretty much ready to go. In fact, some of the team was in New York, they had their suits and everything else. And it was that close, we were a couple of days away. This was going on in the background. We were talking to them in the background. Not obviously everybody knew. The fact that we were in Soma, that's where our office was. But the fact that Cisco was just in San Jose, super easy drive, et cetera. Made it pretty easy. Not everybody knew about it, but the conversation started heating up and as we were getting closer to the IPO, then that's when we had the offer. A little bit of back and forth, here and there. And then eventually we're like, okay, let's take this one. Because we weren't going to float at probably around two billion, right?

Pablo Srugo (00:33:33) :
What was revenue back then?

Bhaskar Sunkara (00:33:34) :
We had basically by then sold a billion in TCB. I don't remember the exact sort of revenue number, but we had sold a billion in TCB.

Pablo Srugo (00:33:43) :
You're doing hundreds of millions at that point annually.

Bhaskar Sunkara (00:33:45) :
Yeah, basically and then also we had launched a bunch of new products. So as I mentioned, you know, we started with Java, right? But then after Java, we did .NET, you know, we did Node.js, we did all the languages. Then we started going to the layers where we did front end monitoring. Which is the browser based monitoring. Then we did database monitoring and then we did a business sort of analytics type of a product on top of this. So yeah, so we were a multi-product. The attach rate was solid for a lot of them, growing pretty quickly and so, yeah. So very solid business by that.

Pablo Srugo (00:34:18) :
And what was it like once that fully closed? What did it feel like for you as somebody who had joined a month after incorporation?

Bhaskar Sunkara (00:34:26) :
Yeah, it was pretty awesome. We actually, you know, in fact, what had happened was we were obviously supposed to go ring the bell at NASDAQ. A couple days away from it and then what NASDAQ offered to us was, why don't you guys come in and still ring the bell with Cisco? And so we actually had that experience. And then we were up on all the billboards, all these sort of displays, and we went in with Cisco and rang the bell. A bunch of us have that sort of NASDAQ sort of mementos, et cetera. So that felt great. That's when it started maybe sinking in, just the impact of what we built and so. And I think valuations like those probably weren't as common back then when we exited. And so, yeah, I think it was definitely amazing to have had that impact, right? And we were starting to do, pretty big multimillion dollar deals. We sold to everyone in financial services as well, which is always hard. Whether it's Goldman, JP Morgan, we're sold to Bank of America, we're sold to everyone. So we knew we had a very strong product and also Cisco was great in the sense that they were primarily, obviously a hardware shop. And for a bit, they just really gave us the autonomy because software work was kind of new to their ecosystem. So whether it was selling, whether it was building, all of those parts. So we had the autonomy there as well. So I think it started off like that. It took some time to sink in, but the impact of it was pretty amazing.

Pablo Srugo (00:35:46) :
And then what leads you to start Bicycle AI?

Bhaskar Sunkara (00:35:50) :
Yeah, so I think the simple way of talking about maybe the parallels is that think of AppDynamics as how do you go from technical signal to, what really happened and taking action on it, right? So technical signal could be, you know, checkout's not working well, it's slow, there are a lot of errors or whatever, right? That's your technical signal. I think of Bicycle as business signal to action. So business signal is coming from the data that's in your warehouse, the data that's in your business, in your data lakes, et cetera. And your business signal is basically like revenue for this product is down, revenue in San Francisco is down, or something like that. If I pick really simple signals and so how do you go from that to figuring out why is it happening? It could be happening because of a business reason. It could be inventory, it could be pricing, all of those things, or it could be technical. You know, it could just be happening on an iOS version because someone sort of messed up a change and it's not really working, and conversion overall is not slow, but it's just it's broken on a particular iOS version. And then that leads you to what action do you want to take? So there's some parallels there in terms of that. And I think the bridge Bicycle is trying to build is that if you think about operational systems. You know, take monitoring systems, they're not analytical enough. They're not thinking about products or merchants or customers in general or segments of customers in general or, any other attributes, right? So territories or cities or whatever else and so the monitoring tools or the operational tools are not analytical enough. They're not thinking about all those dimensions and if you go on to the other side and you look at analytical tools. They are not operational enough. They're very static. You look at a dashboard and you have to figure things out yourself. So how do you kind of bring them together? And the space now has evolved into what everybody calls agentic analytics. So using agents to do analytics for you.

Pablo Srugo (00:37:43) :
Well, this is going to be my question is, you know, you started this in like 2020. Five years ago, and then two and a half or so years ago, the world completely changed. And I'm curious how your vision or your product changed as a result.

Bhaskar Sunkara (00:37:56) :
Yeah, absolutely. I think so the way we initially thought about it. This was that let's build an automated data analyst in some sense, right? That sits on top of customer data, looks for patterns and sort of really comes up with patterns. And then we can triage them and take action for it. And once everything changed, once the whole world changed, and we saw the power of LLMs. What we basically did was, so think of that as an automated data analyst and what we basically said was, how would we create an automated business analyst on top. Which is the onus of asking the questions, asking sort of what to track and what dimensions to pick, and what dashboards to look at. Usually is on the user, but what if we had AI doing that? What if we had AI functioning as the business analyst that would know the business priorities, that would know, combined with domain knowledge as well as sort of, you know, knowledge within the company. Coming up with what are the patterns to look for? You know, what are the KPIs to onboard? So AI orchestrating all that. AI also orchestrating onboarding data, getting all that data onto some sort of mapping, some sort of an ontology. So that's the layer that we had to really build once all of that happened and the agentic stuff was very suited for it because instead of looking at a dashboard. What you're doing is you're creating like an agent loop, which is detect, explain, act, and then learn from every action. Learn from every sort of routing or action or whatever you basically did, and to be able to create that. So that's where the, you can call it a pivot, you can call it sort of like adding that layer on top of it. But what we started off with as just a data analyst now basically has an automated business analyst and it's kind of, think of the AI orchestrating the ML as the core product.

Pablo Srugo (00:39:42) :
And kind of a high level, where are things at today?

Bhaskar Sunkara (00:39:45) :
Yeah, I mean, at a high level, I think the agentic part of it. That's what we've been busy about over the last sort of six to eight months or so and especially just the changes or just the progress that's been made in agentic applications in the last, six to eight months. So really kept up with it and now we're about to launch more of the newer kind of agentic capabilities. We have our first dozen customers. We have some really strong deployments in production where customers are using us for not just obviously tracking signals but also performing actions. So we focus on B2C businesses because that's where the time to sort of do insights or glean insights. The urgency is much higher because otherwise you're losing revenue and so what we've done so far is with our core deployments, we've focused on doing the full loop, right? Not just detect, but do the analysis. So you would think of like a travel company where if there are issues with a particular supplier. We actually run a webhook to really take the supplier out and so that's like a full feedback loop. Same thing with retail when search conversion is low and basically, this is one of the largest retailers in India. So its conversion is low, and if the cause of it is being out of stock, then the agent goes ahead and basically orders it. So we focused on some really strong deployments on creating this agentic layer. But because with the agentic layer, you can do so much sort of out of the box and do it pretty quickly. That's what we've been working on the last six to eight months or so, and that's what we want to push out, you know, pretty soon.

Pablo Srugo (00:41:21) :
Perfect, well, let me stop it there and I'll ask the three questions we always end on. For AppD, when did you feel you'd found true product market fit?

Bhaskar Sunkara (00:41:28) :
Yeah, great question. So I think generally speaking, you know, our early POCs were about proof of concepts were basically focused on how quickly you can do them and a lot of times what happened was one of the things we focused on was automatic discovery of everything in your application. And usually it took, you know, one or two small features at the end to really complete, right? And we used to do that pretty quickly. We kept roadmap fluid and everything else. So think of it as we had POCs and we used to win that with some sort of heroic deals towards the end, right? Doing that pretty quickly. Once that stopped happening, where whatever the product was out of the box and I actually used to go to all the early POCs, like the first twenty, twenty-five of them. Probably I went to them myself, once that stopped happening. Where the product out of the box started working, once, you know, the energy that we spent on sort of doing the deal started reducing. Once people who were very happy with us deployed on one application were like, hey, can we get this onto some of our other applications. Once people who were at a company where they were using AppD left their job and went somewhere else and said, hey, can we get AppD into this company. Those are probably some of the signs that I would think about saying, I think, you know, we have something, we have the fit. You know, we can kind of really replicate it.

Pablo Srugo (00:42:47) :
And was there a time either at Bicycle or at AppD. Where you thought things might not work out and you might actually not make it?

Bhaskar Sunkara (00:42:55) :
I think there were a couple of instances, like I think the getting Netflix and Priceline on board did have its share of drama. We had built out all the functionality and with agents, overhead was the biggest thing. And in one of the overhead exercises, we had a lot of issues where we were coming up with pretty high overhead, and this was actually at Netflix. And it took us about, you know, maybe a couple of weeks to resolve it. And it actually turned out to be a JVM bug because they were using IBM's JVM versus Sun's JVM. And that turned out to be that, and it turned out to be not us. It took us a couple of weeks, right? And that was kind of existential because we're like, look, we've built out all this great functionality, but if we can't really run at the level of overhead that customers want us to. Then you know what happens, right? And so until it cleared out that it was not our problem, that was obviously something that was pretty scary to see how we go from there.

Pablo Srugo (00:43:47) :
And then last question, what would be a top piece of advice for an early stage founder?

Bhaskar Sunkara (00:43:51) :
If I look at some of the lessons that we learned and the things that we would do a little bit differently. I think I would say fail fast on hiring and then when you have your core pillars. Whether they're architectural pillars, whether they're sort of department pillars, the leadership who you really delegate to in that part. It's a really, really important role and if you feel like someone's not really working out, or you're afraid of someone having carried the load so far but they're not sort of scaling beyond that level. Just make decisions quickly and don't sort of worry about what's going to happen to the institutional knowledge, what's going to happen if you bring someone new or whatever. But I think failing faster on hiring is probably the biggest one I would do, yeah.

Pablo Srugo (00:44:30) :
Well, Bhaskar, thanks so much for jumping on the show, man. It's been great.

Bhaskar Sunkara (00:44:33) :
Yeah, absolutely. Thanks, thanks, Pablo, for having me.

Pablo Srugo (00:44:35) :
Wow, what an episode. You're probably in awe. You're in absolute shock. You're like, that helped me so much. So guess what? Now it's your turn to help someone else. Share the episode in the WhatsApp group you have with founders. Share it on that Slack channel. Send it to your founder friends and help them out. Trust me, they will love you for it.