Brian Bell · Aug 17, 2026 · 12 min read

Ignite Startups: Bhaskar Sunkara on Reinventing Business Analytics with AI | Ep289

Bhaskar Sunkara explains why dashboard-driven operations are failing and how AI analytics agents can detect revenue-critical problems, identify their causes, and turn business data into action.

Ignite Startups: Bhaskar Sunkara on Reinventing Business Analytics with AI | Ep289

Bhaskar Sunkara helped build AppDynamics from a laptop on a couch into a category-defining enterprise software company acquired by Cisco for $3.7 billion. Now, as CEO of Bicycle, he is applying a similar operating philosophy to a different problem: helping companies move from business data to revenue-critical action.

His central argument is blunt. Dashboards are still useful for communicating the state of a business, but dashboard-driven operations are breaking down. Companies now track too many products, markets, suppliers, customer segments, devices, conversion paths, and technical dependencies for humans to monitor effectively.

The next generation of analytics will not simply show people what happened. It will detect meaningful changes, explain their likely causes, recommend a response, and eventually take action.

The AppDynamics Lesson: Solve the Immediate Pain

Technical founders often begin with broad visions. They want to build complete platforms, elegant architectures, and systems that can eventually solve many different problems.

AppDynamics initially followed that pattern. The team considered building capacity-management software for elastic cloud computing, but the market was still early. Many companies were experimenting with the cloud without yet running their most important production workloads there.

The team narrowed its focus to a more urgent problem: when a production application breaks, the business loses money.

That decision led to several more constraints.

AppDynamics focused initially on Java because it was the predominant language in the target market. It sold to operations teams rather than developers because operations teams were accountable for keeping production systems running. It also built specifically for production instead of trying to support development, testing, staging, and production environments equally.

These choices looked restrictive. In practice, they created clarity.

The company was not selling a general-purpose technical platform. It was solving a specific and expensive operational problem for a clearly defined buyer.

Bhaskar now sees the same lesson applying to AI startups. Founders should resist building a large horizontal platform before proving that customers urgently need a narrow use case.

Why AppDynamics Put Its Product in Production

Application monitoring software presented an unusual sales challenge. Customers feared that installing a monitoring agent could slow down or even break the application it was supposed to protect.

AppDynamics responded by asking prospects to run proofs of concept directly in production.

That was a risky position, but it forced the company to build reliable infrastructure and gave customers a realistic demonstration. Monitoring software is difficult to evaluate in a sandbox. A test environment does not reproduce real traffic, production databases, external dependencies, or the full architecture of a live application.

Production proofs of concept became a source of credibility.

The company later launched AppDynamics Lite as a self-service product. Customers could download it, install it, and experience the product before entering a traditional enterprise sales cycle. Bhaskar recalls calling users to explain that the agent was safe to run in production, only to hear that some had already deployed it there without assistance.

That validation helped AppDynamics double down on self-service distribution, which eventually generated a significant share of the leads that became large enterprise contracts.

The broader lesson is not merely that free trials work. The product itself must allow a customer to reach meaningful value without requiring a sales team to manufacture the experience.

The $3.7 Billion Decision

In January 2017, the AppDynamics team was in New York preparing to ring the Nasdaq opening bell. The company was on the verge of an initial public offering when Cisco acquired it for $3.7 billion.

Bhaskar says the expected public valuation was likely above $2 billion, making Cisco’s offer an unusually large premium. The abrupt change created an emotional shock for employees who had prepared for the IPO milestone.

The team eventually rang the Nasdaq bell with Cisco, but the company’s path had changed overnight.

Bhaskar stayed at Cisco for roughly two years. The experience gave him a deeper understanding of how the largest enterprises buy technology. AppDynamics had already begun closing major contracts, but Cisco operated at a different scale, with larger transactions, longer buying processes, and elaborate executive briefing centers.

That exposure now shapes how Bicycle approaches enterprise customers and complex business environments.

Bicycle’s Core Idea: Business Signal to Action

Bhaskar describes AppDynamics as a system that moved from technical signals to action. If checkout response times deteriorated, the software helped teams identify the technical cause and fix it.

Bicycle applies the same model to business signals.

A travel company may see bookings decline. A card company may see payment approval rates fall. A retailer may notice checkout conversion dropping in San Francisco.

The metric reveals that something is wrong, but it does not explain why.

Possible causes could include:

  • A supplier experiencing higher-than-normal errors
  • A pricing change by a competitor
  • A shortage of inventory
  • A poorly configured marketing campaign
  • A software release that broke checkout on a specific iOS version
  • An external event that changed customer demand

This creates a large decision tree combining technical, commercial, operational, and external factors.

Traditional analytics systems may alert a team that a KPI moved. Analysts must then investigate multiple systems, test possible explanations, identify the responsible segment, and decide what to do.

Bicycle is attempting to automate more of that process.

The company describes its framework as DEAL:

  • Detect the change in a critical KPI
  • Explain the likely cause
  • Act on the finding
  • Learn from the result

The intended outcome is not simply faster analysis. It is a closed feedback loop in which the system becomes more useful as it accumulates company context and learns which recommendations people accept.

Why Transactional Businesses Come First

Bicycle focuses on travel, retail, and payments because these businesses operate under immediate financial pressure.

When a transactional company experiences a failure, revenue disappears in real time. If payment approvals fall, bookings fail, or restaurant orders stop flowing, the company cannot wait several weeks for an analyst to complete an investigation.

This urgency makes transactional businesses a strong initial market for AI-driven analytics.

Bhaskar uses UrbanPiper as an example. UrbanPiper connects food-ordering platforms with restaurant systems across tens of thousands of locations. When orders decline, the cause might be related to a store, menu, inventory source, or technical failure.

Bicycle’s system is designed to identify the affected segment, isolate the likely cause, and reduce the time required to respond from days to hours.

A similar model can apply to an online travel company. If one supplier produces abnormal booking errors in a particular region, an agent could detect the issue and use a webhook to remove that supplier. Once the metrics return to normal, the system could restore it.

The action is narrow, automated, and tied to a specific business signal.

Dashboard-Driven Operations Are Dying

Bhaskar does not argue that dashboards will disappear entirely.

Executives and teams will still use them to review revenue, customer health, and operating performance. Dashboards are useful communication tools because they provide a shared view of the business.

The problem is using them as the primary mechanism for live operations.

A company may sell dozens of products across dozens of regions. Each product-region combination may have different customer behavior, suppliers, pricing, conversion rates, technical dependencies, and failure modes.

No human can continuously monitor every relevant dimension on a dashboard.

Alerting does not fully solve the problem. Excessive alerts create fatigue, and teams eventually ignore them. A useful system must distinguish meaningful signals from normal variation and begin the investigation before presenting the issue to a person.

The future, in Bhaskar’s view, is not dashboard-free. It is a shift from dashboards as operating systems to dashboards as communication surfaces.

Why Chat Is Not the Final Interface for Analytics

The rise of large language models has made it possible for users to ask questions about business data in plain English instead of writing SQL.

Bhaskar believes this is useful but insufficient.

Chat-based analytics still requires a person to ask the correct question, at the correct time, with the correct suspicion. If the user overlooks a supplier, region, device type, or technical release, the system may never surface the real problem.

As Bhaskar puts it, the end state cannot depend on people deciding when to talk to their data.

An AI system should continuously examine important metrics and dimensions, identify unusual behavior, and surface the signals that require attention. Chat can remain available for exploration, but it should not carry the full burden of business operations.

“Chat driven operations aren’t gonna work also because if you’re relying on you asking the right question, maybe you forgot a particular factor.”

That is one of the episode’s most consequential claims. Making data easier to query is not the same as making a business easier to operate.

Becoming CEO After a Career as CTO

Bhaskar spent years focused on technical correctness, scalability, and architecture. Becoming CEO required a different discipline.

A technical leader can explore multiple ideas simultaneously. A CEO’s behavior sends an emotional and strategic signal to the entire company.

If the CEO appears to chase several directions, employees may interpret each experiment as a new priority. The result is confusion.

