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

Let's just say take Amazon through a 15 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 15 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. We were like, let's not sell to developers because they will give you the most feedback, right? Like, 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 obsolete.

0:00

When did you feel like you'd found true product market fit?

0:36

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 Abdi left their job and went somewhere else and said, hey, can we get Abdi 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 that's Product Market Fit. Product Market Fit. Product Market Fit.

0:39

I call that the Product Market fit question.

1:08

Product Market fit.

1:09

Product Market Fit.

1:10

Product Market Fit. Product Market Fit. I mean, the name of the show is Product Market Fit.

1:11

Do you think the Product Market Fit show has product market fit?

1:16

Because if you do, then there's something you just have to do.

1:18

You have to take out your phone,

1:21

you have to leave the show five stars.

1:22

It lets us reach more founders and it lets us get better guests.

1:24

Thank you, Bhaskar. Welcome to the show, man.

1:28

Thanks, Balbo. Thanks for having me.

1:32

So you're one of the founders of AppDynamics Co. That was acquired, I guess in the, in the late 2010s for nearly $4 billion. So massive, massive company started in kind of 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, well known name. So maybe let's go back to that time, right, as a starting point, like if we're talking, you know, mid, late 2000, what, what was going on in your world how do you end up kind of becoming part of AppDynamics?

1:33

Yeah, absolutely. So AppD was started in 2008 by, you know, Jyoti Bansal, who everybody knows, sort of like a multi unicorn founder. So Jyoti and I were working together at a company called Wiley, Wiley 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 Sujyoti and I were both at Wiley, 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 applications performance monitoring, you know, which Wiley 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 like cpu. You would then say, hey, you know, how's my database doing? How are my queries? And then while you 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. Like, let's just say take Amazon through a 15 year journey and you know, 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 15 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. So that's where we came up with this unit of monitoring called business transactions. And that really gave it this anchor on with the change with the architecture. It basically is a very, very manageable unit. And that was kind of really the core thesis behind rp. Does that make sense?

2:11

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, like when you're talking about monitoring and the old versus the new, you know, vapd, obviously there's so many different things you can monitor. What exactly are you talking about that you guys were focused on monitoring?

5:12

Yeah, yeah. So the old is basically saying, hey, my CPU is 30%, 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 20 milliseconds, this is running at 30 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 like overall for the system, saying in an hour there were a 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 they 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.

5:28

And so you were tying performance to specific like user actions like logging in or checking out, for example.

6:39

Yeah, I think user Action is the right way to describe it. And so we were basically tying to that, but the, the next step there was you tie it to that and then you, 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 100,000 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 like really, really fine grained sensors running on every server, we would then start profiling transactions and basically get to the depth of like looking at a slow transaction or a transaction that failed and then would give you deep 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 transaction. But two, like really do deep dive diagnostics when, when you needed to.

6:45

So going back to kind of the storyline, I mean, the first thing I want to ask about is, you know, you're starting a company mid-2008, what was the impact of, you know, let's say the financial crash and the financial recession or whatever on App D, 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?

7:59

No, I think I would say that at that time we were very passionate about the field, right? Like we spent about three years in Wiley. We were very sort of like 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 like 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 like 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 Our time, in hindsight, that helped us really, really well. And, you know, we did kind of think about that being an angle and

8:16

what types of companies were that. Was that like an E commerce company, like an Amazon or.

9:08

Yeah. So in short, if you say, hey, you know, the software is most critical to running the business, or software defined businesses, then 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, like, subscription services that just depend on software. That was kind of our sweet spot.

9:12

And tell me a bit about the beginning of that. I mean, it was a different area in terms of, like, 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? Like, how did you guys kind of set things up at the outset?

9:36

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 like Jyoti starting out in his garage, his apartment, type of thing, we had sort of the Series A lockdown 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 8, you know, in the back.

9:51

What was his background before? What had he done?

10:16

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 Wiley. He was sort of like, 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.

10:19

And how early did you join?

10:39

Pretty early, I think. You know, it was the first one he brought on. And so before we had, like, any basic sort of proof 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, you know, Wiley. But, yeah, pretty early on, I think probably, you know, if we were founded About April of 08, I'd say May or June, I joined.

10:41

So do you remember, more or less, like, how much you guys raised that first round?

11:03

Yeah, yeah, yeah, yeah. So five and a half was the first.

11:07

First round, basically, which is a massive check back then.

11:10

