Greg Michaelson: Well, hello, welcome back to Day to Day. I'm Greg Michelson and I'm really excited to be here with Bhaskar Sankara, a new friend of mine. We have a connection from the AppDynamics world. Bhaskar was the CTO and founder, co-founder of AppDynamics, which had an outrageous exit too. I think, Cisco acquired you guys, right?
Bhaskar: Yeah, yeah, absolutely. Cisco acquired us. This was 2017, so it's been a while.
Greg Michaelson: What, when was that? What year was it? Wow, okay, awesome. Well, maybe we start out, just let me get an introduction from you and tell us a bit about AppDynamics. Was that your first startup, AppDynamics?
Bhaskar: Yeah, absolutely. Yeah, I mean, been doing startups before. was one of the founders and ⁓ the ⁓ CTO there. And we started sometime in 2008, and then we exited in 2017. ⁓
Greg Michaelson: Oof, that's a hard time to start, huh?
Bhaskar: pretty busy. It was, was. But you know, one of the things that was happening in 08 was people were looking at optimization. People were looking at sort of like getting their systems sort of like running really well. ⁓ And so we actually, we actually wrote that way. I think it was kind of good to, you know, focus on something that that's making your systems more reliable, that's helping with ⁓ drops in, you know, ⁓ sort of like issues with uptime and loss in revenue, et cetera. So, so that actually really help.
Greg Michaelson: Well, maybe it would be good in case folks aren't familiar with AppDynamics. Can you give people just kind of ⁓ a little quick thumbnail of what the company did and what you built?
Bhaskar: Yo. Yeah, absolutely, absolutely. So we were basically the next generation of ⁓ application performance monitoring at that time. ⁓ And what I mean by that is that the way performance was measured. before AppDynamics was either using CPU, either using how your code is running, how your queries are running, and things like that. And what we came in and said was that, mean, one, applications are getting super distributed. So you can't measure code in like 50 different servers. There's just too much code running. ⁓ Number two, it changes all the time. So if you're looking at a relational query and tomorrow you're using NoSQL, what do do with the old method? So there's a lot of change, ⁓ very distributed and it's hard to pin down what services is doing what. ⁓ And so what we said was, why don't we use a measure that is linking back to the user and we introduce this term called business transaction. So instead of measuring code, instead of measuring CPU, instead of measuring queries, you're basically measuring what's the time login is taking, what's the time checkout is taking, what's the time ⁓ payment is taking. irrespective of the changes, irrespective of how distributed it is, that just links it back to user experience. And that's really what... ⁓ But at the same time, we anchored diagnostics, we anchored... You could drill into a particular payment flow, could drill into a particular checkout flow, and get all sorts of diagnostics right down to the millisecond when something was off. So almost sort of turning on a production profiler for lack
Greg Michaelson: Gotcha.
Bhaskar: a better word on when things were not going wrong. that was the appeal. you're number one appealing to the operations people because this was the time when things were getting at a scale where just the developers couldn't operate. So the operators were operating, but they didn't know the code. So they needed a metric they can anchor on, which they can relate to. And we brought in the whole business transaction thing. And then you could do diagnostics and fix issues. So that was the killer combo.
Greg Michaelson: So less important what my CPU consumption is and more important how long it actually takes to check out in my store. Gotcha.
Bhaskar: Correct. Exactly. Which stands the test of time, right? Like, you know, if you're Amazon and if you've re-architected 10 different times in the last 15 years, what still matters is how much time it takes for checkout. So, sounds obvious now, but wasn't then, Yeah.
Greg Michaelson: And you're not wrong. I that is the most important thing. And it's cool that you guys could capitalize on it. Now, did you have a bunch of pivots along the way or did you guys know from the beginning that that's how you wanted to set up your monitoring scheme?
Bhaskar: ⁓ No, we were actually pretty sure. think we started off being a Java product. We were like very focused on Java and just doing Java APM. And so that actually gave us the focus versus doing too many things at once. We didn't try to jump on to like ⁓ Ruby on Rails or whatever bandwagon at that time. So we're like, let's just do Java. Let's do it really well. ⁓ And we were sure about two things, right? Like that we wanted to help the operations people. And then second, ⁓ We wanted to be running only in production. So if you remember, generally speaking, performance monitoring tools have different versions. Like you run it in dev, you run it in test, you run it in staging, you run it in prod. And usually you take a tool that actually ⁓ has a version in each, right? Like you dial up the knob, you dial down the knob, but it's kind of the same tooling that's working in all environments. And what we said was we only want to sell in production. So if you want to run it in dev, or test, it's gonna be the same money. And so I feel like that was probably the biggest decision that we took that helped us sort of stay true to running a production versus like, ⁓ we're just gonna do like these 20 things. So we definitely focused on that.
Greg Michaelson: Yeah, that seems like reducing friction with customers is a really important thing there. I mean, I guess 2008 was before this whole product-led growth wave that has come and sort of swept over startups. Did that sort of go-to-market approach affect how you guys sold at AppDynamics?
Bhaskar: Yeah. Yeah. I'm glad you asked that question because you know one of the probably the most important thing in our good market that got us attraction was Look, I mean performance monitoring ⁓ Especially when you're using an agent that's inside the app So, you know most performance monitoring works with instrumentation where you're in the app that you're monitoring, right? ⁓ and so that's fairly sort of technical and ⁓ It was one of those things where you would work with the vendor the vendor would sort of like really work with you to install it on your servers and everything else. But one of the things we did was like a year and a half into sort of like building, et cetera, et cetera, we actually launched ⁓ Self-Serve. And what we did was we created a mini version of the product, which I had kind of written up in like a couple of weeks to start with. And we put it up on the website and said, Go download this, you know. It's very low footprint in terms of memory. It's hardly anything to download on your disk. Connect it with your live server and start running it. And you don't need any help from us. Everything is auto-detectable. Everything is sort of automated. And it'll give you value in five minutes. ⁓ There was no other performance monitoring tool at that time which had self-serve, which was accessible, where you could actually start a trial, whether it's on the cloud or whether you download and use it. ⁓ So that gave us a tremendous amount of cred, a lot of confidence. ⁓ Especially because when we started, ⁓ you know, reaching out to people who are downloading and we're looking at the links on who was downloading, cetera. ⁓ People were already confident running it in prod, which really surprised us in the beginning, but because we had written something for prod. ⁓ But that was a strategy. we that really helped us ⁓ almost like 50 to 60 percent of our leads at the time basically started coming in from the self self motion where people are downloading and just using it. So really help us there.
Greg Michaelson: Now was the application monitoring space super noisy back then or were you the kind of first player on the scene in terms of.
Bhaskar: It was pretty, I mean, there were a lot of, you know, in fact, like one of the things in our head when we got into the market was, well, there's a lot of really established vendors. So how do we sort of like really, you know, how saturated is the space? Is it a solved problem? Because you have, you have these questions at the back of your head before you actually go start talking to customers. And when we started talking to customers, ⁓ we discovered that still white space in there because, ⁓ you know, customers were basically either burned by not super stable. Again, if something's running in your app, it can crash you. And that had happened quite a bit with some of the customers. And so it wasn't a solved problem. And that's what we discovered, that it's still pretty old school, still working on CPU and code and everything else. Every change needed a restart, stuff like that. So we kind of broke the whole system in terms of saying, this is the next generation. And that's when we, I think, transformed that space.
Greg Michaelson: Right? Got it, so you kind of like rethought the whole paradigm of how to monitor by changing the metrics that were important. Yeah.
Bhaskar: for sure. Yeah, exactly. Exactly. We anchored on something that's more that's more businessy versus like, ⁓ let's look at like 100 at a time.
Greg Michaelson: Now, when Cisco bought you guys, tell me about that. What was that like? That was a huge number.
Bhaskar: Yeah. Yeah, it was a huge number. So I think what was happening at that time was that Cisco was actually a customer of ours, right? Like Cisco, Cisco IT, Cisco was using AppDynamics and was very happy with the product. we were, you know, we had filed an S1, we were like, you know, on the path to to an IPO. In fact, like most of the team was in New York to go ring the bell, you know, and just basically a couple days away from doing that. ⁓ We had the, yeah, absolutely. ⁓ We had the discussion sort of in the background ⁓ and I think Cisco, as it was starting to think more and more about software, got very serious about it. But a lot of it, the foundation was how much they loved the product as customers.
Greg Michaelson: No kidding.
Bhaskar: That was the starting point. And so it was pretty last minute. People were already in New York. They were already in New York to go ring the bell at NASDAQ. And so we told them, this is what happened. Because the numbers were really good. We looked at the overall climate. We felt like this is sort of the right thing to do. But yeah, that was a little bit of a dramatic, dramatic story there. Yeah.
Greg Michaelson: Yeah. Yeah, I feel like a lot of these IPO stories could be movies.
Bhaskar: They could be absolutely, you're right.
Greg Michaelson: All right, so you finish up at AppDynamics and what do you go on to next?
Bhaskar: Yeah, I mean, I took a little bit of a break. then the thing I had in my head was basically the whole signal to action journey was very like it's something that I really enjoyed. A lot of things that we learned at Abdee in terms of understanding, monitoring the whole culture of like operations and everything else, that was really amazing. But then I think I... The thing that really sort of stuck with me was that, how do you sort of like move up the chain, ⁓ right? So when we were at Abdee, one of the products that we released that was a little bit later in the cycle was a product called Business IQ. And what it did was... When something goes wrong, like when there's an outage, for example, ⁓ it was calculating what was the business impact, right? So it's like who got affected, what type of customers. ⁓ You know, if it's a retail scenario, like could we actually just give them like a gift card or something like that. It's like calculating impact of an outage. ⁓ and that got me thinking, you know, over time and especially, you know, during the break on like, how do we sort of like, ⁓ not do it after the fact, but think of it as, ⁓ can we, can we build like an operating sort of system that's sort of anchoring on those key cohorts, business KPIs, business, ⁓ you know, KPI slices. So for example revenue by my top city revenue by my top product things like that Can you anchor on those and build that as the business signal so that? When you detect sort of anomalies etc etc, then you can do the analysis then you can go go to whatever you need to ⁓ So that's sort of the link between them ⁓ and ⁓ You know what we ended up building initially was building a system that was doing exactly that But one of the things that wasn't super optimal in it is that how do you ⁓ feed all the system with the business definitions, the business model, and everything else? Because you don't want to be running a bunch of queries on a warehouse and trying to figure a bunch of stuff out. You want to model a business. You want to of understand how do you go from ⁓ detecting a signal to why it's really happening? And so you want a system ⁓ modeled. So when we did that, ⁓ yeah, good.
Greg Michaelson: Now when you say we, you're talking about bicycle now, not AppDynamics anymore, yeah? Okay, okay, just wanted to make sure. Bicycle.ai. Okay, okay, go ahead.
Bhaskar: Bicycle, yeah, correct, correct, correct. yeah, yeah, yeah. Bicycle, yeah, yeah, absolutely. ⁓ Yeah, just to answer your question in a short way again, think ⁓ post sort of like the exit, I stuck around for a little bit, then sort of like was consulting even with Abdi for a little bit once I started being full time, then I took a little bit of a break and then started building bicycle. And I was actually starting to go into the journey of bicycle, but we can talk more about that later.
Greg Michaelson: Yeah, yeah, no, I'm super interested in that. So when you talk about the sort of sales operation monitoring type stuff, is that all linked to like server health and monitoring applications as well, or is it more business focused? How does it work?
Bhaskar: So think about it this way, right? Like when you have a business KPI, like a drop in revenue or something like that. ⁓ You know could be a drop in conversion could be drop in approval rates, you know when you take a payment use case ⁓ The root cause of it could be multiple things, right? It could be because you have a technical problem, right? Like where you know people are not able to you know Just click on the checkout button for whatever reason because you know, the UI is not loading or something like that It could be a server issue. It could be like something changed for a particular version, but it could also be a pricing issue It could be a competition It could be an inventory issue. It could be a stock out issue. So all of these factors line up. And typically you have the different parts of it where a signal can be attributed to both sort of technical factors as well as the business factors. That's actually one of the reasons why, so they're the two wheels that run the business and bicycle is like the data drive train that connects them and that's why we call it bicycle. being able to...
Greg Michaelson: Gotcha.
Bhaskar: Being able to look at both factors ⁓ and being holistic about it versus saying, yeah, it could just be a technical problem and looking just at the technical layer, that's really the story for us.
Greg Michaelson: Gotcha. Okay, so Zerve, my company, we're a software, a data-focused agentic coding environment, and we have a self-serve type model where people can go on the website and sign up and get a free account and then upgrade to a paid account and so on. If I wanted to plug in something like Bicycle into our business, are we too small for that? Or is there some sort of scale that's required? How would I go about thinking about it? Like, sell me here.
Bhaskar: Mm-hmm. Yeah. Yeah, mean, I think it's, yeah, absolutely. So it's actually pretty straightforward. What you do is ⁓ usually you start from the source of truth, like, so let's say you have a warehouse where all the data is, right? ⁓ You connect bicycle to that, right? Like it could be take a BigQuery, take a Snowflake. ⁓
Greg Michaelson: you to like post hog or something like that. Yeah. ⁓ dump it to a warehouse. I see. I gotcha. Okay.
Bhaskar: More a warehouse, just because we're looking at the core business metrics and everything else. So let's say you have all of that in Snowflake or BigQuery or Redshift or something like that. You can start with that. We also do streaming systems. So if you have something like Kafka in the background, so we could connect with that as well. So that's our core usual source of truth. What we'll do is we have an agent that then will onboard the data from there. ⁓ We'll take context from you on what the company is, what it does, et cetera.
Greg Michaelson: Mm-hmm. Mm-hmm.
Bhaskar: So bicycle system, think about it as how LLMs and machine learning are basically working together. So think of bicycle as a business analyst and a data analyst in a box. So the LLM functions as a business analyst and the machine learning basically, the AutoML functions as a data analyst. Because you don't want the LLMs doing the math. Right. Anything that's sort of like solid math, you want that to be sort of like machine learning or anything that's solid. Anything that's probabilistic where you're like, ⁓ why is revenue dropping? you want to hypothesize, then you want to figure out why that's happening. That's more of the ⁓ ML. So going back to the setup, we will onboard the data. The LLM will help sort of map definitions and things like that and set up data so you don't have to do a lot of heavy lifting. We'll do the 80, 85 % of the work in the initial setup, setting up your KPIs, setting up your slices, dimensions, all of that. ⁓ And then what we do is we have ⁓ you on top of the model, on top of that ontology we create, we basically start running the machine learning pieces. ⁓ And what the machine learning will do is think of, let's say again, take a very simple example. Let's say you're looking at revenue by 100 different cities. So we will have an individual model for all the 100 cities so that we can actually track baselines, track sort of like anomalies and everything else. And so that's an example pattern. And when the pattern goes off saying, revenue is dropping, ⁓ our agent would then start looking at both technical factors and... ⁓ business factors like I was saying like is it pricing is it sort of like performance ⁓ is it like you know competitive pressure is it something external saying like ⁓ you know maybe it's happening because ⁓ you know it's it's a holiday and people are not buying tickets or something like that right so it will look at all of those and then it'll give you a brief it'll give you like recommended actions so that's the overall setup but it's a pretty low lift you know on top of that we do focus on transactions
Greg Michaelson: Mm-hmm. Mm-hmm. Mm-hmm.
Bhaskar: businesses, that's our sweet spot. you know, take retail, take payments, take, you know, take travel, because that's where the sense of urgency to convert insights, you know, into decisions is the highest. And we wanted to focus on that. And we think of ourselves as a vertical solution.
Greg Michaelson: How would you find where would the competitive data come from if say there is a new a new competitor suddenly appeared? How would you know that in your in your system? Are you?
Bhaskar: Yeah. You know, it's typically the agent basically doing web search, looking at like sort of, you know, the data of the internet. So again, being agentic, having access to everything that a modern agent has. And so we'll basically analyze that. But we have a lot of context on what we're doing. So that kind of feeds it in. And so that's going to be part of the analysis.
Greg Michaelson: Got it. Now developing the agent, how was that? We're still in the new days, kind of the early days of ⁓ agentic analysis. What were some of the hurdles that you came across?
Bhaskar: Yeah. Yeah. Yeah, no, think understanding really the, ⁓ if you think about sort of like the analytics agent, the way I kind of looked at the sort of different pieces involved, right? So for example, ⁓ there's the model you're using, there's the data, there's the metric definitions, there's the ownership model, because again, when you're deploying it in an enterprise then... It is basically multiple people who own it. ⁓ The models always, people always look at the model because that's the decision maker and that's the glamorous part. But when issues happen, they usually happen upstream.
Greg Michaelson: Mm-hmm.
Bhaskar: the agent can only be as trustworthy ⁓ as the metric definitions and the ownership structure. For example, if nobody agrees on what revenue means or what is the failed payment or what's a retry, ⁓ the model will just end up confusing you ⁓ and then ⁓ the ownership will bite you. The system may be right, but it might route the issue to the wrong team and eventually it didn't help. You know, and then also there's data freshness where one feeds updating every minute, the others operating next day. So so things like that, right? ⁓ So sometimes what happens is a model will say approvals are healthy, because it's just using the wrong definition ⁓ while the business is looking at like a different way of looking at it, right? instead of like say it is actually a semantic failure, but it's sometimes looked at ⁓ as a model failure. So that's the layer I feel like is the harder one to build because ⁓ especially in the age of AI people, in the details, because in the age of AI people expect a plugin and it just works magically. Even if there's a lot of ambiguity to figure out in the semantics.
Greg Michaelson: Sure. Yeah. The devil's in the details.
Bhaskar: so I'm like, what should I pick? Because I see like four definitions.
Greg Michaelson: Right. And most, yeah, there's most of them, even on the business side, nobody really agrees on the definitions of everything. Yeah. Gotcha. And then in terms of ⁓ feeding back what's what seems to be going on and proposing actions to take, that seems hard. Right. Finding those business actions, because typically in analyses like these, results are kind of like
Bhaskar: Yeah. Correct. Correct, correct. Exactly. Yeah. Mm-hmm. Yeah.
Greg Michaelson: Not trivial, but like you tell me something, ⁓ this is happening because of X, but X, there's nothing I can do about X. You know what I mean? So how do you, how do you sort of navigate that?
Bhaskar: Yeah, yeah, yeah, yeah, yeah. Yeah. So I feel like, and this is again, something ⁓ from the AppDee story as well, but an alert should be not the beginning of triaging it, but it should be the end of triaging it, right? Because when we think about alerts, sometimes they're paging people too early, right? And if all the alert is saying is the metric is down, it doesn't really help, right? Because you're just offloading work. ⁓ I feel like the right pattern is, ⁓ detect, then auto triage and ⁓ find out some sort of thesis and then notify when you have something useful. I ⁓ like to think about a useful alert as having five things. ⁓ What changed? ⁓ Number two, where is it concentrated? What is the impact? How big it is? Number three, what likely changed around the same time?
Greg Michaelson: you
Bhaskar: and who should care. Right? So without that, if you're just sort of like throwing something out there on this is up, this is down, that's kind of the, you know, not as useful, right? And the other big thing is that you have to use business thresholds and not statistical thresholds. Again, like a good lesson we learned from, from MAPD because you have to... know, create a threshold for it. So let's say you have a product ⁓ that ⁓ has really high traffic, know, a of transactions without traffic. And you have a product that, you know, has much, much lesser traffic. The way you calculate thresholds for them is very different because you have density of data and how you calculate that for the... high selling product versus the other one is very different. So that's where you have to bring in the business angle and not just statistical part of it. You also have to think about what is a noisy alert and when you have to do it. Do you say, oh, it has to have at least this revenue for it to be meaningful for me to take a look at it. And that's all bringing in the business definitions and it has to have meaningful impact. But the bottom line is, mean, you know, don't just say that, hey, you know, your credit card approvals are, you know, whatever percent overall moved, but be very specific on like, that is a particular issuer segment are most likely try to tie to a, you know, a route specific issue and it's not sort of systemic. That's the way to sort of like really alert people. Yeah.
Greg Michaelson: It is interesting to think about these kind of softer, more businessy type problems in kind of a more engineering type context. I love how the nerds are sort of taking over. There's a friend of mine, his name is Jeff Schwartz, and he started a company called Data Room HQ. they've been around for a couple of...
Bhaskar: Yeah. Mm-hmm. Yeah. Mm-hmm. ⁓ nice, we're good.
Greg Michaelson: Wow, like five or six years now. And they do ⁓ kind of like more like when you're raising, having a data room ready and being able to look at, you know, like a constant snapshot, like an instant snapshot of what your business metrics look like. And they take it on from a very sort of engineering based perspective as well. Do you think that that sort of way of looking at things, like let's look at it like scientists, like engineers, like very technical people?
Bhaskar: Sure. Yeah. Yeah.
Greg Michaelson: even though it's traditionally more of a softer domain. Do you think a lot of that is happening because of the rise of these coding agents and the ease at which it is, how much easier it's become to build these kinds of things? What's pushing that trend?
Bhaskar: Yeah. Yeah. Yeah, I feel like, you know, breaking down a problem statement into sort of like, again, you know. What's sort of the math to it? What's sort of the interpretation to it? Can you then give the interpretation to like a model? Can you sort of like then sort out the sort of math? ⁓ But breaking down such a nuanced problem into, ⁓ you know, smaller units and applying different parts of AI to it, applying different parts of ML to it, at least in my head, that's how I think about it, just being an engineer. And I relate to it and I can understand you know, especially to your point, because the coding agent, if you know, and I love that strategy of how a coding agent basically defines overall strategy and everything you're doing, you know, whether you're basically building a website, whether you're building an app, whether you're sort of like solving a problem, ⁓ you, solve it with code because code's a very logical way of breaking down a problem. Like you write a routine, you write another routine, you connect them together. ⁓ the logic in one routine and the other one, you know, it's very different, right? like and some one of them can be hypothesis, one of them can be deterministic. ⁓ And so I feel like that that lends itself really well to solving, you know, very nuanced problems, ⁓ especially when they can be, ⁓ you know, ⁓ a lot of like, organizational boundaries and this and that and everything else. And so how do you sort of break it down into something simpler? Does that make sense? Yeah.
Greg Michaelson: It does. ⁓ I'm curious in particular about how you guys are using, like say, do you guys use Cloud Code or Copilot or any of these coding agents in your development work?
Bhaskar: video. Yeah, we do use Cloud Code. So we use both Anthropic and OpenAI, but we do use Cloud Code quite a bit.
Greg Michaelson: Yeah. Yeah. So you've been an engineering manager, manager of engineers, software engineers who are developing ⁓ real, intense production grade enterprise level software for years, decades now. And it feels like the whole coding agent thing is a bit of a seismic shift in terms of the way things work. Do you see it as transformative as that? And how has it impacted the way that you think about development?
Bhaskar: Mm-hmm. Mm-hmm. Yeah. Yeah, absolutely. Yeah. Yeah. Yeah, mean, 100 % right. Like I think ⁓ one of the things that people talk about right now is that ⁓ code is not the bottleneck anymore. ⁓ Design is. What you want to do, what you want to build, how you want to build it, that is really the bottleneck. actually, like writing code for it isn't basically the bottom line anymore, which I kind of like, right? Like, because it makes the problem a lot more creative versus just operational. ⁓ So it's almost like what the... ⁓ Industrial Revolution did do like fabrication or just like creating of or manufacturing something right because machines could do it You know and machine and humans used to do it But then what became more interesting was what do you want to build and what do you want to fabricate? What's this? Like, you know, so it's very very similar right like the the core part is not that important but ⁓ But obviously you want to have the right plan, want to have, you know, want to build something robust, which the coding agents can do. They write really good code, right? ⁓ But what's more important is what do want to build? How do you want to build it? What's the design? What's the problem you're solving? So it's a good sort of step in that direction.
Greg Michaelson: So coding agents are like the assembly line for the software engineer.
Bhaskar: Pretty much, Exactly. Yeah. Yeah.
Greg Michaelson: Yeah. Now, where do they break? So when you're working on a large complex system like that, at some point you run into, okay, the context is too complicated. The agent keeps forgetting how things work. It's like, what are the limitations of coding agents today when it comes to building real complex systems?
Bhaskar: Thank you. Yeah, I mean, I think the thing is like when you have coding agents and you have agents when you have like these probabilistic sort of like systems, you have to have the right evals. You have to have the right structure to basically say, how do I evaluate this is good or not? Right. So like, how do you measure it? Right. Like that's the key thing. And a lot of times, you know, that's, that's not something people are, you know, paying a lot of attention to, attention to, right. Because for an agent to look smart, for 10 minutes is super easy. But when you think about, ⁓ know, just on like a random Tuesday or Wednesday, ⁓ it's unambiguous, it's clear, and it's providing value. Like that's what it's about, right? At some point when it gets boring, that's when it's become useful. ⁓ Not like a 10 minute demo where it's like, ⁓ you know, I'm coming up with like a cool like demo using an LLM. So that's the part, that's the hard part. And I think ⁓ You know, things like evals, obviously having a sound ⁓ model you're working on top of ⁓ versus just running the agent in different loops without a strong model, that's the starting point. But evals are important. So for example, if you're detecting something, ⁓ what you have to evaluate is did we notice a meaningful issue fast enough? ⁓ So you look at precision, you look at time to detect, you look at false positives, you look at false negatives. negatives, et cetera. Then you're diagnosing. So once the agent is flagging something, ⁓ did it pick the right slice? Is this the right concentration? ⁓ Did it pick up the right drivers, which could be driving it? ⁓ Was the actual issue, yeah.
Greg Michaelson: ⁓ so you're you're talking more about using agents as data analysis. I was thinking more about using agents as software engineers to actually build the code of the application. Yes. That's OK.
Bhaskar: Yo. So there's sort of link, you're right, like I think I was kind of digressing a little bit, but there's sort of like, what I mean by that is that, you know, if you, ⁓ when you build something, the way you evaluate it is the most important thing. ⁓ In terms of just answering sort of like maybe, ⁓ you know, where the break, it really depends on if you don't have the right foundation, if you don't have the right data models, et cetera, for the agents to kind of run on. ⁓ I feel that could be, ⁓ I think, One easy way of thinking about it is that because there's some probabilistic areas to it, if you're running it ⁓ again and again on the same thing and it's producing different results, that's the failure. Because you're expecting it to... get them the same results or similar results. So how do you ground it in something which is like the right definitions, the right guardrails, and usually when you don't have that is when you start having issues.
Greg Michaelson: Gotcha. Have these agents impacted the way that you hire and the size of your team and the throughput of your coding? How?
Bhaskar: Yeah, 100%. I think this started happening probably around... ⁓ late last year when I think something changed in the end, you might have, must have observed too, right? Like something changed in how good coding agents were and they got to the point where you could give them long running tasks. ⁓ They'll take that time, but produce something like really, really solid. ⁓ And ⁓ so that's when you start, you started realizing that again, you can rely on them. And so that automatically means that you don't need a team as large as you needed before and that's real. That's definitely real.
Greg Michaelson: So if you had to rebuild AppDynamics, what percentage fewer coders would you have needed if you had to rebuild it today? Is it 10 %? Is it 80 %? What's the number?
Bhaskar: Yeah, I think that's a tricky question. I think it depends on sort of like, I would say if I were to pick a number, maybe at least needing 30 to 40 % lesser, or maybe a little bit more. But that's what I would probably go with. But it's a tricky question to start with.
Greg Michaelson: Now, is a data science and data analytics focused coding agent. That's what we do. We're a development environment. And we found that one of the big bottlenecks with trying to use the sort of, I don't know, like CodD and CodeX and all those is that they're not really built for data. They're more built for software engineering. And so there's lots of, you you got to teach the agent what your data looks like and how to, you know, all, there's a lot of overhead in doing that kind of work. Where are the...
Bhaskar: Cool. Yeah. Mm-hmm.
Greg Michaelson: Where are the bottlenecks in terms of what agents are able to do and not able to do today? Like, is it infrastructure? Is it CI, CD? Is it testing? it like, what are the things that still require humans to get in there and get their hands dirty and so on? And what are the things that just work?
Bhaskar: Yeah, No, think that's a really good question. And it's pretty nuanced, like you said. I think what they're able to do is writing code, wiring that up, even starting to test it, et cetera, et cetera. But when you have something finished, really figuring out if that's doing the right thing from a domain point of view, does it have the right context? ⁓ you know, is it sort of like ⁓ using the memory well? So there's a bunch of angles there that when you make it sort of like real world, that's what like really, you know, comes up. But I think they're getting better and better with respect to, so if you look at like, you know, Codex, if you look at like Cloud Code, ⁓ they're really good right now with, you know, writing code, checking in stuff, testing their own thing. ⁓ And testing's also, ⁓ Not just sort of like running some tests running some smoke tests in the background, but when they build apps with the user interface They actually use you know, they actually use computer use to basically ⁓ Open up the UI and actually start testing and looking at like UI that that's a final produced UI, right? So that's almost like way beyond some some kind of a unit test or a system test It's a proper functional test off the product. That's sort of like really ⁓ And so that part is, think, ⁓ pretty solid. I feel like the things that are brittle could just be, you know, you know, the guardrails, the spec that you give it. ⁓ That's where obviously I think ⁓ how you go from like ⁓ a definition of what you want to do to what you build and everything else. That's where you have to be careful. But once you give it something solid, ⁓ I think everything from right the code, wiring it up, deploying it, and then testing it saying, this is actually doing their job, I feel like the agents are really good at that.
Greg Michaelson: Okay, how talk to me about funding. So how old is bicycle and how big are you guys and what's the VC market look like? It's certainly way tighter than it was back in 20, you know the the late 2000s
Bhaskar: Yeah, I think the VC market right now. Yeah, for sure, for sure. Yeah, yeah. The VC market definitely is much tighter because the AI wave has definitely brought about a lot of changes, right? Because ⁓ especially with things like Lovable, Gamma, et cetera, people expect AI products to pretty much do all the heavy lifting and feel magical, right? So that's what the ⁓ VC world definitely thinks about. ⁓ And you're also seeing multiple waves in the VC world as as well, right? Like you started off with like, obviously AI for coding is the biggest chunk of it, right? But then you also have AI SDR that basically does lead generation. You have the AI SRE that basically does, ⁓ you know. ⁓ root cause for technical issues and things like that. AI analytics, which is where we are, is now picking up, is slowly picking up, right? And people are looking at it as that it is gonna be the next evolution of BI because, ⁓ you know. like doing dashboards, doing sort of like all of that ⁓ type of sort of manual analysis ⁓ isn't gonna work, especially with the scale, especially with ⁓ how quick you have to be at decision making versus like looking at all of that. So I feel like. ⁓ We see waves are always based on what's hot right now and ⁓ you see a lot of money going towards it. So it is that typical sort of like waves, right? Outside of obviously the foundation models and the big infrastructure players, the application layer is slowly picking up, but AISRE, AISDR, et cetera, those were the initial waves, but then I think some of the other ones are just about coming right now. Yeah.
Greg Michaelson: And would you call bicycle like AI sales ops or AI, what's AI analytics?
Bhaskar: It's AI analytics. It's AI analytics with a little more of a revenue focus, basically. So that's what I would, yeah. But I would say, yeah, the team's about like 40 people in 30 plus, yeah, 35 to 40. And I think the way we think about what we do is that, look, we're an analytics agent where you're not chatting with it, right? Like it's actually doing, working a queue.
Greg Michaelson: Gotcha. Gotcha. How big's the team? Okay, yeah. All right, awesome.
Bhaskar: ⁓ We like to think about the process that we do as like a loop that the agent is running, right? Like it's detect, explain, act, and learn from what you did. the acronym is DEAL. So detect, explain, act, and learn. ⁓ Versus sort of chatting. Because the chatting part is that you will get answers to questions that you're asking, but what Bicycle is focused on is that how do you get answers before you really ask the questions and be proactive? That's where the operation ⁓ you know mindset comes in from AppDynamics. That's where the revenue focused mindset comes in from AppDynamics. And so that's kind of like our core focus when it comes to that. Yeah.
Greg Michaelson: So you've got agents running all the time.
Bhaskar: We got agents running all the time, yeah. So we have a platform that builds the agents. the way, ⁓ and you relate to this in terms of data consumption, right? So when we think about data consumption, we break it down into three ways someone can consume data, right? So you can either consume insights tactically where you should know immediately when something happens. Like when a revenue drop is happening, you should know immediately. So we call it a tactical insight. ⁓ So that's sort of like the alerts and actions that you can subscribe to. The second part is more strategic. You look at your Monday morning meeting, you look at your weekly reviews, you look at your quarterly reviews, you look at your monthly reviews. That's more of a data narrative or a data story. So comes in neatly packaged as a PowerPoint deck almost. And it has the top insights, but also deep analysis on why something's moving. ⁓ Is it because of spend is down? Is it because of competition? It'll do that analysis, but it'll give you weekly, monthly, whatever. So that's the second type. The third type is ad hoc analysis, which will always stay, because the first two are meant for decision-making, and the ad hoc analysis is basically meant for exploration. So that basically has dashboards, natural language chat, et cetera. So that's how we kind of think about the overall product.
Greg Michaelson: Got it. Now, how do you, I think one of the things that probably is on your radar is sort of managing the costs associated with all those LLM calls. ⁓ Is that a big cost for you guys? How do you think about it? Because, you know.
Bhaskar: Yeah, for sure, for sure. It is yeah, it is but you know, the good news is that there's some good sort of like open source models You know, ⁓ like for example gemma just came out So it's really a question of like how do you use like for example, if you're doing evals if you're doing some of the testing part ⁓ Can you use some of the more open source models cut down the cost? ⁓ And also like when you're doing something like summarization use the lower cost models like like don't use opus for everything in cloud Use use haiku for some of the that stuff So you have to keep like, you know, really figuring out like where do you swap? You can't use the big hammer for everything. And as long as you're doing that and for a bunch of things, you can use the open source stuff as well. So that actually cuts down the cost, but it is one of those things that you have to pay a lot of attention to, right? Like because those bills can get super high. I'm sure you've heard stories.
Greg Michaelson: Well, I mean, it seems like one of the strategies for the big guys anyway, is to use the big hammer for everything and just sort of like figure out the revenue model later and just operated a massive loss. Right? That seems to be what's happening. I think I've read something about Claude Cote, how somebody used up tens of thousands of dollars in credits and paid their $250 a month plan or something like
Bhaskar: Yeah. Yeah. Yeah, yeah, Yeah, unfortunately that is happening. Yeah. Yeah, yeah, I think I read an article about it or something like that, but yeah, you're right.
Greg Michaelson: Yeah, so that seems to be sort of the business model for the moment is just like burn, burn, baby, burn and then, ⁓ you know, figure out the revenue model down the road.
Bhaskar: Yeah. Yeah, absolutely. Yeah, basically. That is definitely helping.
Greg Michaelson: Which you know, I guess has worked in the past
Bhaskar: Yeah, yeah, absolutely. But I think it's also new, everybody's figuring it out and it's moving so fast. It's unbelievable, right? If you're not caught up in the last couple days, you just miss so much. Everything is happening at such a rapid pace ⁓ that it's a great time to innovate at this time. But if you miss something, it's so quick, you can just miss it. Blink. Yeah.
Greg Michaelson: It is an exciting time. Certainly lots of, ⁓ lots of low-hanging fruit in the space.
Bhaskar: Yeah. Yeah, yeah, absolutely.
Greg Michaelson: Well, Bhaskar, what's next for you? I know, I mean, not next after bicycle, but like, what do you see on the horizon in this space for anybody thinking about kind of playing in this space in the startup world or for companies that are kind of like grappling with how to utilize this sort of technology? What kind of advice would you give?
Bhaskar: Yeah. Yeah, I feel like it's a great time for founders right now. this is also from personal experience as well, but one of the hardest things for a founder is to figure out how do you get stuff out of your head and operationalize it? How do you give it to the team? How do you basically really take that and make it more of a product? And with AI, it's become much easier. with early stage is that ⁓ not a lot is documented, there's not a lot of systems, et et cetera. ⁓ But now AI makes it so easy for you can just talk to it and figure out writing a detailed spec, right? And that detailed spec can be an input to a coding agent. ⁓ That can be an input to a design system. ⁓ And then the coding agent can sort of like, you can use that to build sort of like the testing and the eval framework around it. ⁓ You can then start rigging up like go-to-market systems based on that thesis. So we're not too far from the world where you start with like your core thesis and if that is sound and your thesis about architecture, your thesis about like basically, you know, the market, like your ICP, et cetera, et cetera, that can then start producing specifications that can then start producing code that can then start producing go-to-market layers. So I feel like, you know, ⁓ if you're starting now, if you have ideas that you have to completely forget about how existing companies operate and you have to think more about basically how would you start from scratch in the AI world and then assume everything is possible. That's what I've seen with some of when you work with some of the models don't assume it can't do it like it'll surprise you so many times ⁓ and that's why it's I think great for founders. ⁓ So it makes it so easy for you to take stuff out of your heart and used to be a challenge before. Yeah. Yeah. Yeah.
Greg Michaelson: Well, that's great advice and I completely agree. ⁓ At this point, it's become more of trying to understand all of the different facets of the business. I like how well-rounded you are and talking about, ⁓ how are we going to define revenue? What does churn looks like? How do we recognize revenue over time? These are questions that ⁓ most software engineers never ever think about. But now you're thinking about that plus product design and...
Bhaskar: for sure. Yeah. Yeah. Yeah.
Greg Michaelson: and efficiency and you're thinking about reliability and like a founder these days has to sort of like be aware of all that. You can't just be a technical founder or a visionary founder or anything like that because now the models can just do anything and it's just a matter of like riding herd over them. So I think that's great advice.
Bhaskar: Yeah. Mm-hmm. You have to be. Yeah. Yeah. Absolutely. Yeah, yeah, for sure. Yeah, for sure. Yeah, absolutely.
Greg Michaelson: Well, Boscur, thanks so much for taking the time. This has been really fun. It's great to kind of get to know you a bit and hear about what you're working on.
Bhaskar: Thanks for having me, Greg. It was fun.
Bhaskar: Yeah, yeah, absolutely. Cisco acquired us. This was 2017, so it's been a while.
Greg Michaelson: What, when was that? What year was it? Wow, okay, awesome. Well, maybe we start out, just let me get an introduction from you and tell us a bit about AppDynamics. Was that your first startup, AppDynamics?
Bhaskar: Yeah, absolutely. Yeah, I mean, been doing startups before. was one of the founders and ⁓ the ⁓ CTO there. And we started sometime in 2008, and then we exited in 2017. ⁓
Greg Michaelson: Oof, that's a hard time to start, huh?
Bhaskar: pretty busy. It was, was. But you know, one of the things that was happening in 08 was people were looking at optimization. People were looking at sort of like getting their systems sort of like running really well. ⁓ And so we actually, we actually wrote that way. I think it was kind of good to, you know, focus on something that that's making your systems more reliable, that's helping with ⁓ drops in, you know, ⁓ sort of like issues with uptime and loss in revenue, et cetera. So, so that actually really help.
Greg Michaelson: Well, maybe it would be good in case folks aren't familiar with AppDynamics. Can you give people just kind of ⁓ a little quick thumbnail of what the company did and what you built?
Bhaskar: Yo. Yeah, absolutely, absolutely. So we were basically the next generation of ⁓ application performance monitoring at that time. ⁓ And what I mean by that is that the way performance was measured. before AppDynamics was either using CPU, either using how your code is running, how your queries are running, and things like that. And what we came in and said was that, mean, one, applications are getting super distributed. So you can't measure code in like 50 different servers. There's just too much code running. ⁓ Number two, it changes all the time. So if you're looking at a relational query and tomorrow you're using NoSQL, what do do with the old method? So there's a lot of change, ⁓ very distributed and it's hard to pin down what services is doing what. ⁓ And so what we said was, why don't we use a measure that is linking back to the user and we introduce this term called business transaction. So instead of measuring code, instead of measuring CPU, instead of measuring queries, you're basically measuring what's the time login is taking, what's the time checkout is taking, what's the time ⁓ payment is taking. irrespective of the changes, irrespective of how distributed it is, that just links it back to user experience. And that's really what... ⁓ But at the same time, we anchored diagnostics, we anchored... You could drill into a particular payment flow, could drill into a particular checkout flow, and get all sorts of diagnostics right down to the millisecond when something was off. So almost sort of turning on a production profiler for lack
Greg Michaelson: Gotcha.
Bhaskar: a better word on when things were not going wrong. that was the appeal. you're number one appealing to the operations people because this was the time when things were getting at a scale where just the developers couldn't operate. So the operators were operating, but they didn't know the code. So they needed a metric they can anchor on, which they can relate to. And we brought in the whole business transaction thing. And then you could do diagnostics and fix issues. So that was the killer combo.
Greg Michaelson: So less important what my CPU consumption is and more important how long it actually takes to check out in my store. Gotcha.
Bhaskar: Correct. Exactly. Which stands the test of time, right? Like, you know, if you're Amazon and if you've re-architected 10 different times in the last 15 years, what still matters is how much time it takes for checkout. So, sounds obvious now, but wasn't then, Yeah.
Greg Michaelson: And you're not wrong. I that is the most important thing. And it's cool that you guys could capitalize on it. Now, did you have a bunch of pivots along the way or did you guys know from the beginning that that's how you wanted to set up your monitoring scheme?
Bhaskar: ⁓ No, we were actually pretty sure. think we started off being a Java product. We were like very focused on Java and just doing Java APM. And so that actually gave us the focus versus doing too many things at once. We didn't try to jump on to like ⁓ Ruby on Rails or whatever bandwagon at that time. So we're like, let's just do Java. Let's do it really well. ⁓ And we were sure about two things, right? Like that we wanted to help the operations people. And then second, ⁓ We wanted to be running only in production. So if you remember, generally speaking, performance monitoring tools have different versions. Like you run it in dev, you run it in test, you run it in staging, you run it in prod. And usually you take a tool that actually ⁓ has a version in each, right? Like you dial up the knob, you dial down the knob, but it's kind of the same tooling that's working in all environments. And what we said was we only want to sell in production. So if you want to run it in dev, or test, it's gonna be the same money. And so I feel like that was probably the biggest decision that we took that helped us sort of stay true to running a production versus like, ⁓ we're just gonna do like these 20 things. So we definitely focused on that.
Greg Michaelson: Yeah, that seems like reducing friction with customers is a really important thing there. I mean, I guess 2008 was before this whole product-led growth wave that has come and sort of swept over startups. Did that sort of go-to-market approach affect how you guys sold at AppDynamics?
Bhaskar: Yeah. Yeah. I'm glad you asked that question because you know one of the probably the most important thing in our good market that got us attraction was Look, I mean performance monitoring ⁓ Especially when you're using an agent that's inside the app So, you know most performance monitoring works with instrumentation where you're in the app that you're monitoring, right? ⁓ and so that's fairly sort of technical and ⁓ It was one of those things where you would work with the vendor the vendor would sort of like really work with you to install it on your servers and everything else. But one of the things we did was like a year and a half into sort of like building, et cetera, et cetera, we actually launched ⁓ Self-Serve. And what we did was we created a mini version of the product, which I had kind of written up in like a couple of weeks to start with. And we put it up on the website and said, Go download this, you know. It's very low footprint in terms of memory. It's hardly anything to download on your disk. Connect it with your live server and start running it. And you don't need any help from us. Everything is auto-detectable. Everything is sort of automated. And it'll give you value in five minutes. ⁓ There was no other performance monitoring tool at that time which had self-serve, which was accessible, where you could actually start a trial, whether it's on the cloud or whether you download and use it. ⁓ So that gave us a tremendous amount of cred, a lot of confidence. ⁓ Especially because when we started, ⁓ you know, reaching out to people who are downloading and we're looking at the links on who was downloading, cetera. ⁓ People were already confident running it in prod, which really surprised us in the beginning, but because we had written something for prod. ⁓ But that was a strategy. we that really helped us ⁓ almost like 50 to 60 percent of our leads at the time basically started coming in from the self self motion where people are downloading and just using it. So really help us there.
Greg Michaelson: Now was the application monitoring space super noisy back then or were you the kind of first player on the scene in terms of.
Bhaskar: It was pretty, I mean, there were a lot of, you know, in fact, like one of the things in our head when we got into the market was, well, there's a lot of really established vendors. So how do we sort of like really, you know, how saturated is the space? Is it a solved problem? Because you have, you have these questions at the back of your head before you actually go start talking to customers. And when we started talking to customers, ⁓ we discovered that still white space in there because, ⁓ you know, customers were basically either burned by not super stable. Again, if something's running in your app, it can crash you. And that had happened quite a bit with some of the customers. And so it wasn't a solved problem. And that's what we discovered, that it's still pretty old school, still working on CPU and code and everything else. Every change needed a restart, stuff like that. So we kind of broke the whole system in terms of saying, this is the next generation. And that's when we, I think, transformed that space.
Greg Michaelson: Right? Got it, so you kind of like rethought the whole paradigm of how to monitor by changing the metrics that were important. Yeah.
Bhaskar: for sure. Yeah, exactly. Exactly. We anchored on something that's more that's more businessy versus like, ⁓ let's look at like 100 at a time.
Greg Michaelson: Now, when Cisco bought you guys, tell me about that. What was that like? That was a huge number.
Bhaskar: Yeah. Yeah, it was a huge number. So I think what was happening at that time was that Cisco was actually a customer of ours, right? Like Cisco, Cisco IT, Cisco was using AppDynamics and was very happy with the product. we were, you know, we had filed an S1, we were like, you know, on the path to to an IPO. In fact, like most of the team was in New York to go ring the bell, you know, and just basically a couple days away from doing that. ⁓ We had the, yeah, absolutely. ⁓ We had the discussion sort of in the background ⁓ and I think Cisco, as it was starting to think more and more about software, got very serious about it. But a lot of it, the foundation was how much they loved the product as customers.
Greg Michaelson: No kidding.
Bhaskar: That was the starting point. And so it was pretty last minute. People were already in New York. They were already in New York to go ring the bell at NASDAQ. And so we told them, this is what happened. Because the numbers were really good. We looked at the overall climate. We felt like this is sort of the right thing to do. But yeah, that was a little bit of a dramatic, dramatic story there. Yeah.
Greg Michaelson: Yeah. Yeah, I feel like a lot of these IPO stories could be movies.
Bhaskar: They could be absolutely, you're right.
Greg Michaelson: All right, so you finish up at AppDynamics and what do you go on to next?
Bhaskar: Yeah, I mean, I took a little bit of a break. then the thing I had in my head was basically the whole signal to action journey was very like it's something that I really enjoyed. A lot of things that we learned at Abdee in terms of understanding, monitoring the whole culture of like operations and everything else, that was really amazing. But then I think I... The thing that really sort of stuck with me was that, how do you sort of like move up the chain, ⁓ right? So when we were at Abdee, one of the products that we released that was a little bit later in the cycle was a product called Business IQ. And what it did was... When something goes wrong, like when there's an outage, for example, ⁓ it was calculating what was the business impact, right? So it's like who got affected, what type of customers. ⁓ You know, if it's a retail scenario, like could we actually just give them like a gift card or something like that. It's like calculating impact of an outage. ⁓ and that got me thinking, you know, over time and especially, you know, during the break on like, how do we sort of like, ⁓ not do it after the fact, but think of it as, ⁓ can we, can we build like an operating sort of system that's sort of anchoring on those key cohorts, business KPIs, business, ⁓ you know, KPI slices. So for example revenue by my top city revenue by my top product things like that Can you anchor on those and build that as the business signal so that? When you detect sort of anomalies etc etc, then you can do the analysis then you can go go to whatever you need to ⁓ So that's sort of the link between them ⁓ and ⁓ You know what we ended up building initially was building a system that was doing exactly that But one of the things that wasn't super optimal in it is that how do you ⁓ feed all the system with the business definitions, the business model, and everything else? Because you don't want to be running a bunch of queries on a warehouse and trying to figure a bunch of stuff out. You want to model a business. You want to of understand how do you go from ⁓ detecting a signal to why it's really happening? And so you want a system ⁓ modeled. So when we did that, ⁓ yeah, good.
Greg Michaelson: Now when you say we, you're talking about bicycle now, not AppDynamics anymore, yeah? Okay, okay, just wanted to make sure. Bicycle.ai. Okay, okay, go ahead.
Bhaskar: Bicycle, yeah, correct, correct, correct. yeah, yeah, yeah. Bicycle, yeah, yeah, absolutely. ⁓ Yeah, just to answer your question in a short way again, think ⁓ post sort of like the exit, I stuck around for a little bit, then sort of like was consulting even with Abdi for a little bit once I started being full time, then I took a little bit of a break and then started building bicycle. And I was actually starting to go into the journey of bicycle, but we can talk more about that later.
Greg Michaelson: Yeah, yeah, no, I'm super interested in that. So when you talk about the sort of sales operation monitoring type stuff, is that all linked to like server health and monitoring applications as well, or is it more business focused? How does it work?
Bhaskar: So think about it this way, right? Like when you have a business KPI, like a drop in revenue or something like that. ⁓ You know could be a drop in conversion could be drop in approval rates, you know when you take a payment use case ⁓ The root cause of it could be multiple things, right? It could be because you have a technical problem, right? Like where you know people are not able to you know Just click on the checkout button for whatever reason because you know, the UI is not loading or something like that It could be a server issue. It could be like something changed for a particular version, but it could also be a pricing issue It could be a competition It could be an inventory issue. It could be a stock out issue. So all of these factors line up. And typically you have the different parts of it where a signal can be attributed to both sort of technical factors as well as the business factors. That's actually one of the reasons why, so they're the two wheels that run the business and bicycle is like the data drive train that connects them and that's why we call it bicycle. being able to...
Greg Michaelson: Gotcha.
Bhaskar: Being able to look at both factors ⁓ and being holistic about it versus saying, yeah, it could just be a technical problem and looking just at the technical layer, that's really the story for us.
Greg Michaelson: Gotcha. Okay, so Zerve, my company, we're a software, a data-focused agentic coding environment, and we have a self-serve type model where people can go on the website and sign up and get a free account and then upgrade to a paid account and so on. If I wanted to plug in something like Bicycle into our business, are we too small for that? Or is there some sort of scale that's required? How would I go about thinking about it? Like, sell me here.
Bhaskar: Mm-hmm. Yeah. Yeah, mean, I think it's, yeah, absolutely. So it's actually pretty straightforward. What you do is ⁓ usually you start from the source of truth, like, so let's say you have a warehouse where all the data is, right? ⁓ You connect bicycle to that, right? Like it could be take a BigQuery, take a Snowflake. ⁓
Greg Michaelson: you to like post hog or something like that. Yeah. ⁓ dump it to a warehouse. I see. I gotcha. Okay.
Bhaskar: More a warehouse, just because we're looking at the core business metrics and everything else. So let's say you have all of that in Snowflake or BigQuery or Redshift or something like that. You can start with that. We also do streaming systems. So if you have something like Kafka in the background, so we could connect with that as well. So that's our core usual source of truth. What we'll do is we have an agent that then will onboard the data from there. ⁓ We'll take context from you on what the company is, what it does, et cetera.
Greg Michaelson: Mm-hmm. Mm-hmm.
Bhaskar: So bicycle system, think about it as how LLMs and machine learning are basically working together. So think of bicycle as a business analyst and a data analyst in a box. So the LLM functions as a business analyst and the machine learning basically, the AutoML functions as a data analyst. Because you don't want the LLMs doing the math. Right. Anything that's sort of like solid math, you want that to be sort of like machine learning or anything that's solid. Anything that's probabilistic where you're like, ⁓ why is revenue dropping? you want to hypothesize, then you want to figure out why that's happening. That's more of the ⁓ ML. So going back to the setup, we will onboard the data. The LLM will help sort of map definitions and things like that and set up data so you don't have to do a lot of heavy lifting. We'll do the 80, 85 % of the work in the initial setup, setting up your KPIs, setting up your slices, dimensions, all of that. ⁓ And then what we do is we have ⁓ you on top of the model, on top of that ontology we create, we basically start running the machine learning pieces. ⁓ And what the machine learning will do is think of, let's say again, take a very simple example. Let's say you're looking at revenue by 100 different cities. So we will have an individual model for all the 100 cities so that we can actually track baselines, track sort of like anomalies and everything else. And so that's an example pattern. And when the pattern goes off saying, revenue is dropping, ⁓ our agent would then start looking at both technical factors and... ⁓ business factors like I was saying like is it pricing is it sort of like performance ⁓ is it like you know competitive pressure is it something external saying like ⁓ you know maybe it's happening because ⁓ you know it's it's a holiday and people are not buying tickets or something like that right so it will look at all of those and then it'll give you a brief it'll give you like recommended actions so that's the overall setup but it's a pretty low lift you know on top of that we do focus on transactions
Greg Michaelson: Mm-hmm. Mm-hmm. Mm-hmm.
Bhaskar: businesses, that's our sweet spot. you know, take retail, take payments, take, you know, take travel, because that's where the sense of urgency to convert insights, you know, into decisions is the highest. And we wanted to focus on that. And we think of ourselves as a vertical solution.
Greg Michaelson: How would you find where would the competitive data come from if say there is a new a new competitor suddenly appeared? How would you know that in your in your system? Are you?
Bhaskar: Yeah. You know, it's typically the agent basically doing web search, looking at like sort of, you know, the data of the internet. So again, being agentic, having access to everything that a modern agent has. And so we'll basically analyze that. But we have a lot of context on what we're doing. So that kind of feeds it in. And so that's going to be part of the analysis.
Greg Michaelson: Got it. Now developing the agent, how was that? We're still in the new days, kind of the early days of ⁓ agentic analysis. What were some of the hurdles that you came across?
Bhaskar: Yeah. Yeah. Yeah, no, think understanding really the, ⁓ if you think about sort of like the analytics agent, the way I kind of looked at the sort of different pieces involved, right? So for example, ⁓ there's the model you're using, there's the data, there's the metric definitions, there's the ownership model, because again, when you're deploying it in an enterprise then... It is basically multiple people who own it. ⁓ The models always, people always look at the model because that's the decision maker and that's the glamorous part. But when issues happen, they usually happen upstream.
Greg Michaelson: Mm-hmm.
Bhaskar: the agent can only be as trustworthy ⁓ as the metric definitions and the ownership structure. For example, if nobody agrees on what revenue means or what is the failed payment or what's a retry, ⁓ the model will just end up confusing you ⁓ and then ⁓ the ownership will bite you. The system may be right, but it might route the issue to the wrong team and eventually it didn't help. You know, and then also there's data freshness where one feeds updating every minute, the others operating next day. So so things like that, right? ⁓ So sometimes what happens is a model will say approvals are healthy, because it's just using the wrong definition ⁓ while the business is looking at like a different way of looking at it, right? instead of like say it is actually a semantic failure, but it's sometimes looked at ⁓ as a model failure. So that's the layer I feel like is the harder one to build because ⁓ especially in the age of AI people, in the details, because in the age of AI people expect a plugin and it just works magically. Even if there's a lot of ambiguity to figure out in the semantics.
Greg Michaelson: Sure. Yeah. The devil's in the details.
Bhaskar: so I'm like, what should I pick? Because I see like four definitions.
Greg Michaelson: Right. And most, yeah, there's most of them, even on the business side, nobody really agrees on the definitions of everything. Yeah. Gotcha. And then in terms of ⁓ feeding back what's what seems to be going on and proposing actions to take, that seems hard. Right. Finding those business actions, because typically in analyses like these, results are kind of like
Bhaskar: Yeah. Correct. Correct, correct. Exactly. Yeah. Mm-hmm. Yeah.
Greg Michaelson: Not trivial, but like you tell me something, ⁓ this is happening because of X, but X, there's nothing I can do about X. You know what I mean? So how do you, how do you sort of navigate that?
Bhaskar: Yeah, yeah, yeah, yeah, yeah. Yeah. So I feel like, and this is again, something ⁓ from the AppDee story as well, but an alert should be not the beginning of triaging it, but it should be the end of triaging it, right? Because when we think about alerts, sometimes they're paging people too early, right? And if all the alert is saying is the metric is down, it doesn't really help, right? Because you're just offloading work. ⁓ I feel like the right pattern is, ⁓ detect, then auto triage and ⁓ find out some sort of thesis and then notify when you have something useful. I ⁓ like to think about a useful alert as having five things. ⁓ What changed? ⁓ Number two, where is it concentrated? What is the impact? How big it is? Number three, what likely changed around the same time?
Greg Michaelson: you
Bhaskar: and who should care. Right? So without that, if you're just sort of like throwing something out there on this is up, this is down, that's kind of the, you know, not as useful, right? And the other big thing is that you have to use business thresholds and not statistical thresholds. Again, like a good lesson we learned from, from MAPD because you have to... know, create a threshold for it. So let's say you have a product ⁓ that ⁓ has really high traffic, know, a of transactions without traffic. And you have a product that, you know, has much, much lesser traffic. The way you calculate thresholds for them is very different because you have density of data and how you calculate that for the... high selling product versus the other one is very different. So that's where you have to bring in the business angle and not just statistical part of it. You also have to think about what is a noisy alert and when you have to do it. Do you say, oh, it has to have at least this revenue for it to be meaningful for me to take a look at it. And that's all bringing in the business definitions and it has to have meaningful impact. But the bottom line is, mean, you know, don't just say that, hey, you know, your credit card approvals are, you know, whatever percent overall moved, but be very specific on like, that is a particular issuer segment are most likely try to tie to a, you know, a route specific issue and it's not sort of systemic. That's the way to sort of like really alert people. Yeah.
Greg Michaelson: It is interesting to think about these kind of softer, more businessy type problems in kind of a more engineering type context. I love how the nerds are sort of taking over. There's a friend of mine, his name is Jeff Schwartz, and he started a company called Data Room HQ. they've been around for a couple of...
Bhaskar: Yeah. Mm-hmm. Yeah. Mm-hmm. ⁓ nice, we're good.
Greg Michaelson: Wow, like five or six years now. And they do ⁓ kind of like more like when you're raising, having a data room ready and being able to look at, you know, like a constant snapshot, like an instant snapshot of what your business metrics look like. And they take it on from a very sort of engineering based perspective as well. Do you think that that sort of way of looking at things, like let's look at it like scientists, like engineers, like very technical people?
Bhaskar: Sure. Yeah. Yeah.
Greg Michaelson: even though it's traditionally more of a softer domain. Do you think a lot of that is happening because of the rise of these coding agents and the ease at which it is, how much easier it's become to build these kinds of things? What's pushing that trend?
Bhaskar: Yeah. Yeah. Yeah, I feel like, you know, breaking down a problem statement into sort of like, again, you know. What's sort of the math to it? What's sort of the interpretation to it? Can you then give the interpretation to like a model? Can you sort of like then sort out the sort of math? ⁓ But breaking down such a nuanced problem into, ⁓ you know, smaller units and applying different parts of AI to it, applying different parts of ML to it, at least in my head, that's how I think about it, just being an engineer. And I relate to it and I can understand you know, especially to your point, because the coding agent, if you know, and I love that strategy of how a coding agent basically defines overall strategy and everything you're doing, you know, whether you're basically building a website, whether you're building an app, whether you're sort of like solving a problem, ⁓ you, solve it with code because code's a very logical way of breaking down a problem. Like you write a routine, you write another routine, you connect them together. ⁓ the logic in one routine and the other one, you know, it's very different, right? like and some one of them can be hypothesis, one of them can be deterministic. ⁓ And so I feel like that that lends itself really well to solving, you know, very nuanced problems, ⁓ especially when they can be, ⁓ you know, ⁓ a lot of like, organizational boundaries and this and that and everything else. And so how do you sort of break it down into something simpler? Does that make sense? Yeah.
Greg Michaelson: It does. ⁓ I'm curious in particular about how you guys are using, like say, do you guys use Cloud Code or Copilot or any of these coding agents in your development work?
Bhaskar: video. Yeah, we do use Cloud Code. So we use both Anthropic and OpenAI, but we do use Cloud Code quite a bit.
Greg Michaelson: Yeah. Yeah. So you've been an engineering manager, manager of engineers, software engineers who are developing ⁓ real, intense production grade enterprise level software for years, decades now. And it feels like the whole coding agent thing is a bit of a seismic shift in terms of the way things work. Do you see it as transformative as that? And how has it impacted the way that you think about development?
Bhaskar: Mm-hmm. Mm-hmm. Yeah. Yeah, absolutely. Yeah. Yeah. Yeah, mean, 100 % right. Like I think ⁓ one of the things that people talk about right now is that ⁓ code is not the bottleneck anymore. ⁓ Design is. What you want to do, what you want to build, how you want to build it, that is really the bottleneck. actually, like writing code for it isn't basically the bottom line anymore, which I kind of like, right? Like, because it makes the problem a lot more creative versus just operational. ⁓ So it's almost like what the... ⁓ Industrial Revolution did do like fabrication or just like creating of or manufacturing something right because machines could do it You know and machine and humans used to do it But then what became more interesting was what do you want to build and what do you want to fabricate? What's this? Like, you know, so it's very very similar right like the the core part is not that important but ⁓ But obviously you want to have the right plan, want to have, you know, want to build something robust, which the coding agents can do. They write really good code, right? ⁓ But what's more important is what do want to build? How do you want to build it? What's the design? What's the problem you're solving? So it's a good sort of step in that direction.
Greg Michaelson: So coding agents are like the assembly line for the software engineer.
Bhaskar: Pretty much, Exactly. Yeah. Yeah.
Greg Michaelson: Yeah. Now, where do they break? So when you're working on a large complex system like that, at some point you run into, okay, the context is too complicated. The agent keeps forgetting how things work. It's like, what are the limitations of coding agents today when it comes to building real complex systems?
Bhaskar: Thank you. Yeah, I mean, I think the thing is like when you have coding agents and you have agents when you have like these probabilistic sort of like systems, you have to have the right evals. You have to have the right structure to basically say, how do I evaluate this is good or not? Right. So like, how do you measure it? Right. Like that's the key thing. And a lot of times, you know, that's, that's not something people are, you know, paying a lot of attention to, attention to, right. Because for an agent to look smart, for 10 minutes is super easy. But when you think about, ⁓ know, just on like a random Tuesday or Wednesday, ⁓ it's unambiguous, it's clear, and it's providing value. Like that's what it's about, right? At some point when it gets boring, that's when it's become useful. ⁓ Not like a 10 minute demo where it's like, ⁓ you know, I'm coming up with like a cool like demo using an LLM. So that's the part, that's the hard part. And I think ⁓ You know, things like evals, obviously having a sound ⁓ model you're working on top of ⁓ versus just running the agent in different loops without a strong model, that's the starting point. But evals are important. So for example, if you're detecting something, ⁓ what you have to evaluate is did we notice a meaningful issue fast enough? ⁓ So you look at precision, you look at time to detect, you look at false positives, you look at false negatives. negatives, et cetera. Then you're diagnosing. So once the agent is flagging something, ⁓ did it pick the right slice? Is this the right concentration? ⁓ Did it pick up the right drivers, which could be driving it? ⁓ Was the actual issue, yeah.
Greg Michaelson: ⁓ so you're you're talking more about using agents as data analysis. I was thinking more about using agents as software engineers to actually build the code of the application. Yes. That's OK.
Bhaskar: Yo. So there's sort of link, you're right, like I think I was kind of digressing a little bit, but there's sort of like, what I mean by that is that, you know, if you, ⁓ when you build something, the way you evaluate it is the most important thing. ⁓ In terms of just answering sort of like maybe, ⁓ you know, where the break, it really depends on if you don't have the right foundation, if you don't have the right data models, et cetera, for the agents to kind of run on. ⁓ I feel that could be, ⁓ I think, One easy way of thinking about it is that because there's some probabilistic areas to it, if you're running it ⁓ again and again on the same thing and it's producing different results, that's the failure. Because you're expecting it to... get them the same results or similar results. So how do you ground it in something which is like the right definitions, the right guardrails, and usually when you don't have that is when you start having issues.
Greg Michaelson: Gotcha. Have these agents impacted the way that you hire and the size of your team and the throughput of your coding? How?
Bhaskar: Yeah, 100%. I think this started happening probably around... ⁓ late last year when I think something changed in the end, you might have, must have observed too, right? Like something changed in how good coding agents were and they got to the point where you could give them long running tasks. ⁓ They'll take that time, but produce something like really, really solid. ⁓ And ⁓ so that's when you start, you started realizing that again, you can rely on them. And so that automatically means that you don't need a team as large as you needed before and that's real. That's definitely real.
Greg Michaelson: So if you had to rebuild AppDynamics, what percentage fewer coders would you have needed if you had to rebuild it today? Is it 10 %? Is it 80 %? What's the number?
Bhaskar: Yeah, I think that's a tricky question. I think it depends on sort of like, I would say if I were to pick a number, maybe at least needing 30 to 40 % lesser, or maybe a little bit more. But that's what I would probably go with. But it's a tricky question to start with.
Greg Michaelson: Now, is a data science and data analytics focused coding agent. That's what we do. We're a development environment. And we found that one of the big bottlenecks with trying to use the sort of, I don't know, like CodD and CodeX and all those is that they're not really built for data. They're more built for software engineering. And so there's lots of, you you got to teach the agent what your data looks like and how to, you know, all, there's a lot of overhead in doing that kind of work. Where are the...
Bhaskar: Cool. Yeah. Mm-hmm.
Greg Michaelson: Where are the bottlenecks in terms of what agents are able to do and not able to do today? Like, is it infrastructure? Is it CI, CD? Is it testing? it like, what are the things that still require humans to get in there and get their hands dirty and so on? And what are the things that just work?
Bhaskar: Yeah, No, think that's a really good question. And it's pretty nuanced, like you said. I think what they're able to do is writing code, wiring that up, even starting to test it, et cetera, et cetera. But when you have something finished, really figuring out if that's doing the right thing from a domain point of view, does it have the right context? ⁓ you know, is it sort of like ⁓ using the memory well? So there's a bunch of angles there that when you make it sort of like real world, that's what like really, you know, comes up. But I think they're getting better and better with respect to, so if you look at like, you know, Codex, if you look at like Cloud Code, ⁓ they're really good right now with, you know, writing code, checking in stuff, testing their own thing. ⁓ And testing's also, ⁓ Not just sort of like running some tests running some smoke tests in the background, but when they build apps with the user interface They actually use you know, they actually use computer use to basically ⁓ Open up the UI and actually start testing and looking at like UI that that's a final produced UI, right? So that's almost like way beyond some some kind of a unit test or a system test It's a proper functional test off the product. That's sort of like really ⁓ And so that part is, think, ⁓ pretty solid. I feel like the things that are brittle could just be, you know, you know, the guardrails, the spec that you give it. ⁓ That's where obviously I think ⁓ how you go from like ⁓ a definition of what you want to do to what you build and everything else. That's where you have to be careful. But once you give it something solid, ⁓ I think everything from right the code, wiring it up, deploying it, and then testing it saying, this is actually doing their job, I feel like the agents are really good at that.
Greg Michaelson: Okay, how talk to me about funding. So how old is bicycle and how big are you guys and what's the VC market look like? It's certainly way tighter than it was back in 20, you know the the late 2000s
Bhaskar: Yeah, I think the VC market right now. Yeah, for sure, for sure. Yeah, yeah. The VC market definitely is much tighter because the AI wave has definitely brought about a lot of changes, right? Because ⁓ especially with things like Lovable, Gamma, et cetera, people expect AI products to pretty much do all the heavy lifting and feel magical, right? So that's what the ⁓ VC world definitely thinks about. ⁓ And you're also seeing multiple waves in the VC world as as well, right? Like you started off with like, obviously AI for coding is the biggest chunk of it, right? But then you also have AI SDR that basically does lead generation. You have the AI SRE that basically does, ⁓ you know. ⁓ root cause for technical issues and things like that. AI analytics, which is where we are, is now picking up, is slowly picking up, right? And people are looking at it as that it is gonna be the next evolution of BI because, ⁓ you know. like doing dashboards, doing sort of like all of that ⁓ type of sort of manual analysis ⁓ isn't gonna work, especially with the scale, especially with ⁓ how quick you have to be at decision making versus like looking at all of that. So I feel like. ⁓ We see waves are always based on what's hot right now and ⁓ you see a lot of money going towards it. So it is that typical sort of like waves, right? Outside of obviously the foundation models and the big infrastructure players, the application layer is slowly picking up, but AISRE, AISDR, et cetera, those were the initial waves, but then I think some of the other ones are just about coming right now. Yeah.
Greg Michaelson: And would you call bicycle like AI sales ops or AI, what's AI analytics?
Bhaskar: It's AI analytics. It's AI analytics with a little more of a revenue focus, basically. So that's what I would, yeah. But I would say, yeah, the team's about like 40 people in 30 plus, yeah, 35 to 40. And I think the way we think about what we do is that, look, we're an analytics agent where you're not chatting with it, right? Like it's actually doing, working a queue.
Greg Michaelson: Gotcha. Gotcha. How big's the team? Okay, yeah. All right, awesome.
Bhaskar: ⁓ We like to think about the process that we do as like a loop that the agent is running, right? Like it's detect, explain, act, and learn from what you did. the acronym is DEAL. So detect, explain, act, and learn. ⁓ Versus sort of chatting. Because the chatting part is that you will get answers to questions that you're asking, but what Bicycle is focused on is that how do you get answers before you really ask the questions and be proactive? That's where the operation ⁓ you know mindset comes in from AppDynamics. That's where the revenue focused mindset comes in from AppDynamics. And so that's kind of like our core focus when it comes to that. Yeah.
Greg Michaelson: So you've got agents running all the time.
Bhaskar: We got agents running all the time, yeah. So we have a platform that builds the agents. the way, ⁓ and you relate to this in terms of data consumption, right? So when we think about data consumption, we break it down into three ways someone can consume data, right? So you can either consume insights tactically where you should know immediately when something happens. Like when a revenue drop is happening, you should know immediately. So we call it a tactical insight. ⁓ So that's sort of like the alerts and actions that you can subscribe to. The second part is more strategic. You look at your Monday morning meeting, you look at your weekly reviews, you look at your quarterly reviews, you look at your monthly reviews. That's more of a data narrative or a data story. So comes in neatly packaged as a PowerPoint deck almost. And it has the top insights, but also deep analysis on why something's moving. ⁓ Is it because of spend is down? Is it because of competition? It'll do that analysis, but it'll give you weekly, monthly, whatever. So that's the second type. The third type is ad hoc analysis, which will always stay, because the first two are meant for decision-making, and the ad hoc analysis is basically meant for exploration. So that basically has dashboards, natural language chat, et cetera. So that's how we kind of think about the overall product.
Greg Michaelson: Got it. Now, how do you, I think one of the things that probably is on your radar is sort of managing the costs associated with all those LLM calls. ⁓ Is that a big cost for you guys? How do you think about it? Because, you know.
Bhaskar: Yeah, for sure, for sure. It is yeah, it is but you know, the good news is that there's some good sort of like open source models You know, ⁓ like for example gemma just came out So it's really a question of like how do you use like for example, if you're doing evals if you're doing some of the testing part ⁓ Can you use some of the more open source models cut down the cost? ⁓ And also like when you're doing something like summarization use the lower cost models like like don't use opus for everything in cloud Use use haiku for some of the that stuff So you have to keep like, you know, really figuring out like where do you swap? You can't use the big hammer for everything. And as long as you're doing that and for a bunch of things, you can use the open source stuff as well. So that actually cuts down the cost, but it is one of those things that you have to pay a lot of attention to, right? Like because those bills can get super high. I'm sure you've heard stories.
Greg Michaelson: Well, I mean, it seems like one of the strategies for the big guys anyway, is to use the big hammer for everything and just sort of like figure out the revenue model later and just operated a massive loss. Right? That seems to be what's happening. I think I've read something about Claude Cote, how somebody used up tens of thousands of dollars in credits and paid their $250 a month plan or something like
Bhaskar: Yeah. Yeah. Yeah, yeah, Yeah, unfortunately that is happening. Yeah. Yeah, yeah, I think I read an article about it or something like that, but yeah, you're right.
Greg Michaelson: Yeah, so that seems to be sort of the business model for the moment is just like burn, burn, baby, burn and then, ⁓ you know, figure out the revenue model down the road.
Bhaskar: Yeah. Yeah, absolutely. Yeah, basically. That is definitely helping.
Greg Michaelson: Which you know, I guess has worked in the past
Bhaskar: Yeah, yeah, absolutely. But I think it's also new, everybody's figuring it out and it's moving so fast. It's unbelievable, right? If you're not caught up in the last couple days, you just miss so much. Everything is happening at such a rapid pace ⁓ that it's a great time to innovate at this time. But if you miss something, it's so quick, you can just miss it. Blink. Yeah.
Greg Michaelson: It is an exciting time. Certainly lots of, ⁓ lots of low-hanging fruit in the space.
Bhaskar: Yeah. Yeah, yeah, absolutely.
Greg Michaelson: Well, Bhaskar, what's next for you? I know, I mean, not next after bicycle, but like, what do you see on the horizon in this space for anybody thinking about kind of playing in this space in the startup world or for companies that are kind of like grappling with how to utilize this sort of technology? What kind of advice would you give?
Bhaskar: Yeah. Yeah, I feel like it's a great time for founders right now. this is also from personal experience as well, but one of the hardest things for a founder is to figure out how do you get stuff out of your head and operationalize it? How do you give it to the team? How do you basically really take that and make it more of a product? And with AI, it's become much easier. with early stage is that ⁓ not a lot is documented, there's not a lot of systems, et et cetera. ⁓ But now AI makes it so easy for you can just talk to it and figure out writing a detailed spec, right? And that detailed spec can be an input to a coding agent. ⁓ That can be an input to a design system. ⁓ And then the coding agent can sort of like, you can use that to build sort of like the testing and the eval framework around it. ⁓ You can then start rigging up like go-to-market systems based on that thesis. So we're not too far from the world where you start with like your core thesis and if that is sound and your thesis about architecture, your thesis about like basically, you know, the market, like your ICP, et cetera, et cetera, that can then start producing specifications that can then start producing code that can then start producing go-to-market layers. So I feel like, you know, ⁓ if you're starting now, if you have ideas that you have to completely forget about how existing companies operate and you have to think more about basically how would you start from scratch in the AI world and then assume everything is possible. That's what I've seen with some of when you work with some of the models don't assume it can't do it like it'll surprise you so many times ⁓ and that's why it's I think great for founders. ⁓ So it makes it so easy for you to take stuff out of your heart and used to be a challenge before. Yeah. Yeah. Yeah.
Greg Michaelson: Well, that's great advice and I completely agree. ⁓ At this point, it's become more of trying to understand all of the different facets of the business. I like how well-rounded you are and talking about, ⁓ how are we going to define revenue? What does churn looks like? How do we recognize revenue over time? These are questions that ⁓ most software engineers never ever think about. But now you're thinking about that plus product design and...
Bhaskar: for sure. Yeah. Yeah. Yeah.
Greg Michaelson: and efficiency and you're thinking about reliability and like a founder these days has to sort of like be aware of all that. You can't just be a technical founder or a visionary founder or anything like that because now the models can just do anything and it's just a matter of like riding herd over them. So I think that's great advice.
Bhaskar: Yeah. Mm-hmm. You have to be. Yeah. Yeah. Absolutely. Yeah, yeah, for sure. Yeah, for sure. Yeah, absolutely.
Greg Michaelson: Well, Boscur, thanks so much for taking the time. This has been really fun. It's great to kind of get to know you a bit and hear about what you're working on.
Bhaskar: Thanks for having me, Greg. It was fun.