Bhaskar says the CEO must create clarity, even while personally managing uncertainty. That means separating private exploration from the signals the organization receives.

This is especially important in a market moving as quickly as AI. Bicycle has rebuilt parts of its product as large language models and agentic systems have improved. The company initially created an automated data analyst, then added an automated business analyst that could understand important KPIs, business dimensions, likely causes, and potential actions.

The challenge was not merely adopting new technology. It was deciding which changes represented the company’s strategy and which were temporary experiments.

AI Is Also Changing How Software Gets Built

Bhaskar sees AI affecting both Bicycle’s product and its internal development process.

Detailed natural-language specifications can now serve as strong inputs for coding agents. A product leader can describe how a service should behave, and the agent can use that context to produce an initial implementation or help diagnose a bug.

The company also uses AI tools to turn long specifications into more digestible formats, including presentations and audio-style summaries.

Product development is becoming more fluid. Teams can begin with clickable AI-generated prototypes, move into design tools when more collaboration is needed, and hand increasingly complete context to developers.

The process changes rapidly, sometimes month by month.

The implication is not that product managers, designers, or engineers disappear. Their value moves toward judgment, prioritization, taste, system design, and the ability to provide high-quality context.

The Metrics Founders Should Question

Bhaskar considers customer or logo count one of the most overrated startup metrics, especially in AI.

A company can accumulate logos through free trials, demonstrations, and experimental deployments without creating durable value. A recognizable customer name reveals little about how deeply the product is used or whether it has reached production.

The more meaningful question is whether the customer has adopted the product for an important use case.

He sees time to value as one of the most underrated metrics. Companies should understand how quickly users experience a meaningful result and how much work is required to reach it.

This is difficult to measure, particularly in enterprise software, where renewals can be influenced by relationships and procurement dynamics. But it gets closer to the truth than a raw customer count.

Hiring Executives Who Can Still Do the Work

Bhaskar is skeptical of senior executives who present themselves primarily as hiring machines.

A head of sales should still be able to deliver a strong pitch. An engineering executive should still be capable of engaging with hard technical and business problems. Seniority should not create distance from the actual work.

This is one reason founders should be cautious when investors recommend executives from their personal networks. Pattern matching can be useful, but the executive must fit the company’s current stage and specific operating needs.

A leader who succeeded inside a mature organization may not be willing or able to operate inside an early-stage company where roles remain fluid and resources are limited.

The strongest executives can think strategically while still getting their hands dirty.

The Long-Term Vision

Bicycle’s ambition is to become more than a conversational interface layered over a data warehouse.

The company wants to build a system that understands how a business operates and compounds that understanding over time.

On day one, an agent may know which KPIs are commonly important for a travel, retail, or payments company. By day one hundred, it should understand which movements matter in that specific organization, which explanations have proven reliable, which recommendations users accepted, and which actions produced results.

That accumulated context creates the difference between a generic AI demonstration and an operational system.

The deeper shift is from software that reports what happened to software that participates in decision-making.

Dashboards organized the information age. AI agents may organize the action that follows.

Chapters:

  • 00:01Introducing Bhaskar Sunkara
  • 00:24From India to Silicon Valley
  • 03:59Lessons from Building AppDynamics
  • 07:10Why DevOps Remains a Fuzzy Concept
  • 08:52Selling to Operations Instead of Developers
  • 10:20Running Proofs of Concept in Production
  • 12:21Launching AppDynamics Lite as a Self-Service Product
  • 14:23Cisco’s $3.7 Billion AppDynamics Acquisition
  • 16:34Learning Enterprise Scale Inside Cisco
  • 18:05The Origin of Bicycle
  • 19:42Turning Business Signals Into Action
  • 21:47From Business IQ to Proactive Analytics
  • 23:43Moving from CTO to CEO
  • 25:08Bicycle’s Product Evolution
  • 28:38Choosing Travel, Retail, and Payments
  • 31:21Reducing Resolution Times Across 45,000 Locations
  • 34:49Why Dashboard-Driven Operations Are Dying
  • 37:01Why Companies Are Over-Indexing on Chat
  • 40:03Selling Analytics to Business and Data Teams
  • 42:00Building the Cursor for Analytics Teams
  • 43:36How AI Is Changing Product Development
  • 46:23Prototyping Products With Claude
  • 47:27Bicycle’s Long-Term Vision
  • 50:01Rapid-Fire Founder Lessons
  • 53:23The Most Overrated Startup Metric

https://tr.ee/S2ayrbx_fL

https://linktr.ee/theignitepodcast

Learn more about Bicycle AI: https://bicycle.ai/

Follow Bhaskar Sunkara on LinkedIn: https://www.linkedin.com/in/bhaskarsunkara/

Subscribe on Spotify:

https://open.spotify.com/show/6Ga6v0YUsHotLhjap67uu5

Subscribe on Apple Podcasts:

https://podcasts.apple.com/us/podcast/ignite-conversations-on-startups-venture-capital-tech/id1709248824

Listen to this episode

0:00 / 0:00
Open the full episode page
Read the full transcript

Brian Bell (00:01.652) Hey everyone, welcome back to the Ignite Podcast. Today we are delighted to have Bas Pascara Sankara on the program. He was employee number one, number one at App Dynamics. As founding CTO, he helped build the company from a single laptop on a couch in San Francisco into a category-defining application performance monitoring platform. Thanks for coming on.

Bhaskar Sunkara (00:22.594) Yeah, thanks Brian. Thanks for having me. Appreciate it.

Brian Bell (00:24.724) Well, I'd love to get your origin story. What's your what's your background?

Bhaskar Sunkara (00:28.514) Yeah, so you know, my background. I actually grew up in India and then moved to moved to the US because I always wanted to be in the valley, you know, building products. But but I think if you if I if I look at the pattern, I've always been a builder, started programming, you know, fairly early, right? and understanding sort of like how to build systems, how to build something and iterate on it. And then just getting closer to a solution that I kind of really, really, really kind of wanted. And that was kind of the starting point. But when I started my career, I started with an infrastructure company. So this was a company this was a startup out of India called Pramadi. And they were building application servers, right? So this was back back in the day when you were kind of still thinking about application middleware. What is the plumbing you need to build software? That runs critical, you know, business software, right? That runs really really the business at the core of it. so th those were the first five years. I think I spent a good chunk of the time building, but I also spent a good chunk of the time selling in the field. So I had a little bit of a dual job because they had especially moved me to the US after the first three years where I was just heads down coding. and then the two years I spent here, I spent with a lot of customers and I And I really understood what is the difference between, you know, building something accurate and building something useful. Right. Like that that was kind of like the light bulb moment for me. So after those five years, then I joined Wiley because my thinking was how do I use my infrastructure and plumbing skills to to do something where I can leverage them, but it's still a little bit of a different area. And what I found as I was interviewing then was you know monitoring really fascinated me because I'm like, I understand plumbing really well. So I can use all of that skill to to really monitor something. and I sort of moved to that. And then also monitoring at that point, Java specifically was bytecode instrumentation where you would insert your own code into the customer's code and that would basically have probes. Which would send information where you're just then measuring it, right? So that seemed like I was fairly, you know, I was super technical. I wanted sort of some of those hard problems. So I kind of really looked at that combination and was like, okay, this is like a really good next step. And so I got into got into Wiley. and then post Wiley, about three years in Wiley, the last year of which we got acquired by computer associates. Yeah. And obviously Wiley was where I met Jodi and you know We were we were friends hanging out there, discussing problems, discussing the space and all of that type stuff. And 2008, you know, Ab Dynamics happened. that was about close to a 10-year journey. f yeah, you know, phenomenal, sort of super like hockey stick stuff and everything else. Very, very exciting, very, very privileged and grateful to be to be a part of that journey. and then after that, obviously the Cisco moment happened. you know, the IPO was about to happen, the Cisco moment then happened and then spent a little bit of time there, took some time off and then post COVID started getting into sort of like the next problem I wanted to solve, et cetera. So that's that's that's a little bit of background.

Brian Bell (03:59.861) That's amazing. and so what are what are kind of some takeaways from from the app dynamics journey? I mean, that's a very kind of blitz scaling kind of company, you know, going from zero to a hundred kind of thing.