Yeah, yeah, absolutely. From Greylock and Lightspeed. But, yeah, that was. That was a good check back then. Gave us the right kind of Space and gave us the freedom to sort of like do what we really wanted to do.

11:13

How do you start something like this? Like do you just go heads down, you build product for a while, do you kind of get like an anchor customer that lets you, you know, do stuff on their environment?

11:24

Yeah, so I think a few things that we started thinking about in terms of execution, right? Like so number one, we wanted to find what's the first icp. And we were very sort of like eager to go into the market and really start sort of like deploying stuff. And our first icp, when we thought about it, was number one, look at distributed environments. Like I was saying, you know, 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, you know, because they will give you the most feedback, right? Like, 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, you know, the ops lead.

11:33

By the way, why is that like that Persona? Tell me. Because that is critical, right? Figuring out who exactly you should be selling to within an organization. Like what was it about that ops leader, what KPI they care about that made them the ideal buyer?

12:41

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 they're sort of like, 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 like 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 like 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.

12:55

What were they used to seeing? They were used to seeing uptime as well. But what was the before?

13:53

Let's say, yeah, the before was, you know, what I described earlier, like cpu, you know, code queries, how the query is doing.

13:57

Right.

14:05

And those were very deep constructs that they didn't really understand. And that used to change all the time. So it was like really sort of working through something that they were not fully comfortable with versus something that resists the change. Right. Like the business transaction was something that they're like, okay, you know, this is something constant versus I don't know what I have to do to keep up with all of this that I'm monitoring.

14:06

Why was that the status quo like now? 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?

14:26

Yeah, no, I think the monitoring part really comes from like a very technical background. Right? Like it comes from profiling. It comes from, you know, 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 on how we packaged it. Right. So if you look at like 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, like, 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 like 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 like a developer mode that's sort of like 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 focused, right? Like, what do you focus on?

14:38

What drove that, by the way? You'd think uptime only matters in production. That would be my, like, simple way of thinking about it. But why not?

16:07

Yeah, when you think about performance. So if you step out of uptime, if you think about performance, if you think about like profiling an application and making it better, right. That's more of a life cycle 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 like this four product suite that has all the features sort of like really distributed in different stages, right? So we said, let's just do that, you know, 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, you know, are they going to buy? The other thing to think about is, you know, a development license, you could do it per se, 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. Anything else, you'll have to pay the same price.

16:14

Was that strictly to help you guys focus or did that also help you sell by simplifying the offering?

17:25

It did. 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 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 you know, I'm having this particular issue, et cetera. Et cetera. But a memory leak is a very sort of, like, you can run, you know, a product, you can run a tool, a solution on a particular jvm, like one server, and diagnose whether, you know there's a memory leak there and why is it happening and things like that. But it's not a distributed construct. It's not sort of like something that's more complex, which is like, I don't really know where the slowness is because I have 20 servers, I have 50 servers, I have 100 servers, and they're all like, 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 it kind of makes it easier for you to make a case on the ROI if 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 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 like a distributed problem versus what is like 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.

17:33

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. 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. How do you get there?

19:16

Yeah, I mean, to start with, we actually started figuring out, like, which of our friends had test applications or whatever running on their laptops on wherever they were working on. Because what we had built was an agent. I mean, not like a AI agent, but an agent that was instrumenting, instrumenting, you know, 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 like more and more smarter, sort of like production monitoring. And Netflix actually was 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, you know, what they were doing and they needed to sort of like 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 like an initial thesis.

19:32

How did you get, like, whether it's Netflix or Priceline, one of these large enterprises that you got really early on, like, tell me that story.

20:37

Yeah, yeah, absolutely. So we are like a team that was really calling into them, you know, mainly LinkedIn, pretty gorilla in some sense. And so a lot of it was just like really having the clear value prop and then defining out the fact that, hey, we're, we're targeting the OPS people we targeted sort of like that ops Persona. And clearly they had a lot of pain. And so it was actually like a pretty quick hit.

20:44

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

21:06

a favor for you. Just hit the follow button.

21:14

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.

21:17

And by the way, the ops Persona is like, what role is that exactly? Like, what's the title of that role?

21:25

Yeah, let's just say VP of Ops. Right? This was before, like, 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. So you hit that Persona and that's how we got some of the early engagement, some of the early engagement going.

21:30

How do you communicate? Like, 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 like, you're going to understand what this means. And, you know, 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

22:02

