S12 Bonus: The Dashboard Mirage: Why Aggregate Metrics Hide Revenue Leaks and the Rise of Autonomous, Agentic Analytics with Bhaskar Sunkara, Founder & CEO of Bicycle AI
Bhaskar Sunkara grew up in Delhi, India, and moved to the states when he started working. He has lived in San Fransisco for several decades now, and has spent a lot of his professional life building systems (infrastructure, observability and now, analytics). His prior startup, AppDynamics, was eventually acquired by Cisco. In general, he stays curious about how things work, and likes to deconstruct systems to figure out how they work. Outside of tech, he is a big sports fan, enjoying football, baseball, cricket and basketball. In fact, he grew up watching Michael Jordan and the bulls.
Bhaskar noticed that business teams were drowning in dashboards, and as such, were not sure how to take the next steps in the business. He and his team realized that what people needed was not a retroactive view, but a proactive one - something more akin to a 24x7 analyst.
This is the creation story of Bicycle AI.
Sponsors
Links
Our Sponsors:
* Check out Cash App and use my code CASHAPP10 for a great deal: https://cash.app
* Check out Plaud AI and use my code CODESTORY for a great deal: https://plaud.ai
Advertising Inquiries: https://redcircle.com/brands
Privacy & Opt-Out: https://redcircle.com/privacy
[SPEAKER_01]: We started with a much narrower problem, can we detect important KPI movements and help explain the faster than a team doing it manually, right?
[SPEAKER_01]: The three things that we focused on, it's the number one, connect to customer data.
[SPEAKER_01]: So, second, define the KPI properly, sounds boring, but actually if you think about it, it's one of the hardest parts.
[SPEAKER_01]: And number three, once the KPI moves automatically search across the dimensions that could be causing it.
[SPEAKER_01]: So that could be device, region, suppliers, customer segments, campaigns, gateways, but look at whatever matters for the business and turn a figure out why this is happening.
[SPEAKER_01]: My name is Masquer Sunkara, and I'm the co-founder and CEO at Pyskleeak.
[SPEAKER_03]: This is code story.
[SPEAKER_03]: a podcast bringing you interviews with tech visionaries.
[SPEAKER_03]: Six, six months moonlighting goes.
[SPEAKER_03]: It's the last and all of the backgrounds who share what it takes to change an industry.
[SPEAKER_00]: I don't exactly know what to do.
[SPEAKER_03]: It doesn't go as to get right.
[SPEAKER_02]: who built the teams that have their bad company is its team's help each other, which is proud of our team.
[SPEAKER_03]: Keeping scalability top of mind, all that infrastructure was up there.
[SPEAKER_03]: Yes, we've been fighting it as we grew up.
[SPEAKER_03]: Total waste of time.
[SPEAKER_03]: The stories you don't read in the headlines.
[SPEAKER_02]: It's not an easy thing to achieve.
[SPEAKER_03]: To get yourself a deficit of off, try to begin to ride the ups and downs of the start-up line.
[SPEAKER_02]: Need to really want it.
[SPEAKER_03]: Not just about technology.
[SPEAKER_03]: All this and more on code story.
[SPEAKER_03]: I'm your host, Noah Labpart.
[SPEAKER_03]: And today, help Vascar's and Cara, has built the best agentic analytics platform, using AI to drive revenue acceleration.
[SPEAKER_03]: Baskar, Sunkara, grew up in Delhi, India, and moved to the states when he started working.
[SPEAKER_03]: He has lived in San Francisco for several decades now and has spent a lot of his professional life building systems, infrastructure, observability, and now analytics.
[SPEAKER_03]: His prior startup, App Dynamics, was eventually acquired by Cisco.
[SPEAKER_03]: In general, he stays curious about how things work and likes to deconstruct systems to figure them out.
[SPEAKER_03]: Outside of Tech, he's a big sports fan and joined football, baseball, cricket, and basketball.
[SPEAKER_03]: In fact, he grew up watching Michael Jordan and the Bulls.
[SPEAKER_03]: Buskart noticed that revenue teams were drowning in dashboards, and as such were not sure what next steps to take in their business.
[SPEAKER_03]: He and his team realized that what people needed was not a retroactive view of revenue, but a proactive one, something more akin to a 24-7 analyst.
[SPEAKER_03]: This is the creation story of Bicycle AI.
[SPEAKER_01]: The brief behind the story about Bicycle is that it came from a very simple observation, right?
[SPEAKER_01]: Business teams are drowning in dashboards, but they still don't know what changed.
[SPEAKER_01]: Why did it change?
[SPEAKER_01]: And what they should do.
[SPEAKER_01]: So my background obviously I was one of the founders at App Dynamics and where we actually help
[SPEAKER_01]: technical teams, both operations and engineering teams, understand complex offer systems and understand how to go from seeing technical signals like high latency or high error rate to actioning them like what we should do to fix those.
[SPEAKER_01]: But with bicycle we're applying the same muscle
[SPEAKER_01]: do revenue teams, revenue teams, analysts would basically working on that.
[SPEAKER_01]: But if we focus on retail travel and payments, it's called verticals where a small KPI movement can mean real money, right?
[SPEAKER_01]: So the product is not a chart with your data, but it's an AI analyst that continuously watches revenue critical KPI's, but then investigates, why is it really happening and then helps teams take safe next steps?
[SPEAKER_01]: In terms of how we got started, building it, we started around the idea that the analytical work should be much more proactive, right?
[SPEAKER_01]: Not another dashboard, not just a chatbot.
[SPEAKER_01]: More an analyst that's always working.
[SPEAKER_01]: It watches the KPIs that matter, finds the segments that explain the moment, movement, posts and signals, and the actual systems.
[SPEAKER_01]: But definitely the starting point came from my background in observability and in terms of why software systems are failing.
[SPEAKER_01]: we're applying that for basically business systems.
[SPEAKER_01]: But the simple way to again describe this is that we help companies understand what change in their business, especially with the KPIs, why change and what to do about it.
[SPEAKER_01]: Our customers are usually in businesses where revenue is very transactional, which is why we pick retail travel, payments, marketplaces, things like that.
[SPEAKER_01]: They have a lot of data that are drowning in dashboards.
[SPEAKER_01]: They have warehouses, they have BI tools, analysts, etc.
[SPEAKER_01]: but what they're not really able to solve for the pain that we're solving is what happens when something moves?
[SPEAKER_01]: Let's just say conversion is dropping or authorization rate is changing for a payments company.
[SPEAKER_01]: Our supplier is underperforming.
[SPEAKER_01]: If the inventory looks fine, but customers can't buy the things they want.
[SPEAKER_01]: Everyone sees that the numbers changed of all of these examples are gave you, but then the real work starts.
[SPEAKER_01]: And then the most important
[SPEAKER_01]: part of the decision making.
[SPEAKER_01]: Is it real?
[SPEAKER_01]: Is it nice?
[SPEAKER_01]: It's first of all.
[SPEAKER_01]: Like which segment caused it?
[SPEAKER_01]: Was it in in geography?
[SPEAKER_01]: Was it in a skew?
[SPEAKER_01]: Was it in a campaign?
[SPEAKER_01]: Was it in a gateway?
[SPEAKER_01]: Was it an apartment?
[SPEAKER_01]: etc.
[SPEAKER_01]: And then you actually start figuring out like why is it like really happening doing the analysis?
[SPEAKER_01]: And that can take hours or days and by the team has the answer to the business may already help lost money.
[SPEAKER_01]: And that's really what bicycle automates that instead of asking, why is this so slow?
[SPEAKER_01]: We're asking, why did checkout and was dropped or why did bookings fall?
[SPEAKER_01]: And that's basically really the problem called we're solving.
[SPEAKER_03]: Let's move into what you would consider the MVP for bicycle AI.
[SPEAKER_03]: So that first version that you created, how long it takes to build and what sort of tools are you using to bring it to life?
[SPEAKER_01]: So the first version took about like a year plus and then I think the other thing which we can talk about a little bit later the show is that how things have been changing so much over the last sort of 12 to 18 months or so, right?
[SPEAKER_01]: The first the whole LLAM stuff comes up and the sort of like ingenting stuff comes up and so we've been really keeping up with it because it's a very exciting time to build and if you're really harness all that technology and
[SPEAKER_01]: build something meaningful and solve a real problem, I think it's a very exciting result for technologists like myself.
[SPEAKER_01]: But let's start with the first version.
[SPEAKER_01]: It was very focused.
[SPEAKER_01]: We didn't try to build like a giant horizontal analytics platform on day one.
[SPEAKER_01]: That would have been pretty hard and that would have been a mistake.
[SPEAKER_01]: We started with a much narrower problem.
[SPEAKER_01]: Can we detect important KPI movements and help explain them faster than are team doing it manually?
[SPEAKER_01]: right.
[SPEAKER_01]: So the early MVP was basically the three things that we focused on.
[SPEAKER_01]: It's a number one, connect to customer data.
[SPEAKER_01]: So that could be living in warehouses, that could be living in CSVs, it could be operational data, it could be in a stream like Kafka etc.
[SPEAKER_01]: So that's number one.
[SPEAKER_01]: Second, Define the KBI property.
[SPEAKER_01]: So again, Sans boring, but actually if you think about it, it's one of the hardest parts.
[SPEAKER_01]: Multiple teams use multiple words, multiple teams to use different KBI definitions and beat very different things.
[SPEAKER_01]: So we're like, okay, let's just define it properly, let's drown on the definition.
[SPEAKER_01]: And number three, once the KPI moves automatically search across the dimensions that could be causing it.
[SPEAKER_01]: So that could be device, region, suppliers, customer segments, campaigns, gateways, and then because of that, you're actually looking at different tooling.
[SPEAKER_01]: But look at whatever matters for the business and trying to figure out why this is happening.
[SPEAKER_01]: what we learned in that process was the model is not the whole product right like a lot of the product is basically context.
[SPEAKER_01]: So this was like v1 because the system just has to know what the method means, it has to know what normal looks like, it has to know which dimensions matter, has to know which causes a plausible etc etc.
[SPEAKER_03]: I want to stay on that MVP for now.
[SPEAKER_03]: I'm curious about, and I could probably cherry-picker or extract from what you said, but maybe give me a core decision that you had to make in that early MVP and how you built it and how you approach the problem and then how you cooked with that decision.
[SPEAKER_01]: So I think the core thing and this was like the first sentence when I was describing it when it's okay, we're not building like a giant horizontal platform and the decision we have to make is that okay, let's focus on a particular vertical because eventually or a set of verticals because eventually we want the solution to look very vertical right.
[SPEAKER_01]: The language you speak is very difficult, right?
[SPEAKER_01]: Pre-tale is different from travel and travels very different from health care, health care is very different from some other industry.
[SPEAKER_01]: So we want to have the whole sort of model grounded in a particular type of business and we chose transactional businesses where there is some form of looking at something, adding it to cart, checking it out, and like this fulfillment or delivery.
[SPEAKER_01]: And that's why we picked retail and travel and payments because it just sounded like that one ecosystem.
[SPEAKER_01]: So that was the big decision, worse they're saying, hey, we're just going to treat it as like a data analysis problem and create like some visualizations etc because eventually what we wanted to do was to create modules that are actually solving real problems like conversion is dropping or approval rate monitoring is dropping and how do you handle that?
[SPEAKER_01]: And as it stands today,
[SPEAKER_01]: Those modules are basically analytics agents that are just AI agents that are performing that job and that's kind of how it worked out over time, but that was a big decision and that we ought to make.
[SPEAKER_01]: And I think you also asked me by the systems we used and we basically used a mix of traditional data engineering because data engineering, statistical methods machine learning.
[SPEAKER_01]: That is what really helps us understand.
[SPEAKER_01]: Why I keep when I keep I moves because that's a data science problem.
[SPEAKER_01]: It's not like you could throw like an LLM on top of a very house and say oh fine sort of movement in it You have to be grounded in statistical methods and so we use a lot of that and now we obviously use LLMs for orchestration all of that type of stuff
[SPEAKER_03]: Curious then, how you progress and mature the prognist, you know, this goes back to the two iterations you mentioned.
[SPEAKER_03]: I'm curious about how you went about that and to wrap that kind of box.
[SPEAKER_03]: A little bit, I'm looking for how you build your roadbath.
[SPEAKER_03]: How do you go about deciding that?
[SPEAKER_03]: Okay, this is the next most important thing to build or to address.
[SPEAKER_01]: In short, I would say that the product has really matured from detect and explain a KPM movement, which is what we started our path, to a broader decision system, right?
[SPEAKER_01]: In the early days, we're like, let's prove that we could spot changes and explain them.
[SPEAKER_01]: Now the product is more of a full new.
[SPEAKER_01]: We think about it as detect, explain
[SPEAKER_01]: act and learn.
[SPEAKER_01]: So we call it deal, right?
[SPEAKER_01]: So detect, explain, act and learn.
[SPEAKER_01]: So detect basically means the system finds something that matters, right?
[SPEAKER_01]: Explain basically means bicycle and mess against the likely cause, but a subsection of explain is actually focused, like focus means it figures out where to look.
[SPEAKER_01]: Not every movement deserves the same attention and KBI can move because of a tiny segment, like a particular city, a particular iOS version, or because of all business issues.
[SPEAKER_01]: Product has to separate the nice from signals, so can you find the segment?
[SPEAKER_01]: So that's the focus part of the explanation.
[SPEAKER_01]: But the explanation itself then looks across business data, operational data, sometimes technical signals, and then shows the evidence.
[SPEAKER_01]: and then act basically means the system helps the team take the next step that could be starting with the recommendation but then progressing from there to like actually creating a task and you adjust a campaign, can you notify a partner, can you change a routing rule in payments are preparing a decision for approval.
[SPEAKER_01]: So that's like the core system.
[SPEAKER_01]: So in terms of progress, there are two big things I would say as part of the iteration.
[SPEAKER_01]: Once we created the core system, when we looked at the power of LLMs, we understood that if what we created was the automated data analyst, the LLM can actually function as an automated business analyst.
[SPEAKER_01]: Where it's bringing in the strategy and it's orchestrating and it's actually suggesting
[SPEAKER_01]: all the core exploration steps, all the core actions that can be recommended.
[SPEAKER_01]: It actually comes up with that list, so that was kind of one big iteration.
[SPEAKER_01]: And the next iteration was when things went agente, we actually then started building, how do you go from raw data where the agent actually picks up all the onboarding, all the mapping, etc., etc., all the heavy lift that the customer has to do to map data into our system, and the agent now actually just sits on top snowflakes,
[SPEAKER_01]: and then maps it basically automatically.
[SPEAKER_01]: So that's the progression part.
[SPEAKER_01]: Really quick on the roadmap, it just comes from repeated customer patterns, right?
[SPEAKER_01]: So when we talk to three, two or three retail customers who have the same type of checkout problem that becomes a template.
[SPEAKER_01]: For example, they bring up promotions then we're like, okay, that's what it is.
[SPEAKER_01]: When multiple travel companies need to understand supplier performance that becomes a reusable agent, right?
[SPEAKER_01]: So everything becomes reusable agent, brand payment, steaks, keep asking about the authorization rate,
[SPEAKER_01]: by geography, by bay and etc.
[SPEAKER_01]: Again, that pattern needs to be stronger.
[SPEAKER_01]: So it's not just a feature list, but whatever is recurring in terms of the conversations we have, what decisions or teams making again and again and wherever data is available to the cost of delay is high and we can compress the time from the question to answer that's really what we index on and that's kind of really how the product is grown.
[SPEAKER_03]: Okay, so I hear you saying we come about how you built that team and what do you look for in those people to indicate that they are the winning horses to join you?
[SPEAKER_01]: That is the most important thing.
[SPEAKER_01]: You can have the best idea.
[SPEAKER_01]: You can have whatever in terms of the end idea, etc.
[SPEAKER_01]: But without the team, you can't really do that.
[SPEAKER_01]: We look for people who are comfortable with where when things are messy.
[SPEAKER_01]: And sounds very simple, but I think it's really important in how you really look at that.
[SPEAKER_01]: Look, those people, right?
[SPEAKER_01]: Because not everybody is able to handle ambing you.
[SPEAKER_01]: In this kind of product, you need people who can handle ambing, but you're not going after an established category where you're like, yeah, we're just building another Sierra.
[SPEAKER_01]: So let's do these four bells and whistles and put a eye on top of it and then let's sort of build that.
[SPEAKER_01]: So you need someone can handle ambiguity, customer data is messy, working with customer data is always hard, business definitions are all over the place, they are messy, real organizations when they're working with an
[SPEAKER_01]: is an area of very high attention.
[SPEAKER_01]: So you can't build this from like a clean demo environment.
[SPEAKER_01]: So we look for people who have strong technical depth, but also patients with the last mile on what we're doing, a great sort of engineer and bicycle I would say can can build a system where we'll also ask when the customer trust is answered because again, it can just be a number right with the customer really trusted.
[SPEAKER_01]: A great product person can think of the eye.
[SPEAKER_01]: But also I understand why a revenue leader doesn't want five explanations.
[SPEAKER_01]: They're one the right one with the evidence, otherwise there's no point in using the product.
[SPEAKER_01]: And then there's some engineers who love complexity and who just focus only on complexity, but it's not just about being in love with complexity and working on complex and hard problems because the user experience has to be simple.
[SPEAKER_01]: And that is the anti-poor of complexity, right?
[SPEAKER_01]: If a customer sees a revenue drop,
[SPEAKER_01]: they're not necessarily looking for like super-dance material and models or something like they want to know is this real is as nice and if it's real what caused it so the team we have is a mix of like infrastructure data yeah I product and enterprise experience and then we look for people who are direct below ego comfortable even if their opinions are strong they hold them lose the as they say
[SPEAKER_01]: because early stages you're wrong a lot right like you want to learn fast, fix it and keep going and then the last point I'd probably say is that curiosity that is the foundation of anything of everything and definitely want people for more curious and want to begin.
[SPEAKER_03]: I'm curious about scale.
[SPEAKER_03]: Like where scale has been factored into your decisions and that could be technology or business and I'm curious about how you're approached it, but also it had to have been interesting areas we've had to fight scale as you've grown.
[SPEAKER_01]: it's a moving target right like keeps changing.
[SPEAKER_01]: We did build some of it scale efficiently but we also fought as we grew so like a little bit of both right architecturally we knew from day one that this had to scale scale a lot.
[SPEAKER_01]: Our customers are very high-transact volumes.
[SPEAKER_01]: We're not dealing with a small dashboard.
[SPEAKER_01]: In fact we have customers who sell centers about half a billion to a billion events a day and I've talked about like so it is bookings, statements etc and so
[SPEAKER_01]: We have almost a billion of those events coming in of customers every day.
[SPEAKER_01]: And these events are constantly flowing, pricing changes, supplier changes, inventory updates, payments, etc.
[SPEAKER_01]: So what we designed bicycle to work with is designed it to work with existing data infrastructure.
[SPEAKER_01]: We don't want customers to move everything into some new system just to get value.
[SPEAKER_01]: We connect to the data they already have.
[SPEAKER_01]: and push computation where it makes sense, right?
[SPEAKER_01]: But we also have to fight scale in a different way, which is product scale.
[SPEAKER_01]: The harder scaling problem is not data volume, it's context volume.
[SPEAKER_01]: How do you narrow it down?
[SPEAKER_01]: How do you condense it?
[SPEAKER_01]: How do you get to like the right hypothesis?
[SPEAKER_01]: the right sort of reason why something's happened and this is where we have to go into every company having multiple definitions, every vertical high, having its own logic and which is why we narrow it out onto verticals.
[SPEAKER_01]: A check out problem in retail is not the same as a book proper travel, it has some parallels, it's not the same as an authorization problem in payment.
[SPEAKER_01]: So, how do we build a system that has reusable intelligence and has underlying patterns, right?
[SPEAKER_01]: And that's basically where the agent model really came in.
[SPEAKER_01]: Think of, we don't think of PiceColor's generic assistant.
[SPEAKER_01]: We think of, it is an agent that is got a very specific job and check out versus booking versus authorization are different jobs, but it needs to know how to think about that particular top use case, like whether it's search.
[SPEAKER_01]: payment authorization, and then in need to understand domain.
[SPEAKER_01]: If you're a payment authorization agent, you have to understand issuers, gateways, bin, geography, retry logic, etc., a supplier performance agent needs to understand availability, pricing, latency, etc., so that gives us a better path to scale and that's why we're focused on smaller set of verticals, more like a set of focused analysts that understands specific business decisions.
[SPEAKER_03]: So as you step out on the balcony and you look across all that you've built with Bicycle AI, what do you most proud of?
[SPEAKER_01]: I was proud of the fact that we're solving a very real problem that's unsolved and that people feel every week.
[SPEAKER_01]: With all this attention on data, with all the focus on data, like people are drowning in data and dashboards, but this is like an unsolved problem.
[SPEAKER_01]: And then also like how we solve this with AI, right?
[SPEAKER_01]: There's a version of AI right now.
[SPEAKER_01]: It's very demo driven, right?
[SPEAKER_01]: Like, it looks great for five minutes, but when you put it inside a real business with real data, real permissions, real definitions, real money on the line, it's a much harder problem.
[SPEAKER_01]: Some probably chose the hard avoidant.
[SPEAKER_01]: We're not saying ask any question and trust what I'm gonna come back.
[SPEAKER_01]: We're saying, let's build a system that understands the business and it's grounded in your business sort of knowledge.
[SPEAKER_01]: and starting with the vertical foundation that we had, validates the metric, investigates the cause, and gives you our balance.
[SPEAKER_01]: That matters because analytics is sure.
[SPEAKER_01]: It is about answers, but it's also about trust.
[SPEAKER_01]: If it revenue leader doesn't trust the answer, they won't act if it did, it didn't trust the system.
[SPEAKER_01]: They're not going to support it, right?
[SPEAKER_01]: So, I'm proud that you've stayed grounded in that.
[SPEAKER_01]: That's like the real grant work.
[SPEAKER_01]: Definitely proud of the team is not an easy product build.
[SPEAKER_01]: It's looking at multiple different sort of areas and especially the explanation part, having to go through one, but you could go through an observability tool or a second session recording tool or a pricing engine all over the place, right?
[SPEAKER_01]: But to combine data, product design and price workflows and domain context and come up with that, you can either make it too complex or sometimes you can make it to shallow.
[SPEAKER_01]: And the fact that the team keeps pushing towards something simple, useful, meaningful.
[SPEAKER_03]: Okay, let's flip the script a little bit.
[SPEAKER_03]: Tell me about a mistake you made and how you and your team responded to it.
[SPEAKER_01]: One of them was underestimating how much context the system needs before the AI feels useful, honestly.
[SPEAKER_01]: Obviously, we are giving it the base context of, here's the retail system.
[SPEAKER_01]: Here is basically more context about the subvertical off retail.
[SPEAKER_01]: So, is it quick-comers?
[SPEAKER_01]: Is it a fashion retailer?
[SPEAKER_01]: Is it a large market-based server?
[SPEAKER_01]: So, we've seen in all of that, right?
[SPEAKER_01]: And early on, we were very excited by the idea that AI could make analytics for conversational, user-grasked questions, system grants, and then that's useful, but it's hard enough, right?
[SPEAKER_01]: So, the mistake was, it kicked out.
[SPEAKER_01]: the interface is the product, because the hard part in analytics isn't typing a question.
[SPEAKER_01]: The hard part is knowing what the question means, whether the metric is to find correct me, which data source is a trusted one, but what are the dimensions that matter?
[SPEAKER_01]: So we had a lot of moments where the product could just go in and getting the data behind it is great when you see it for the first time, right?
[SPEAKER_01]: And the product could technically answer
[SPEAKER_01]: when the answer didn't have the tap right and the team responded well because we didn't defend the original idea too much we're like okay how do we do better and so that pushed us towards better stronger onboarding while editing KPIs reusing decision templates so that again that's rooted in the context that a company gives us
[SPEAKER_01]: better cause analysis based off of that and then it also changed how we talk about the product because it's obviously not a child experience right this entire analyst that has to be counted in the business and it basically gives you answers before you to ask for them.
[SPEAKER_01]: That's the progression and I think those are really good correction but we started with getting so excited with oh we can just talk to the data and get answers from it.
[SPEAKER_03]: Okay, best scar, let's move forward then.
[SPEAKER_03]: What does the future look like for bicycle AI?
[SPEAKER_03]: There's a lot going on in the industry, you're solving a big problem.
[SPEAKER_03]: What does the future look like for the product, for the team, and where everything's going?
[SPEAKER_01]: I think of Bicycle as a cursor for the analysts, like a cursor or a plot court for the analysts.
[SPEAKER_01]: Just because cursor or a plot court came in, developers didn't stop writing court, right?
[SPEAKER_01]: Like, they were still writing court, but it was basically like force multiplier for them.
[SPEAKER_01]: So similarly,
[SPEAKER_01]: Like, we want to give analysts an unfair advantage by force multiplying what they do.
[SPEAKER_01]: What is the core problem we're solving?
[SPEAKER_01]: Like, the best analyst today spent too much time on interpretative investigation.
[SPEAKER_01]: Something moved.
[SPEAKER_01]: What is the segment check device, check geo, check campaign, check skew, check release, check multiple things and build the same explanation again, right?
[SPEAKER_01]: It's very similar to building a system when you code it is interpretative.
[SPEAKER_01]: That work is important, but a lot of it can be assisted.
[SPEAKER_01]: So, but the strategy is still coming from them, right?
[SPEAKER_01]: So, I think the future is that the bicycle becomes the always on analytical layer for these themes.
[SPEAKER_01]: And again, it doesn't necessarily always have to be like, and somebody who's job title is analysts, but you can actually start creating citizen analysts as well.
[SPEAKER_01]: But the bicycle always on our regular layer knows the KDIs, knows the business context, knows what change, knows the likely causes, knows what actions that are allowed, right?
[SPEAKER_01]: So we just focus on that path, go from signal to action, and it learns from how the team responds.
[SPEAKER_01]: If we made a decision or if we recommended an action or if we automated something,
[SPEAKER_01]: did we do the right thing?
[SPEAKER_01]: And so can we learn from that?
[SPEAKER_01]: And what that means to the product is that means going deeper into retail power payments, more agents for more specific decisions that are workflows by the governance.
[SPEAKER_01]: And what it means for us internally as a team is just staying focused right because this is so much noise in AI right now.
[SPEAKER_01]: And sometimes it can become chasing a new model or interface, but our job is to help customers make better revenue decisions
[SPEAKER_03]: Excellent.
[SPEAKER_03]: Let's wish to you.
[SPEAKER_03]: Who influences the way that you work?
[SPEAKER_03]: Name a person or many persons or something.
[SPEAKER_03]: You look up to him.
[SPEAKER_03]: Why?
[SPEAKER_01]: There's the usual folks like Steve Jobs, folks like Elon who obviously are just in a different status fear and who inspire you.
[SPEAKER_01]: But I think having been in the valley for more than a couple of decades and work with a lot of brilliant people, I think a lot of my influence comes from bernas who are combining technical depth with practical customer apathy, right?
[SPEAKER_01]: Because again, technical theft can lead you towards like super complex, super hard problems, but that doesn't mean air you have practically a customer out with the NP, you're building a great product.
[SPEAKER_01]: So, I'll always admire people who can go very deep technically, but still explain the problem in play language, right?
[SPEAKER_01]: Can break it down, can have that kind of big picture.
[SPEAKER_01]: It was a big part of the dynamic experience because observability is a very complex technical category.
[SPEAKER_01]: But the reason we were successful is we mapped it to a very human pain.
[SPEAKER_01]: We mapped it to operators who weren't coding.
[SPEAKER_01]: And so we made them understand how to operate the application without understanding the code layer and everything else.
[SPEAKER_01]: And that's what I'm influenced by.
[SPEAKER_01]: I also pay attention to operators and people running
[SPEAKER_01]: their problems in fancy terms like they just say every Monday, we spent three hours figuring out why it's never changed.
[SPEAKER_01]: So that kind of sentence is important, right?
[SPEAKER_01]: Because it tells you about the pain and how do you then map it to what you're doing?
[SPEAKER_01]: So my work style I would say is...
[SPEAKER_01]: influenced by technical vendors, but also by operators who have to live in the product every day.
[SPEAKER_01]: That's where you learn a lot of it from, and that's who you release to simplify it, because the best products respect both sides, whether it's the vendors and the operators, because under the word, you have to build something that's like pretty strong.
[SPEAKER_01]: But then, if you make the user actually feel the complexity, then you really fail in the product.
[SPEAKER_01]: So how do you combine both those layers?
[SPEAKER_01]: So you're just like the builders, you got to respect the operators and have the relevance.
[SPEAKER_03]: Last question.
[SPEAKER_03]: So you're getting on a plane.
[SPEAKER_03]: You're sitting next to a young entrepreneur who's built the next big thing.
[SPEAKER_03]: They're jazzed about it.
[SPEAKER_03]: They can't reach showed off to the world and can we shut off to you right there on the plane?
[SPEAKER_03]: What advice do you give that person having gone down this road a bit?
[SPEAKER_01]: I would say stay very close to the painful versions of the problem, right?
[SPEAKER_01]: Because a long-famous father starts with the exciting version.
[SPEAKER_01]: What is the category?
[SPEAKER_01]: How do you map the market like my pitch is really big?
[SPEAKER_01]: Like this the AI story and the product question and all that stuff, right?
[SPEAKER_01]: But it can pull you away from the thing that really matters.
[SPEAKER_01]: You have to find the people who have the problem every week, you have to sit with them.
[SPEAKER_01]: watch other word, ask what happens when the problem isn't solved, who gets the blame, how much time the lose, how much money the lose, ask what they've already tried before, ask what they don't trust, and a lot of these answers are actually really solid because that's what shapes the product.
[SPEAKER_01]: That's one.
[SPEAKER_01]: And then second, which is very relevant right now,
[SPEAKER_01]: do not confuse speed with progress, right?
[SPEAKER_01]: Because you can build something so quick, like I could just run something in a few minutes, secret results, do something over a weekend, come up with something amazing, with AI tools, cloud, etc.
[SPEAKER_01]: create something that looks really real and even created very quickly.
[SPEAKER_01]: But a company is not just built by shipping code.
[SPEAKER_01]: It's built by earning trust.
[SPEAKER_01]: The customer has to trust the answer.
[SPEAKER_01]: The buyer has to trust the value.
[SPEAKER_01]: The team has to trust each other.
[SPEAKER_01]: The market has to trust that you'll be around.
[SPEAKER_01]: Right.
[SPEAKER_01]: So yeah, definitely by all means will fast, but definitely be precise.
[SPEAKER_01]: And then it's in the last thing is maybe build something specific enough.
[SPEAKER_01]: AI for analytics is too broad, right?
[SPEAKER_01]: I can tell you why Chuck Hartman wasn't dropped before your Monday meeting is easier to understand which is why we're focusing more on those verticals, specific problems, create specific products and specific products basically create trust.
[SPEAKER_01]: So that's probably the three-part advice that I was thinking.
[SPEAKER_03]: That's all fantastic advice.
[SPEAKER_03]: Well, Baskar, thank you for being on the show today, and thank you for telling the creation story of Bicycle AI.
[SPEAKER_01]: Oh, I enjoy it.
[SPEAKER_01]: Thank you, thank you so much.
[SPEAKER_03]: and this concludes another chapter of Coat Story.
[SPEAKER_03]: Coat Story is hosted and produced by Noil Apphart.
[SPEAKER_03]: Be sure to subscribe on Apple Podcast, Spotify or the podcasting app at your choice.
[SPEAKER_03]: And when you get a chance, leave us a review, both things help us out tremendously.
[SPEAKER_03]: And thanks again for listening.
Podbean