Bhaskar Sunkara (04:09.25) Yeah, yeah, yeah. Yeah, yeah, absolutely. I think some of the early lessons were you know, most technical founders I think start really, really broad. but at some point, you know, you kind of have to realize what is the immediate pain you're solving. It's not about sort of like how architecturally strong your product is, how you know, how much of a solid platform it is, but are you solving an immediate problem? So we in fact started out with something broad where we're like, okay, we'll we'll do capacity management for elastic compute, you know, where cloud was new and we were like, this is a great way of how you manage your application because you can you can sort of define your capacity up and down based on the load, the traffic that you're getting. but as we started talking to people, we realized that it was still early. you know, people were doing a lot of cloud but not yet in production. Like it was still still pretty early. And so we kind of really focused on the immediate problem where people are like, Look, if my application is broken, then I'm losing money. Right. and so that's the problem we really, really anchored on. we had some foundational stuff that was reusable, whether you use that for capacity or you use that for performance. So that really helped us. but we focused on, okay, let's focus on that that is the problem. And then we narrowed it down further. We're like, okay, let's only do Java because that's the predominant programming language. Let's not focus on anything else. and then we said, what is our persona? do we the the the intuitive thing at that time was to sell to the developer, right? Because you know it's code, you know, you're monitoring code. but we took a little bit of a contrarian view where we're like, okay, let's let's focus on who's actually running it in production, right? who has the pain. and so this was the time when there was some separation between dev and ops. So there was the operations team. Cause you know, at some point it became DevOps and and honestly, DevOps is still sort of like a fuzzy concept in terms of like all the strong devs who are building all the time. You know, it it's hard for them to, you know, completely own, have ownership of ops. But then once w at that time when we had the ops team, we're like, that's the buyer. So let's build something for that, for them. and then all of these points I'm happy to drill down further. But like the third point was what do we kind of what environment do we build it for? Again, you know, the intuitive thing thing at that time, along with selling to dev was that build it for dev, build it for test, build it for staging, build it for production. And we said, we'll build it only for production. We won't build it for anything else. So if you want a dev license, it's gonna cost the same thing. Right. And so what happened was we did not build a ton of like developer ish features which again had different value, different ROI when you actually deploy it. and I think, you know, those decisions actually helped. you know, helped a lot. Yeah.

Brian Bell (07:10.184) Yeah. You know, it's interesting. I'm I'm early enough in tech. you know, I was at Rocket Fuel and we had our all our own data centers and we had our ops team and we had what we called mission control, which had, you know, all of our servers on a sc on I don't know how many screens, you know, thirty, forty screens. And maybe you could talk a little bit about sort of the why DevOps is is kind of a fuzzy term.

Bhaskar Sunkara (07:18.936) Yeah. yeah. Yeah. Yeah. Yeah. Yeah. Well, because I think it's it's kinda like the responsibility part, right? Like who takes who who takes accountability of that? 'Cause you know, operations is a full time job, you know, development is a full time job. And I mean sure, you can bake in a bunch of practices that you're that you're doing as you're building to make sure you're operating it well. you know, but when when the page comes in, when something's off, etcetera, you you need some accountability there. And it's kinda hard to have the same people in charge of both. So you have to have a little bit of a skew on like and that's why like SREs came in and you know things like that who are who are very focused on site reliability versus the the the site relia site reliability engineers. Yeah. Right. yeah, that's right. That's right. I should I should I should qualify. Yeah, absolutely. That that's when

Brian Bell (08:18.362) S R E meaning Yeah, yeah. Maybe some people don't know what that is, but yeah. Yeah, yeah.

Bhaskar Sunkara (08:27.834) so yeah, so that's why it's kind of fuzzy because you still have to have some clear ownership and accountability because the application you're running, you know, the situation I'm talking about is is is running the business. So it's really critical. you can't afford downtime and you have to have like rigor in both disciplines. And that's that's when it's it gets hard if it's the same person doing it. So you have to have like some structure around it.

Brian Bell (08:52.776) Yeah, I would imagine you guys considered, you know, going strictly open source or kind of how did you guys think through that? You know, 'cause a lot of tools like you guys that are focused on devs or dev ops or ops are they they they go open source. How did you guys think through that?

Bhaskar Sunkara (09:09.632) Yeah, no, I think I think we yeah, it it never came up for us because we always thought about ops. You know, we always thought like we we we sold to the head of ops, we sold to sort of the line of business which was operating the the software, right? Versus pure engineering which was building it. and one of the things with that team was that they really did not understand the code. So so before App Dynamics, if you if you look at just the history of monitoring, What you really monitor is the infrastructure, right? Like you look at code, you look at CPU, you look at queries. Those are the things that you're really, really monitoring. and those were all owned by development, right? So it was very hard for the operating team to actually operations team to actually own it. So that was kind of the main issue as the transition to the operations team operating it was was basically happening. And that was always a very, very hard problem. And so yeah, so we we we never really thought about like a developer centric open source type of a you know, solution if that makes sense. Yeah.

Brian Bell (10:20.466) Yeah. So you did production POCs when nobody else in enterprise did that. sounds simple in retrospect, but like what did it actually require to pull that off?

Bhaskar Sunkara (10:25.826) Yeah. Yeah. Yeah. Yeah, I mean, you know, the the philosophy behind that was obviously, you know, the market almost felt saturated at that time. There were a lot of like, you know, there were a lot of companies that were doing you know, monitoring, including where we came from, right? Like we came from Wiley and Wiley was one of the leaders. but obviously one of the things with Wiley is that it was very focused on code monitoring. Like it was kind of just looking at Here's you know, tell me what your code is that is the most important part of, you know, the application and we'll measure that. We'll put probes in it, we'll measure it. tell me what your most important queries are, we'll track those queries. And if that query is starting to become sort of higher response time, then we'll track it. So that was that was kind of what you know while he was. But we wanted to get aggressive on How do people sort of trust us? And one of the things that people had a reservation with application monitoring was that it was kind of risky, as in it could break the application and they were burnt by that a lot. so that was a big part of it. And so from day one, we designed a lot of the you know stuff that we built, the the the agent infrastructure that we built that would live in the apps to be very, very solid, very, very secure. And that's the reason why we sort of were like, okay. Let's sort of take the risk and say, don't run the POC in like some staging environment. Run it. Put it in production. because because honestly, monitoring isn't really believable in a sandbox, right? Because it's not yeah, yeah. Yeah. And then also like I think there there's so many other factors. Everything is wired up in production, not just the traffic part, but you know, real production database, you know, everything is kind of wired up differently.

Brian Bell (12:04.372) Well it's just not enough traffic. You have to kind of fake the traffic and yeah.

Bhaskar Sunkara (12:21.378) And so production POCs were really forcing honesty. So it gave us the best chance to shine. and also, you know, separate topic, we can talk more about that in detail. That's what led us to say, you know what, let's just put a download out there. Because no monitoring at that time was self service. Right. we were the first ones to put, you know, do self service. This was this was back in like May of twenty ten. and and what was surprising for us, you know, it was a pleasant surprise, was people were you know downloading the App Dynamics Lite product. That's what we called it. and when we called them saying, Hey, you know, this is our production agent, you could actually put it in production also. We're we're actually that confident. And the first time someone said, we're already running it in production, unaided, you know, we hadn't talked to them.

Brian Bell (12:58.45) Right. Yeah.

Bhaskar Sunkara (13:14.496) I think that was the moment where like, okay, you know, I I we we always had the confidence, but this is great validation and then we kinda double down on that strategy into the enterprise.

Brian Bell (13:24.946) Yeah. And it's that light product that actually drove something like sixty percent of your leads, which led to the six and seven figure contracts. yeah. It turns out like free trials and freemium products really work, right? And and if you could get people to self serve, deploy it and see the value, then then they start wanting to scale it and use it everywhere. And yeah.