this yeah, no, I think the concept of sort of like using a business transaction and really anchoring around that made it much easier where you're like, what are you tracking? Right? If you're tracking 20 things, and those 20 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 l in your application. So the agents are actually living in your application inside Java. And so how reliable they are, the quality of them was also super important because you are basically running in the application's memory. Like, 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'll 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? Like, number one, you know, what do you monitor? Like, the whole business transaction concept, which appealed to the VP of Ops much more than working with, like, queries and code, right? So that's number one. And second, it was the overhead part of it. On, look, I mean, we barely add 1 to 2% 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? Like, so we said, why don't we just say, you know, do a production

22:21

poc That's a good segue. Like, how do you structure that? Do you just run alongside their existing analytics? And so now they have both views.

24:03

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.

24:09

And so how do you scope that out? Because that's a big risk for them if, like, the PLC doesn't go well, if you don't. You know what I mean?

24:21

Yeah, absolutely. And what we said was start small, you know, take a part of the application, see what visibility you get see how much time does it take for, 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, you know, solution which basically says do like a POC production. They're that short of their overhead, they're that short of like not crashing the app or doing something. So it's a risk we took. Right.

24:27

But for them, they would just put you on a specific part of the app that maybe like, is the least critical part, let's say, and just see how you monitor that.

25:03

Yeah, and most people actually put us onto like a pretty reasonably critical ones just because again, when you have pain, you can do that. And also, by the way, our credibility at Wiley really helped, right? Because we had spent multiple years at Wiley doing this thing, so we were not like building this for the first time. We understood agents and we understood sort of like 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 onto 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 100 plus servers and they put us onto 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, Abdi, and looking at one that had Abdi, and literally you couldn't tell which one was which, which is the win. Right? Like, because you're like, you're an agent, you're tracking your monitoring, but it's almost like you're not there.

25:11

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 there I'll therefore I'll pay you. Or is it more like, because I have this now, I can act on it and now my performance is higher than it would have been. Like, how do they think about, you know, paying what I assume are pretty big contracts for something like this?

26:09

Yeah, absolutely. See, visibility, I would break it into two parts. Right. Like, 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 is slowing down, you know, at a particular time, especially with respect to the seasonality. Right. Like 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 10am, 11am, 12am, 12 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 like 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 like, 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 like, you know, worth everything to them.

26:29

And how big Were the ACVs early on?

27:51

Yeah, I think in the beginning we were in the, you know, 50 to 100 type of range because we wanted velocity. You know, we did some 25s also in the beginning, but we wanted velocity. We wanted like really quick sales cycles because what we really thought of was like, how quickly can we do a poc? And in the beginning, like, we did a lot of like single day POCs, which was just unheard of in application monitoring at that time. And there's some stories in terms of like, more tactics and specificity and how we approach the POCs, how we align 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, 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.

27:53

How fast did you guys grow, like at the beginning? Like how fast you get to a million, how fast you get to 10? What was that curve like?

28:44

Yeah, I think in the first year we started in 08, as you know, and it's been a while, but like just from my memory, the first year we did about a couple million. And then in the second year we did about 12.

28:49

Wow.

28:59

And the following year we doubled. The following year we tripled again. So we grew pretty fast. I'm counting some like multi year contracts, et cetera in there. So it's more like revenue versus like pure ARR. But like 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 08, right? Like, so 2010 early. We basically launched, you know, a free to use product that was like just a. Think of it as a freemium thing, but. But it was called APPD Light Appdynamics Lite, right? It was one of those where you could 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 are starting a server with, and then it would enable, you know, 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 like, you know, free trial. Like 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, like let's sort of do like a Dev or test PoC, because then we'll learn and then we'll go to product, 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 60% plus of our leads, you know, from then on started coming in from that.

29:00

Oh, wow.

30:42

You know, so that was like 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 were saying like, 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 like a light lead, we're already using Appdynamics Lite. We would just mention casually that, hey, 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 like, super easy. Get started in a couple minutes, takes less than 100 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

30:43

it and then jumping kind of fast forwarding a lot, like from 2010 to, I guess, like 2019. Tell me about the acquisition. Like, you know, how. How did that come about? And then what was it like when that moment really happens and. And the company exits for, you know, many billions?

31:48

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 with them. And in fact, I did a bunch of, like, you know, sessions with them to get to the point where they made the buying decision on, hey, we're going to get Abdi 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, you know, as part of our suite, as part of, like, 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, like, you'd run things parallelly, you never stop one or the other, and you keep going in multiple directions. We had filed the S1. We were pretty much ready to go. In fact, like, some of the team was in New York. Like, they had their suits and everything else, and it was that close. Like, we're a couple days away. This was going on in the background. You know, we were talking to them in the background. Not obviously everybody knew the fact that, like, 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. You know, 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 were going to float at probably around 2 billion, right.

32:03

What was revenue back then?

33:32

We had basically by then sold a billion in tcv. I don't remember the exact sort of revenue number, but we had sold a billion in tcb.

33:34

You're doing hundreds of millions at that point annually.

33:42

Yeah, basically. And then also like 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 like a business sort of like 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.

33:45

And what was it like once that like fully closed? Like what did it feel like for you as somebody who had joined a month after incorporation?

34:18

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? A bell with Cisco. And so we actually had that experience and then we were up on all the billboards, all these sort of like displays and we went in with Cisco and rang the bell. A bunch of us have that sort of NASDAQ sort of, you know, 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 like 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'll sold to bank of America which 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 was kind of new to their ecosystem. So whether it was selling, whether it was like building all of those parts, so we had the autonomy there as well. So I think it was. It started off like that. It took some time to sink in, but, like, the impact of it was pretty.

34:26

And then what leads you to start Bicycle? AI.

35:46

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, you know, what really happened and taking action on it? Right. Like, so technical signal could be, you know, checkout's not working, 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. That's the data that's in your business, sort of 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 like, really, 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. It could just be happening on an iOS version because someone sort of, like, messed up a change and it's not really working. And conversion overall is not slow, but it's just. It's broken on, you know, 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 that 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, you know, any other attributes. Right. Like, 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 onto 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.

35:49

Well, this is going to be. My question is, you know, you started this in like 20, 25 ish years ago, and then two and a half or so years ago, like, the world completely changed. And I'm curious how your, your vision or your product changed as a result.

37:43

Yeah, absolutely, I think so. The way we initially thought about this was that let's build like an automated data analyst in some sense, right? Like that sits on top of customer data, looks for patterns and sort of like 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 like an automated business analyst? On top of which is the onus of asking the questions, asking sort of like what to, what to track and what dimensions to pick and what dashboards look at usually is on the user. But what if we had AI doing that? What if he 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, for what are the KPIs to onboard. So AI orchestrating all that, AI also orchestrating onboarding data, getting all that data on to 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 Agentix 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 detective, 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 the 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

37:56

product and kind of high level, like where are things at today?

39:42

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, eight months or so. And especially just the changes or just the progress that's been made in agentic applications in the last like six, eight months. So really kept up with it and now we're about to launch, you know, more of the newer kind of agentic capabilities. We have our first, you know, 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 like 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, search 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 want to. We've been working on the last six, eight months or so, and that's what we want to push out, like, you know, pretty soon.

39:45

Perfect.

41:21

Well, let me stop it there and I'll ask the three questions we always end on for AppD. When did you feel like you'd found true product market fit?

41:21

Yeah, great question. So I think generally Speaking, 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 one or two small features at the end to really complete. And we used to do that pretty quickly. We kept roadmap fluid and everything else. So think of it as like we had POCs and we used to win that with some sort of like, heroic deals towards the end, right? Like 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 20, 25 of them. 20 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 like doing the deal, you know, started reducing. Once people who are very happy with us deployed on one application were, hey, can we get this onto some of our other applications? Once people who were at a company where they were using ABD left their job and went somewhere else and said, hey, can we get ABDY into this company. Those are probably some of the signs that I would think about saying, I think we have something, we have the fit, we can kind of really replicate it.

41:28

And was there a time either at Bicycle or at abd, where you thought things might not work out and you might actually not make it?

42:47

I think there were a couple of instances. Like, I think the getting Netflix and Priceline on board did have its share of drama. Like, we had built out all the functionality and, you know, like, 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 like, 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 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 like, pretty scary to see how we go from there.

42:55

And then, last question. What would be like a top piece of advice for an early stage founder?

43:47

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 like 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 like 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, you know, I would do. Yeah.

43:51

Well, Bhaskar, thanks so much for jumping on the show, man. It's been great.

44:30

Yeah, absolutely, thanks. Thanks, Pablo, for.

44:33

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

44:35

you have with founders.

44:48

Share it on that Slack channel. Send it to your founder friends and help them out. Trust me, they will love you for it.

44:49