Bhaskar Sunkara (13:29.358) Correct. Correct. Yeah. Yeah, absolutely. Yeah. Absolutely. Yeah. Yeah, yeah, yeah. Yeah. Yeah, absolutely. we're we're kind of doing the same thing with what we're doing, you know, we'll get more into it as well. But we we just we just launched that a couple of days ago where you can you can go on bicycle, you know, you can click on start for free. We only ask for your email, it doesn't even pop up a form, it's just your email. it is sort of like a vertical solution, so we focus on, you know, certain verticals. but then you can actually just start your trial just with like, you know

Brian Bell (13:54.068) Yeah, yeah.

Bhaskar Sunkara (14:17.42) the data that you have. and then and and and so so yeah, so we we just did that a couple of days ago. Yeah.

Brian Bell (14:23.346) Yeah, that's amazing. So it's January twenty seventeen. The team's in New York. You guys have bought suits. You're about to ring the Nasdaq bell and then Cisco comes in with a huge offer. Walk me through that, what happened there, you know?

Bhaskar Sunkara (14:28.984) Mm-hmm. Yeah. Yeah. Yeah. Definitely like a roller coaster, right? Because some of us knew you know, what was happening in the background. most of most of us didn't. and so it was a surprise to everybody and you know, and obviously when you're all set to sort of like go ring the bell and do all of that and then suddenly you're like, you know, something else happened. obviously it takes some time for people to really react to it, people to get sort of like really take that in. and so so yeah, so we did spend some time making sure that, you know, if you know, everybody had a soft landing in terms of absorbing what had really happened. But the but the obviously the number associated with was very large and, you know, at that time it was almost like sort of a big moment for

Brian Bell (15:22.92) Well, at that time you guys are gonna IPO for what? And you know, Cisco came in for four billion or something like that, right?

Bhaskar Sunkara (15:28.502) Yeah, yeah, yeah. Yeah. So we we got sold at three point seven. I think we were gonna probably float at two plus. So so so the number obviously. Yeah, yeah, yeah. Yeah, absolutely. so I I think there was the initial shock of you know, I was gonna go ring the bell. But then when you look at everything, when you look at sort of like it rationally, I think people people understood it was a big moment for us, it was big success thing. so it kinda settled down, but it was pretty dramatic because

Brian Bell (15:35.186) Yeah, so it's like a two X offer. Yeah. Yeah.

Bhaskar Sunkara (15:58.484) Everybody was in New York. I still remember the I still remember the hotel. I still remember like that that was it was still yeah. But the but but but the other thing that happened was that, you know, Nasdaq said you guys were so close that they eventually got us to come in and ring the bell with Cisco. So we actually had that moment where we went in and rang the bell because we were like literally overnight, you know, just away from doing that. So we did actually do that. so my my my memories are sort of like all

Brian Bell (16:03.049) Wow. wow.

Bhaskar Sunkara (16:27.458) fuse together on the one that was about to happen and then, you know, eventually when we did go and ring the bell.

Brian Bell (16:34.226) Yeah, that's amazing. and and so you stayed, you stayed on for a couple of years. most people flame out inside the acquirer in less than twelve months. What did you actually learn in those two years? that's now showing up in what you're doing.

Bhaskar Sunkara (16:42.55) Yeah. Yeah. Yeah, I mean I think it's just more at more appreciation for the enterprise. because I mean Cisco had like, you know, tremendous scale, right? Like so and the deals they were doing were very large. And so how you sort of like really work through them. You know, towards the end of you know app D before it was getting sold, we were starting to do really, really large deals, right? but then that was pretty much the regular thing that happened at Cisco. So so that was kind of That was kind of a good thing to absorb. it was also new because most of it was hardware and like, you know, honestly, none of us had that exposure. We were all software people, started off with Java programming. So very, very different. so a lot of difference within just the scale at which things operate, but mostly how that that scale of like enterprise customers really buy, what those cycles are. how are the what do they call that? The executive briefing centers just different level, right? Like we had a A B C when I saw Cisco's, I'm like, Yeah, this th this is this is like next level. So those are some things that you kind of appreciate that you kind of learn and you you you kind of understand large scale enterprise customers better.

Brian Bell (17:49.844) Mm. Right. Yeah. Right. Yeah, it's like walking into like a Davos conference room or something like that. I yeah, Microsoft had them too. And yeah, they were quite quite the quite the event. And then you could you could sign up for these and you you were required at Microsoft at my level to like actually show up to these. You're like, okay, you haven't done one of these in sixty days or something. You need to go like talk to executives from you know, UiPath or whatever it was at the time. So tell us about the origin story for for bicycle.

Bhaskar Sunkara (18:08.46) Yeah, exactly. Exactly. Yeah, exactly. Yeah. Yeah, yeah. yeah. Yeah, yeah. Yeah. Yeah, yeah, yeah, yeah. Yeah, so I mean, you know, I'd like to think that there's definitely some continuity from what I was doing at App D and you know, what I'm doing at Bicycle now. Like in a very, very simple way, if I were to describe it in one line, Abd was a journey of how do you go from technical signal to action? Right. Like so your your response time for like checkouts are not doing great, you know, it's not doing great. So how do you how do you diagnose it? Like what is really happening and how do you fix it? But you apply that to a business. so to summarize bicycle journey, the bicycle journey is more of a business signal to action, right? Because when you say business signal, you're like, you know, you're talking about orders, you're talking about payments, you're talking about bookings. because we really focus on we really focus on retail travel and payments. We focus on transactional businesses. but generally the story is like the business signal to action. So there's there's some parallels in there, but Business signal to action is a much, much harder problem, much, much harder journey. And just to teed up on why it is difficult,

Brian Bell (19:42.162) Yeah, I mean what is business signal to action? Like tell us what that is and yeah.

Bhaskar Sunkara (19:45.014) Yeah. Yeah, yeah, absolutely. Absolutely. So let's say you're a travel company, your bookings are down, right? you're a you're a card company and your payment approvals are down. Because that's what really matters at the top. Like for ex and and and it's also down. Correct, correct. It's it's an operational business metric. and so when that is off, or take something as simple as like my checkouts are down in San Francisco, right? It's something as simple as that.

Brian Bell (19:57.011) Yeah. There's some sort of operational business metric that you're tracking. Yeah.

Bhaskar Sunkara (20:11.52) And and typically that will proxy up to revenue, but my revenue is down in San Francisco. So now the next step is like why is that happening? Is that like a inventory problem? Is that a supplier problem? Is that a competitor pricing problem? Is that a technical problem because, you know, somebody made a change on iOS so and so version and people are not able to check out in your revenues dropping? So there's like about

Brian Bell (20:33.522) Yeah. Kinda strikes me as almost like a like a almost like a Fermi equation, right? Or like you you have all these like you you have all these steps and each of those steps have component pieces. And so you have to break down. Yeah. So yeah.

Bhaskar Sunkara (20:37.559) Yeah, correct. Correct. It's a decision tree. It's a decision tree, right? It's a large decision tree. and the decision tree is not restricted to technical and it's not restricted to business factors. It's a bit of both, right? Because it could be a new release that broke the app, it could be your pricing strategy, it could be because competition is pricing more aggressively than you're you're doing. It could be because your your your your campaign is not plugged in properly. And it could be any of these things.

Brian Bell (21:10.089) Yeah.

Bhaskar Sunkara (21:11.104) It could be doing better because your campaign's working great. So how do you sort of like really figure out what is the right factor that's causing it and then take action because you have to get the revenue back on track. You're losing money. Right. So it's almost like decision making towards sort of like revenue management, you know, tracking revenue. And and you know, obviously you can use decision making for all sorts of other purposes, but we we we choose to focus on revenue criticality. And that's that's kind of the goal. And that's really a business signal to action, you know, in short.

Brian Bell (21:47.91) Yeah, so where did this idea come from? Like what was the aha moment where you're like, Okay, this is this this is a problem that we want to go solve.

Bhaskar Sunkara (21:52.278) Yeah. No, I think Yeah, I mean some of it is has some sort of links back to, you know, Ap D. so so Abd definitely, like I said, was technical signal to action. But during the later years of Ap D, we introduced a product called Business IQ. And what what that used to do was when there's an outage, it would tell you the impact of it. Right. So for example, when checkouts failed, we're like, okay, here are all all the people that got impacted by checkout. Because we did that for a retailer, because the retailer wanted to get a list of all the people impacted and then they would want to send them a gift card. Right? Like it was actually that simple. and so the origin of it was that in terms of what about being more proactive? Right? Because reactive is something happened, let me figure out impact and then deal with it. But what about you ran your business with basically saying? Here's my key cohort of customers, and I'm gonna stay on top of all those KPIs all the time. Right. So over the years, I think that's kind of it evolved as. and so and eventually I think it's kind of now taking up shape and how the market's like really picking up and because you know, one of the struggles I had was that where does it live? Like, does it live in observability? Does it live in analytics? Right? Does it live in

Brian Bell (22:58.355) Yeah.

Bhaskar Sunkara (23:18.604) the technical audience, does it live with the business audience? Like where does it kind of live? And it took us some time to figure that out. But that's what I would say was the origin because I'd like to think that I'm I'm I'm just kind of chasing that problem on what is the operating metric when software is running your business? Like does that make sense? Like at the core of it, that's the problem I think that that I've been thinking about.

Brian Bell (23:39.39) Yeah. And so this time you're CEO, not CTO. I mean you spent eleven years as, you know, CTO, head of product. what's harder about being CEO than you expected?

Bhaskar Sunkara (23:46.467) Yeah. Yeah. Yeah. Yeah. Yeah. Great question. let's see. I think I think with CTO, one of the things is that you always chase accuracy, correctness, you know, architecture, just like being really solid on that scalability all up front. And then w w with CEO I think

Brian Bell (24:07.988) Scalability, yeah.

Bhaskar Sunkara (24:15.136) Everybody's following your emotional signal and you have to be very clear. You have to have clarity. and then when you're chasing too many things, then you're creating confusion in the company and you have to create clarity. and then creating clarity is easier said than done. It's like you you have to you have to separate the way you work as an individual where you're sort of like all over the place and you're kind of chasing multiple threads and what signal the company's picking up from you so that they're they're kind of on that path. So and i it's not the it's not a easy switch because you you're just used to sort of like experimenting and tinkering and everything else and and so that's a little bit of a deliberate muscle that you have to, you know, develop. But I I would say that's probably the the the biggest difference, yeah.

Brian Bell (25:08.308) Yeah. So there's probably, you know, some VCs listening to the podcast are like, okay, how far along are these guys? So how far along are you guys?

Bhaskar Sunkara (25:14.274) Yeah, yeah, yeah. Yeah, no, I think we are we you know, we have our initial set of customers, we have reasonably sort of like mature deployments, pretty solid deployments already. But one of the things that we've been doing over the last year or so have you know, because the technology is moving so fast that we've we've been kind of like redoing, rebuilding what it was, right? Like when we started off, we we kind of built like an automated Data analyst that sits on top of your data and kind of really helps you with finding patterns, finding signals in your business, and and staying on top of them so that you can actually operate the business better. but what we realized is that the the lift to get there, even if it was super, super useful, was a lot, right? So as LLMs came in, we kind of wrote the layer of like Not just having like an automated data analyst that we had built first, but also build the automated business analyst on top of it. Right. Where the business analyst is basically saying, you know, what are the what are the KPIs that actually matter for your company? Like having an opinion on, like let's say you're you're you're a certain company, let's say your price line, what are the what are the KPIs that matter? What are the dimensions that matter? Like what, you know, are these suppliers, are these sort of like airlines, are these sort of like, you know, hotels that I'm working with? then you move on to what are these signals and the patterns that matter, like, based on the business. for these signals, when they go off, what are the potential causes that matter? Again, inventory, supplier, supplier issues, technical issues, et cetera, et cetera. And then what could be the potential actions be? Right. So we kind of build that layer which is the recommendation engine of doing all that. So we basically build like an automated business analyst. And then at some point we realized that the the the agentic part of it, which is can we automate, you know, going from raw data to building all these recommendations and onboarding all of that ourselves. So so the user is actually pretty much set up and we can do self service. So for the last year or so I would say, and so that's why we we just did the launch a couple of days ago. so the so the good news is we we have our sort of like initial set of customers and but the markets sort of evolved a lot. you know, and and we also found the right sort of area to really really really you know attach to which is the analytics becoming agentic. And so we we we kind of chose that part of the house because eventually it's business data that you're working with. and so so so yeah, so a bunch of that sort of being figured out. But

Brian Bell (27:53.502) Yeah.

Bhaskar Sunkara (27:59.266) But yeah, we're pretty excited about like the self service part of it because like there's no like deep analytical solutions that are really self service. And so it'll take some time for us to just build the momentum around it. But but but that's where we are. it's super easy for anyone to check out what the tech is because they can actually test it right now. So that's the easiest, right? Like I, you know, I can go all day along with sort of telling you about like all the coolness and law architecture versus like, okay, you know. It's it's it's out there for there everybody to see. It's got like a pretty extensive website which talks about the tech and the approach and the use cases that we solve. and and the tech is out there for for anybody to take a look. Yeah.

Brian Bell (28:38.44) Yeah. And and and one of the things that you you decide as CEO and founder is, you know, kind of the product roadmap and like who's your customer, like how broad are you going? Are you picking verticals? T walk us through kind of how you pick picked the verticals you're in versus going just, hey, we're just like this do everything platform that's horizontally applicable.

Bhaskar Sunkara (28:46.966) Yeah. Yeah. Correct. Yeah, absolutely. so so at a basic level, we obviously support you know, travel, retail and payments, and that's a proxy for transactional businesses, right? And the reason why we pick transactional businesses is that you know, when you use data to do to drive decision making, the sense of urgency comes in when you're a transactional business. Because if you don't do that in time, you are losing revenue, right? So so imagine you're doing analytics for like you're let's say you're a B D V company and you're doing analytics. a lot of times if you have an insight, you usually have a quarter or a couple of quarters to get that right and to fix it, right? Because you're like, I see some pattern with this customer. Like so okay, you know, take you know, work with your customer success team, work with your rep, and eventually they're gonna most lik you know, if you're executing well, more often than not, they're gonna get it done and and get the revenue back on track. 'Cause you you your renewal isn't in your extra. I mean, obviously there's consumption based pricing, etc. But I think in in in retail, whether it's travel, whether it's retail, et cetera, you tend you you will lose money if you're not sort of like fixing that problem and if you're not making the right call. That's why we chose that, right? but obviously building a this real money on the line. Yeah, there's real money on the line. but obviously building like a platform that actually

Brian Bell (30:15.732) Yeah, there's real money on the line, right? That yeah. Yeah.

Bhaskar Sunkara (30:24.642) Then takes on vertical context definitely is harder. And that's kind of what we've built. But we're definitely choosing to. So even if you go to the website, you will see that there are specific sections dedicated to verticals. And we have pre-built agents, right? Like that's one of the things also that took us some time. On it's not about exposing like a horizontal platform that someone can start using, but it's about Giving them saying, hey, here's my search conversion agent, here's my checkout conversion agent, here's my you know, payment approval tracking agent. Right. And so that way it's easier for customers to say, okay, here's the data you need for it. And then the agent does the onboarding itself and has all the recommendations you need to go. So so that took us some time to really package it like a vertical solution versus saying, we'll we'll work as a vertical solution once you set everything up.

Brian Bell (31:21.522) Yeah. So you you have a case study, urban piper, you know, and that claims you cut resolution time from days to hours across forty five thousand locations, which is pretty pretty impressive. Pull that apart for us.

Bhaskar Sunkara (31:26.082) Yeah. Yeah. Yeah. Yeah, yeah. So and actually I can apply the same thing to you know, very, very similar generally speaking. If you you know, you you typically have a KPI. Like your KPI could be Urban Piper is you know, middle is middleware for restaurant ordering. And so like you'll go from like the Uber Eats type of platforms into Urban Piper and then it will place orders on you know, onto multiples multiple restaurants, right? Same thing you can apply to something like a priceline where it's like you have all these customers that are placing the buying tickets from you. And what you're doing is you're going buying tickets from multiple suppliers. So it's kind of similar. There's a marketplace there, yeah. Because you you know, as a travel agency, you don't own the tickets, but you basically get it from different suppliers, et cetera, et cetera. So you're an aggregator, yeah, exactly. Online travel aggregator.

Brian Bell (32:11.506) Right. So mark it's there's a marketplace there. Yeah. Yeah, you're an aggregator. Yeah.

Bhaskar Sunkara (32:26.002) so but but what's happening is like let's say if you have a supplier in a particular region that has errors that you know that that that basically pro that happens when they're processing. And this typically happens, right? Like, you know, when you and I book tickets on, you know, orbits or price time or whatever, it takes some time for the ticket to come through because it has to be processed in the back end and then it then it comes through. So let's say one of the particular areas Has you know more errors than normal, then what we do is we go to the supplier, we we it's a very fine-grained way of determining that. And the closed feedback loop in bicycle actually determines that. And when it determines that, it basically runs a webhook to basically take the supplier out. Right. So it's a very surgical type of action and it's a closed feedback loop. And when those metrics are back to normal, only for that supplier, right? Like and This is not someone watching on a dashboard and making decisions. This is the agent watching all all segments for that metric, which is sort of like bookings or booking failures in this case, and then taking corrective action. And so very similar with the urban piper as well, like we are able to when they're when when the orders are dropping, we're able to figure out is that a menu related issue? Like cause sometimes is it an inventory related issue, is it a store related issue? And then we take then we take action. So So we the way we describe our technology is you know, we use an acronym called DEAL, like detect, explain, act, and learn, right? So you detect the KPI, and that could be like, my bookings are down for this particular segment. Then you explain, which is basically like is it a business factor, is it a technical factor? Like, is it a store or a menu level issue, or is the tech failing? Right. It could also be an external issue, right? It could be because well, for example, one of the cases we had you know, open fiber is that. Orders are spiking and they're up because it's, you know, Mother's Day. That's an external factor. It's ne it's you know, it's not like a you know internal, technical, or a business factor. It's not like an external factor. Or something happened with a competitor somewhere, right? And this is what analysts are doing all day. The amount of things they have to look at when they have to make a decision is is humongous, right? And so we are really kind of putting a framework where that becomes easier. Yeah, so that that that's kind of a, you know, really good example, really good way of looking at it.

Brian Bell (34:49.416) Yeah. So AI is kind of changing the modern data stack. the strongest version of this argument would be dashboards are dead. Do you guys do you guys believe dashboards are dead, or is it kind of just morphing and evolving?

Bhaskar Sunkara (34:54.531) Mm-hmm. Yeah. Sure. Yeah. I mean I think, you know, yeah, I think I would say dashboards are you know, dashboard operations driven by dashboards are kind of dying. That's probably the way I would use it. Cause you know, you'd you you'd still want to use a dashboard, as in you know, like when I want to look at like stacks in the company, etc. etc. you know, I'm gonna I wanna look at a dashboard. But decision making driven by dashboards, you know, I think that's that's gonna die because the The amount of things, the amount of dimensions that you have to stay on top of is just so much that it's just not humanly possible with a dashboard, right? Like so if you've for example, let's say you're you're looking at sales, you obviously cannot track the top line aggregate of sales because that's just two cores, right? You know, you're doing you you're selling, you know, you're selling fifty different products, you're you're doing business in fifty different regions. You have to track each region separately, right? So how do you do that in a dashboard? So I think operations driven by it are gonna die because it's just not sustainable. but dashboards in general, like obviously it's you know, it it's a good medium where you you're still sort of like using them in some form or the other, but you're not really making active decision making, especially when decision making is time sensitive. Yeah.

Brian Bell (36:23.25) Right. And and it creates a alert fatigue, right? I mean, if you're monitoring all these things and you have thirty six different things that you're looking at every hour, you just you throw your ha hands up eventually and

Bhaskar Sunkara (36:26.51) Correct. Yeah. And yeah. Correct, correct. Yeah. And then also like it it's it's a good way of like sharing sharing state. Right. Like it's a document you pass around. Cause you know, like otherwise it's hard to sort of communicate. It's a great communication medium. You lock things down, you're like, okay, here's here's here's revenue metrics, here's customer health, et cetera. So it's a good medium to communicate across a team, but it's just not a good way of doing operations.

Brian Bell (37:01.94) So you said publicly that you know we're over indexing on chat. What did you mean by that?

Bhaskar Sunkara (37:08.482) Yeah, I think what I mean by that is that when you start looking at AI to help with business operations or helping you with parsing out data, making decisions with data, I don't think the end state is people want to talk to their data. Because you're leaving the most important question to the user on if you ask the right question, if you ask the right at the right time. If you suspect the right thing, you'll get the right answer. And I don't think that's AI taking it far enough. Too many failure mode. Correct. Correct. I mean it's great to say, well, now you have the capability of asking a question from your data without knowing SQL. I don't think that's a win. Right? Like that's just not f correct, correct. Yeah, because you know, it it it's great that you can now talk to your data.

Brian Bell (37:44.03) Too many failure modes in that in that chain of thought, yeah. Yeah, tell tell smart, yeah. Unpack that, yeah.

Bhaskar Sunkara (38:04.722) you know, without SQL and ask questions in English. And I think that's something that's here to stay. That's similar to dashboards, it has a place, right? because you're curious about something and it data is much more accessible to you. Right. But when you're operating and you're decision making again, going back to the reason we called out dashboards, dashboard driven operations are not gonna work and chat driven operations aren't gonna work also because if you're relying on You asking the right question, maybe you forgot a particular factor. Maybe you're not drilling down into the right thing, maybe you're not looking at the right dimension when you need to look at it. Because there needs to be an AI that's actually looking at all your dimensions and surfacing a signal that you need to take a look at. But even that, it's sort of like doing a first pass on, hey, here's probably why this is happening. and if you leave it all to I'm gonna ask the right question at the right time. It just it just doesn't really compute. Like so that's the difference for me. It has a place because it makes data more accessible and that's great, but I don't think you can operate with it. Does that make sense?

Brian Bell (39:12.424) You know what it kind of reminds me of from a historical technological perspective is, you know, when we started driving cars, you know, the first cars had they had boat rudder levers as steering wheels. You know, we hadn't figured out to use a wheel yet. And then, you know, for you guys, I mean, another good great analogy is bicycles themselves, right? When b bicycles came out, you see the old ones and

Bhaskar Sunkara (39:19.811) Yeah. Yeah. Sure, sure. Yeah.

Brian Bell (39:38.643) You know, the eighteen hundreds in France with the big wheel and like the little wheel on the back. And you know, I think technology now with with AI and agents is changing what's possible. And we're and we're we're trying to shoehorn kind of the way we used to do things, the lever in in in the boat into the into the car, and that just doesn't work.

Bhaskar Sunkara (39:42.188) Yeah. Yeah. Yeah. Yeah, for sure. Yeah. Yeah. Yeah. It doesn't work Ag absolutely. Yeah, for sure. It's a good analogy. Yeah.

Brian Bell (40:03.356) Yeah. Yeah. I'm a I'm a VC. That's all I do is just think of an and analogies and historical analogies. so selling to developers versus selling to businesses, walk us walk us through how that's different.

Bhaskar Sunkara (40:08.588) Yeah, yeah. Yeah, I mean and I mean though actually Abd definitely we sell more to sold more to operations, but selling to the business is definitely much more nuanced, obviously, because also in this case what happens is that there is the business, but there's also the data and the analytics team, which actually runs it. and so it it really depends on whether you're selling to the business and they're gonna be going to be the primary users, but At the same time, who's gonna own the tool, right? Like in App Dynamics, the the tool was owned by operations people because they were the ones who were administering install of the App Dynamics agent in their JVMs or their machines, right? So similar to that situation, you're selling the solution, but the solution sits on top of your warehouse. and then the warehouse is pretty sacred in an organization, like it l not everybody gets access to it. you know, it's Pretty closely guarded in terms of like who gets access, who has access, and everything else, very governed. so so there is the data sort of team and the analyst team that's actually responsible to that as well. but in general, that's what makes the selling you know a little more nuanced. But in general, when you sell to the business, I think what we really focus on is anchoring on the KPI, anchoring on like the story, on You know, what happens when your search conversion is down, when your checkout conversion is down, when your payment approvals are down. and that resonates really well with them versus starting to talk about tech, starting to talk about how deep the architecture is, and stuff like that. Right. Like because they wanna focus on what they do day to day.

Brian Bell (42:00.255) So what are you guys excited about over the next year or two?

Bhaskar Sunkara (42:03.394) Yeah. I think w what excites us is basically as this as the as the AI stuff is taking shape, to me I think about so far a lot of you know a lot of excitement most of the excitement has been about AI for coding. All right, like AI for coding is really like predominantly the most prominent kind of use case. and I think slowly I think AI for analytics is picking up. and I think the way we like to Talk about bicycle is that for the data and the analytics team, it think of it as a cursor, right? The way cursor gave you an unf unfair advantage as a developer because it did the first pass, it did the repetitive stuff. And you had focus on what's the taste, what's what what do I have to sort of like think about, like what do I have to build that is actually differentiating? I think it does the same thing for the data team because the data team and and when I say data team, I'm I'm using analytics also as a proxy inside it. for them, I think does the first pass, if it's an investigation that's again and again and again, it does sort of like that recurring investigation. And you are able to sort of like, you know, tune it and govern it versus like, you know, versus sort of like always sort of doing things from scratch. so that's the theme that I'm kind of really excited about on how that really plays out and how I think if we can really develop as the unfair advantage similar to cursor to developers, I think that that's the thing that excites me.

Brian Bell (43:36.189) Yeah. I just had this experience over the last week. I vibe coded a new Team Ignite website. And, you know, I spent years and years in product management, probably eight years of my career, you know, working with d developers and designers. And it was just such a an interesting experience to go through the web the web creation process. This this thing that I used to do with developers, you know, 10, 15 years ago. And I could just as fast as I could tell Claude or Chat GPT, I actually mostly coded it with Chat GPT. The new five point six is really good.

Bhaskar Sunkara (43:41.294) Mm-hmm. Yeah. Yeah. Sure. Yeah. Yeah. Yeah.

Brian Bell (44:06.046) I actually I gave it the same prompt. I gave Claude a prompt, on yeah, yeah, on Sonnet and I gave a five point six prompt and I was like, go. And I I let it kind of go and make the website. And ChatGPT made a better website. I was really surprised. and so I ended up iterating with ChatGPT for took me about five days, but it was just like as fast as I could tell it stuff to do, it would just code it, you know.

Bhaskar Sunkara (44:09.646) Mm-hmm. Yeah. Yeah. Yeah, yeah. Nice. Yeah, yeah. Yeah, yeah. Yeah, yeah. Absolutely.

Brian Bell (44:30.804) It's such such a a furring experience. And the like how does that how does that feel on the ground internally building now? Because you you know, as a PM, like you probably could go code up the thing that you're trying to tell the developers and the designers to build, right?

Bhaskar Sunkara (44:45.088) Yeah, yeah. No, that's actually starting to happen a lot. Like I think that's why I think the team sizes are not as big as what they used to. and honestly, if you have so one of the things I work with my team on is give them like a really solid spec on what I want a service to be or like what I want the service to sort of like a certain way of behaving in. and a lot of times that helps as the foundation for coding up a service or even fixing a bug because again, you know, the knowledge work is so solid with with with that sort of natural language. and so the agent picks up a lot of that context. So at the end of the day, like I mean context is, you know, everything with that knowledge work. And so that's something we've been doing. So actually I've been doing both things. One is like, you know, doing the specs, but then also like using something like a notebook LM to really synthesize that spec so that people understand it because

Brian Bell (45:27.581) Right.

Bhaskar Sunkara (45:40.384) If I read a forty page spec, no one really wants to read all of it. Right. Like I I can I can I can synthesize that into a ten page slide deck and then people are like, okay, I I process it much better versus like, you know, I read through all of all of your notes, etc. Create a podcast. Yeah, absolutely. Absolutely, absolutely. Exactly. Yeah, exactly. So so that's been that's been, you know, that's been terrific. Like that's been very helpful.

Brian Bell (45:44.03) Right. Create a podcast for it. You know, just dump dump all the artifacts and notebook LM. Create a podcast for my devs to listen to about the thing that we're building. Yeah, yeah, I can s syn synthesize different kind of versions of the same thing, right? I yeah, I can't are are you how what is the dev process look like these days? Is it is it a PRD or is it is it even more agile than it was before or?

Bhaskar Sunkara (46:12.632) Correct. Yeah, yeah, yeah, absolutely. I think i i it kinda changes every month, but I mean at the l the the latest I would say is basically like a clot design prototype. That's yeah. Right now that's what it is because yeah. Correct. Correct. Correct. and sometimes

Brian Bell (46:31.996) Interesting. Okay. So get a clickable prototype, get it end to end in in in cloud design. Yeah. I wonder what what's that's what what that's doing to Figma's business. Are you still using Figma then as well if there's a UI aspect? Yeah.

Bhaskar Sunkara (46:44.928) Yeah, y you know, we do we do. So we actually we go from there to so sometimes it becomes the input 'cause 'cause a lot of times what happens is that if you have something very clear cut in your head, you sometimes struggle to communicate to your designers. and so so we do have the middle level, but it also depends on the sense of urgency. If you want to roll out something really quickly, you have that prototype and then devs can just build off of it. But you need something a little more elaborate where you need some sort of like collaboration and everything else. So so definitely for more of that chunk we still have Figma in the middle. but it's changing now. Like it's really evolving at such a you know, so so yeah, we do a lot of like cloud design prototypes.

Brian Bell (47:21.833) Yeah. Yeah, I I I basically just I dumped all my files in, my brand guidelines, all like my little FAQs, my pitch decks, like for for Team Ignite, I just dumped it all into AI and said, okay, make a website. Yeah. Made a pretty nice website. what are you guys excited about over the next, you know, the long term? What does like long term success look like, you know, five, 10 years away?

Bhaskar Sunkara (47:39.518) Yeah, exactly. Yeah. Yeah, yeah. Yeah. Yeah. I think long term success, beyond sort of thinking about sort of the you know, can we really pick up this sort of trend in AI and really be successful? I think, you know, honestly, decision making with data is one of the kind of big segments and then it goes dovetails into business operations. And so if we you know, if we can be the leaders in really bringing in that sort of change on How do you use AI to do that? But in a reliable sort of manner where it understands the business, where you have control over it. that's the part that really kind of excites us, right? And you need a very solid foundation for it. And you need all of the technical constructs, but you need to have a model of the business. You need to understand how the business actually works to be able to kind of pull that off, right? And so that's the part that kind of excites us where. you know, it's not just sort of like saying you're making data more accessible, but you go in into a company on day one and you're useful from day one, but day hundred is much better than day one because you have compounded the company context, company intelligence, and operational intelligence over time. And d you know, day one, if you said Hey, I understand like what KPIs are important, what what sort of movements in KPIs and what causes are important. Day hundred, you know it much, much better. You know which ones are meaningful. You know which decisions you took in agent were accepted, and so which ones are the right ones to run on. And so that's where there's a difference in, you know, I can just close this, code this up in cloud in a day, where it's just like, you actually built for accumulating that operating context over a year, over two years. And then at that point, you are an employee that's sort of like doing the the the the class of problem you're solving is revenue critical decision making. And so that's sort of like core of like how you're operating as a business. And so if we if we can kind of get to that level and have that type of impact, like that's that's the long term I think success. Yeah. Yeah.

Brian Bell (50:01.798) Awesome. Well let's let's wrap up with some rapid fire questions. what's a bet you made at App Dynamics that five years later looked really smart?

Bhaskar Sunkara (50:06.029) Gasher. Yeah. I still remember a slide where we were showing the the complexity of applications exploding. We were like multiplying bunch of servers or whatever the unit was on that slide and

Brian Bell (50:26.558) Service oriented architecture and you'd have all these like microservices all over the place. Yeah.

Bhaskar Sunkara (50:29.45) Yeah. Correct, correct. And then we were basically showing that exploding and then, you know, that that definitely came through. That was kind of important, yeah.

Brian Bell (50:37.032) Yeah, I you guys were right place, right time for that. what's a technical decision at Bicycle do you would reverse today if it were free to undo?

Bhaskar Sunkara (50:39.308) Yeah, yeah, absolutely. Yeah, I mean I think being a little more narrow in the use cases that versus like so because you know again as a as a technical founder you s you you start building so much platform and you know before validation. So definitely, you know, be more judicious in that, be more pragmatic in that, versus building out too much horizontal surface.

Brian Bell (51:09.244) Right. And that that's the tension that we were talking about earlier, right? Is the working from the problem and in as a CEO or a product manager versus like, hey, I'm gonna build this amazing, beautiful, scalable platform out, you know. and really, really go going down down, down, down, down, down to that, like r what what is that really hair on fire problem that we can solve? And we'll work our way back to the platform from that. Yeah. speaking of management, tell us about the

Bhaskar Sunkara (51:11.864) Correct, correct, correct. Correct, correct, exactly, exactly. Correct, correct. To the platform, yeah. Exactly. Yeah, exactly. Yeah.

Brian Bell (51:39.24) The hardest firing you've ever had to do. And what did you learn from it? Yeah.

Bhaskar Sunkara (51:42.028) Yeah. Well, yeah, I mean usually this is I mean they're not the obvious ones, right? They're brilliant people who are not either sitting in the right role because of the way things are set up or you know, the way they're operating in that particular structure. and so what happens is because they're so brilliant, you take your time to get to the point where you're like, I need to press the trigger. Exactly, exactly. but but

Brian Bell (52:04.4) Mm. Like, they'll figure it out. They're talented. Yeah.

Bhaskar Sunkara (52:11.938) when you when you get to it, what you realize is that you're also doing them a favor, you're putting them out of the misery because they kind of know internally that they're just not like really clicking in that in that role. so yeah, I've had I I've definitely had a couple of those and it's just painful and you keep hoping against hope that it'll get figured out. and it's kind of not just their fault, but it takes it takes time to really get to that. But like at the end of it you realize that you're doing them a favor.

Brian Bell (52:21.555) Yeah.

Bhaskar Sunkara (52:41.73) They're not enjoying it. You know, you you know it.

Brian Bell (52:42.098) Yeah. Wow. Yeah. And that and that's an interesting thing. You know, I managed a a pretty large team, not probably as large as you you did, obviously, to app dynamics, but we use at Microsoft, we used a situational leadership, which kind of breaks it down into a two by two. It's like, do does this person have high ability in this in this c case? And do they have high or low motivation in this case? Right. And you're trying to figure out like where that where that person is. And then depending on where they are in those those four quadrants,

Bhaskar Sunkara (52:48.184) Mm-hmm. Okay. Yeah. Yeah. Got it. Yeah, yeah.

Brian Bell (53:11.614) you'll apply different kind of management or coaching or delegation. I found that to be a really helpful framework. what's the most overrated metric right now?

Bhaskar Sunkara (53:11.906) Basically. Yeah. True. Yeah, yeah, yeah. over in metric probably is let's see. I don't know like like like number of number of customers or logos, because the it does not talk about what the what the deployment is like, what the value is like, you know, things like that. It can be very, very high level. At least that's what comes to mind when you maybe ask that question. That was the instant reaction. because i it it really depends on

Brian Bell (53:32.98) Mm.

Bhaskar Sunkara (53:53.172) Some logos, they're probably not using the sweet spot use case, some logos are just using something else. so that's what I've seen to be like maybe the most overused sort of you know, thing. Yeah.

Brian Bell (54:05.256) Yeah. You could have a bunch of free people signed up and not using it at all, not getting any value. But they're a logo. Yeah.

Bhaskar Sunkara (54:07.714) Yeah, absolutely. It's especially in the yeah, especially in the AI age, because they're like, this is such a cool, you know, demo. and even when they maybe did did a demo with some of what they had versus actually adopting in production is is very different. Right. So there's always a gap, which has always been an enterprise on you know, doing the POC, doing the demo versus like this there's actually the value that they're using it every day. Yeah.

Brian Bell (54:36.68) Yeah. Walt and and the inverse of that, what is the most underrated metric right now?

Bhaskar Sunkara (54:41.358) yeah, I think the the the time to value part of it, like especially when you think about the team that's adopting it, like there's no the it's not a easy way of like really measuring that part. I mean sure, you can you can use like whatever proxies like, you know, net retention rate and everything else, but even those don't really tell you the actual value of because a lot of a lot of it enterprise sales is is you know what I know is so much of it is relationships and you know And so it's hard to actually measure the trusted value, the the time to do that. and that's kind of a hard one to measure.

Brian Bell (55:17.332) What's piece of conventional VC advice you've gotten that you actively ignore?

Bhaskar Sunkara (55:22.638) Yeah, that's a good one, man. I think, you know, definitely, I mean, you know, VCs have their own networks of like senior go to market people. And I I feel like sometimes that can be pretty overrated. and so you you kinda have to be really focused on the stage you are and what needs to be done, et cetera, versus like because again, I think you know not everything cannot be just like patterns and sort of like fitting something into something. and so I think that happens l a lot of times when they're recommending senior execs and you just you know, that happened a bit inapte. You know, we we did that and it didn't work out and so so we kinda learned the hard way. But but that that's what I would point to. Yeah.

Brian Bell (56:08.242) Hmm. What is what is the best way to hire execs?

Bhaskar Sunkara (56:12.652) I think, you know, definitely spend more time than you like I mean the the the chemistry part is pretty important. but they have to be able to sort of like, you know, roll up their sleeves and talk about sort of solving a problem, even if that's not what they're doing like every day. but I've seen that the right execs are like, you know, i i if you have a head of sales and they're not able to do a good pitch, but they're saying, Hey, I'm I'm just like a good hiring machine, I'm gonna do XYZ. I I I don't know. I've seen that more often than not. It doesn't really work, right? Like, and so and then also a link back to the to business, right? Like on the other hand, like you take somebody who's an engineering leader and if they're like, I want to look at like hard problems, then only that's all also like so you have to have like that balance, but you have to have the ability to sort of like get your get your hands dirty. and if you don't have that I I kiss kinda sometimes feel like that's a little bit of a negative signal. Yeah.

Brian Bell (57:15.25) Yeah. Well, I've really enjoyed the conversation. Where can folks find you and Bicycle online?

Bhaskar Sunkara (57:21.218) just LinkedIn. So Baskar Sankara on LinkedIn. and then Bicycle. so we actually like I was mentioning launched self service a couple of days ago. So you can just go, yeah, good timing, absolutely. You can go try it out. Yeah. Just you know, it doesn't even have a form, it just asks for your email and we don't

Brian Bell (57:32.463) good timing. Yeah, just go try it out. Is it like an NPM kind of like just install right in in the code base kind of thing or

Bhaskar Sunkara (57:46.252) No, it's not an install in the code base, but it's basically what you do is like you you get a sign in, you get a magic link. So it's not even like a password, you get a magic link, you get there and you have a screen. We call it Wibe Analytics, which is if Vibecoding builds you an app, Wibe Analytics builds you an agent that does your analytics for you. And so you upload your data, you connect to your data, and then you you tell it it'll suggest a bunch of agents that are prepackaged. You pick that and then it builds it for you, and then it watches your data. Basically. Yeah.

Brian Bell (58:16.112) Awesome. Well, thank you so much for coming on. Really enjoyed it.

Bhaskar Sunkara (58:19.68) Absolutely, Brian. This this is great. Thanks for having me. Thanks.

This article is for general informational purposes only and does not constitute investment, legal, tax, or accounting advice, nor an offer or solicitation to buy or sell any security or investment product. Investing involves substantial risk, including possible loss of principal, and past performance is not indicative of future results. Full disclaimer.

Subscribe to Ignite Insights

Get Team Ignite's best writing on venture, product, and go-to-market delivered straight to your inbox.