Bulletproof Large Scale Data Science with Srini Raghavan, Chief Product Officer at Freshworks

So I think what the buyers are saying is, "I need outcomes, not necessarily a workflow software along with a bunch of integration that I have to do." So the core product capabilities in SaaS are still very valuable, and that's what the buyers are paying for. They're not paying for the workflows, the user experience.

What they're paying for is the capabilities that they get and the single data layer and the single platform on which their entire business is based off of, but they want it very uncomplicated. 

Richie Cotton: Okay. Yeah, I can certainly see how some of the platforms like, I don't know particularly enterprise software, it takes a lot of effort to set up.

You need to pay people to spend time setting up software and having that lower sort of friction. I just want stuff to work out the box makes a lot more sense. So but you mentioned consolidation, so do you think we're gonna have fewer pieces of SaaS software that do more things rather than lots of little tools?

Srini Raghavan: I agree. Look, here's the thing. There's a lot of software that's been written over the last 15 years, 20 years, and what has happened in the last 12 months, and maybe more so in the last six months, is the cost to build has pretty much gone to zero, right? You can wipe code any piece of software over a weekend.

But the wipe coded software doesn't necessarily hit the mark in terms of serving the needs of the customer. Look, I can build a CRM over a weekend, but I cannot actually get the data and the data sanctity and everything else even for IT. Like for example, take a IT service management system, right?

And we surveyed like 9,000 mid-market IT decision makers and they're losing about a quarter of their AI budget to the complexity. So they're building things, they're using AI, but what they're really wrangling with is the integration, the data wrangling. It shows up in the unified platform that we built.

Look, you had an ITSM system, you had an IT operations management system, you had an IT asset management system. Just in IT, you had three systems, and what they're looking for is, "I don't want three systems. I need a single system on which I can build my business on." So I do think that the consolidation is going to happen, and we will have fewer and fewer point solutions and more of a platform-based approach the customers are going to ask for.

Richie Cotton: Okay so how do you get to that? How do you get to the point where you have simpler software that is easier to use? What do you need to do differently to-- if you're creating your software? 

Srini Raghavan: Yeah. I would say you always start with sort of the architecture of what you really want. And it-- think about it this way, right?

Like the 7% of the buyers that we surveyed, they really don't want to rip and replace their systems. What they want is is the architectural agility. The stickiest tools that these customers want to use are the ones that employees love. And the way you do that is by providing to begin with, an architectural layer that is modular, and you give three things: the choice to the end customers of using whatever software that they want to use and however they want to use it, and second is ease of use.

For example, take the employee experience software. You probably spend a lot of time on Teams or Slack. If you're a company, you're either on Teams or Slack. Increasingly, customers are either on ChatGPT or they are on Claude, right? All the work gets done in those places. So as long as you provide a platform where there is a choice, ease, and finally the trust that you give to the users and say that, "Look, you can get your work done in where you are, and you can keep adding things to it."

Just as the example that I gave you, like service management. If I have a problem with Zoom, my Zoom is not working, then I should be able to go to the collaboration medium that I already use, like Slack, and just submit a and just ask, "Hey, my Zoom is not working," and it should be able to detect. And even better, it actually detects that even before you say that Zoom is not working.

It detects that, "Hey, Srini is using a LLM on his desktop, which is taking a lot of memory, and that's why Zoom is not expected to work well," and it automatically says that, "Okay, I need to reduce the memory." Things like that, right? Things that go from being very reactive to proactive, and that's how the customers are thinking about it.

What can help me make my life a lot more easier? And at the end of the day, the CIOs who are responsible providing the software to the end customers, they're becoming more like chief innovation officers. They're saying, "Let me take the best platform that's out there and let me provide the functionality where my employees are."

And thereby they're able to get their work done in a much more faster way. 

Richie Cotton: Now, Sanjeev, so y- you mentioned the idea that you should be able to access other pieces of software from Slack or from Teams or wherever or from your favorite LLM. So does that mean that the user interface then goes away?

Because you're always just chatting to whatever other pieces of software there are from your AI. Do you need to not care about like what the website looks like, what your app looks like? 

Srini Raghavan: I, I actually think on the contrary, user experience become a lot more important. It's not that you-- the importance of user experience goes away, it's the fluidity of the user experience that's important.

As I said, it's the choice and the ease of use. Someone might want to... There may be a field level employee, like we talk to our customers, one of them is a manufacturing firm, and they have two kinds of employees. They have knowledge workers and they have field level, like manufacturing people who are actually working on the floor.

The field level employees want to access things in their Slack app or in their Teams app. The knowledge workers on the other hand, they want to use ChatGPT or Claude and they want to access it in ChatGPT or Claude. And there are IT admins who want to access it in the application because they want to administer the application.

They want to log into we have a service which is used by thousands and millions of users, and they want to log into the application and use it. So what becomes more important is how fluid your user experience is and how you deliver it in a seamless way to different personas. I almost think it's not like user experience is not important.

What is important is personalizing that user experience to the persona that you're serving 

Richie Cotton: Ah, okay. Yeah, I like the idea that if you've got different groups of users using it, they're gonna want to do access your software from different ways, whether it's like point and click- Yes ... or whether it's from a chat interface or I guess maybe engineers who wanna write code to access it.

Srini Raghavan: Sure. 

Richie Cotton: So how do you approach building stuff then for these different users? How do you get to this level of personalization? 

Srini Raghavan: Yeah. A good question. So I've been doing SaaS for a while. It always used to be, we used to call as MCP. What's called as MCP today is different. So when I started I'm an engineer.

I was an engineer for 10 years and what's called as Model Context Protocol today used to be that there was a model, which is the data model that existed, and then there was context, which is how that data model works on, and then there was the user interface. So that was the paradigm that we had, and everything built on top of each other.

Now everything is modularized because some customers might say, for example, we have one of our it's one of the biggest AI data companies that's out there and they exclusively use our product through actually it's one of the cybersecurity companies. Cybersecurity companies, they're using our software exclusively through Microsoft Copilot, and they're moved away from using it from the user interface that we provide and use it just with the Microsoft Copilot.

Another one, which is a big AI model company, and they are increasingly using Claude to access the capabilities that we have. So when you build software now, what we are looking at is the MCP software that we introduced about maybe two, three months back, and we are amazed at how customers are using that.

And fundamentally, you need to rethink that you're not just building for humans, you're also building for these AI agents in different formats, and you need to think about how you modularly build things. It used to be an API dev- driven approach. Now it's like a tool call based approach so that you can provide the different parts of your software easily accessible from different interfaces.

So it's fundamentally rethinking how you build build the software. 

Richie Cotton: That's fascinating. You mentioned the idea that you've gotta build for agents as well as humans. How do they need to use software differently then? And how do you approach building for both audiences? 

Srini Raghavan: Yes. So humans care about the aesthetics.

Think about your own consumer favorite consumer app, right? Now, one of the things that I use a lot is LinkedIn, and I scroll through LinkedIn, it gives me personalized recommendations based on the content that I use. It surfaces up things that are of interest to me, and it makes it very easy for me to follow a feed or to connect with other people.

So these are things that are customized for me as an individual. Now think about it same in the enterprise context, right? Probably the enterprise software that we all use is is Microsoft tools, right? Microsoft Office, or maybe Google Workspace. These are all things that have been designed for people to make it easier for people to access the visual elements of the software because people are visual and they access the visual elements of the software.

AI agents, on the other hand, they are not really seeing things. What they want at the time of they are operating is the access to information. So context becomes very important. And how AI agents, how easy

it is for AI agents to get the context, think about in a ticketing ticketing world, right? IT. For example, if your checkout system on your website is not working, you want an AI agent to know why is this checkout not working? What system caused it? Was there a memory leak that happened? Was there a CPU overutilization that happened?

What is the exact problem? That doesn't necessarily require a visual element. The AI agent needs to know the context of where the servers are located, how these systems are accessed. So providing the context is very important for AI agents, while providing the visual experience is very important for human beings.

So when you design things for AI agents and humans, you gotta keep both in mind. 

Richie Cotton: Okay. Yeah. I can certainly see how AI doesn't care about like what font you use, what what the page looks like. It just wants the information. Yeah, you've gotta think about the, these two different things together.

Now, To think about, like, how you go about building this, who needs to do this? You mentioned you used to be an engineer, you're now a product manager. I feel like there's been a bit of a battle between these two roles recently. There's a question about do you need more product managers?

Do you need less product managers? Engineers think that they can just have AI outsource the product bit. Product managers think they can have, like- Yeah ... aI outsource the engineering bit. Do you think the teams have changed then in terms of how you go about building stuff?

Srini Raghavan: Yeah. Maybe four or five months back, I actually saw some video from Marc Andreessen from Andreessen Horowitz. And Marc said at the time that there is this Mexican standoff happening between product managers, user experience designers, and engineers. Just for the audience that don't know what a Mexican standoff is, it's three people standing with guns just pointing at each other.

Each one is pointing gun at two other people, right? And on one hand you have the product managers that say I can code now, I can design now." And user experience people are saying I can actually write the product specs and I actually deploy code in production." Engineers are saying I can actually do the product specs and I can also design."

None of them are wrong None of them are wrong but I think it's it's this product builder thing that's going to emerge. I'd be really surprised if in the next three to five years timeframe, we actually have these titles called product manager or user experience designer a software engineer or a tester or a DevOps engineer.

These are all things that they're like specialized roles that were built so that people can specialize in their own craft, and that's what happened in the last 15, 20 years of of building software. What AI has enabled with the tools that we have now is for people to be sort of experts in building the thing.

Like understanding actually what the users need, understanding what the customers would love to use, and finally delivering on those things in a very agile fashion. People used to do these waterfall models where it's a six months release cycle, et cetera. Even in our-- in, in Freshworks example, we we have a pipeline that's built.

We don't call it product builder per se, but that's what we are doing. What we are doing is, we, we-- when we talk to customers, we record those conversations, and there's a corpus of conversations because many people are having those conversations. We take that into a notebook LLM, we synthesize that information, and we say, "Okay, what are the themes that are emerging?"

And that's being fed into the pipeline of okay, now that we have all this data, what are the things that we need to build? So that sort of becomes the input to... We built an internal tool called a PRD Genie which takes into account the customer conversations that we have. A bunch of customers submit their requests.

"Oh, this is broken software," or, "Oh, this is a cool idea." So we take those requests. We also get inputs from our sales teams, our CSMs. We talk to analysts. We get inputs from that. So it takes all these things into account, and it comes up with a what is the product design document that needs to be there.

And that gets automatically fed into Figma Make. So Figma Make can take the product requirements document, and it'll come up with a prototype design, which then gets fed into Cursor. And the Cursor can actually code things, and it can create a prototype, and we can release it, go back to the customers, test it, and say, "Hey, is this what you want?

Did you like these things?" We can easily do an A/B testing, and based off of that, then we can release code into product. And this happens within a matter of one or two weeks. This whole cycle happens within one or two weeks. So we used to have these big bang releases in the past, but now we're doing, especially in the AI products that we're releasing, we release things every two weeks, we keep releasing.

Which is why I think the title-- we still have these titles at Freshworks, the work is getting done by individuals, and they are cutting across different functions and doing the work. So I think in the next few months to a few years, all these titles will go away and you'll just have a product builder.

So my title today is chief product officer, and then my title will cease to exist probably, hopefully in the next 12 months or 18 months. The new title will be like a chief builder officer or something like that. 

Richie Cotton: Okay. That's cool the fact that because I guess each part of the job has got the product engineering design role has got slightly easier, you can afford to go a bit broader in terms of your skill set and encompass each of those elements within your role.

I guess that's, let's say I trust you to say, right?

Srini Raghavan: That's right. Yes. 

Richie Cotton: Okay. Okay. And you also mentioned that being customer-focused i- is incredibly important. I think every company says, "Oh, yeah, we're customer-focused," but actually this is becoming increasingly important. Do you wanna talk me through a little bit more about this automation of collecting customer feedback then?

So you mentioned that sometimes I guess you have to speak to your customers yourself. Sometimes you're getting, I guess the sales team to do it. Sometimes you're collecting data from other places and you're stuffing it all in- into this system to be data-driven about it. Do you wanna go into a bit more depth about like what's involved?

Srini Raghavan: So I think there is nothing that beats talking to actual customers, and more importantly, talking to the actual persona that is using your product. So the different touch points that happen in an organization, for example, our CEO might talk to a CIO in a company. CIO's vantage point is different. They see it from a, "Okay, what is the ROI?

What am I getting? How are my users using things?" Then I might talk to a person who's like an actual VP of IT or a VP of customer support because I want to understand what their pain points are and what's working for them and what's not working for them. I have those 10 of those interaction every week.

I spend like at least half of my time just talking to customers and then partners as well. And then the next level, line level product manager will actually spend time talking to the users, like literally doing a follow me and looking at, okay, how are they actually using the product? What are the things that intuitively they are able to do, and what are the things that they are intuitively not able to do?

Research shows that in, in the entire SaaS software, there's about 80% of the functionality that's out there are never used, only 20% of the stuff that gets used. So what I would say is the different conversation-- and a CSM might have a conversation about "Hey, you're using this as a usage pattern," or they may talk about renewals, they may talk about something else.

A salesperson might talk about something else. So these are all different altitudes of conversations with different personas of the customer. The term customer that gets used is used generically. But I think most most of the quote unquote customer conversations are happening with different personas and at different levels in the organization.

The important thing is to synthesize these things to make sure that we are building the right thing for the customer, we are pricing and packaging it appropriately, and we are making it super easy for the end user to adopt the thing that we built. And and that's how we approach it.

Like for example, we had a cust- we have a customer advisory board, which is our top 20 customers. We meet them every every three months we meet them. And when we do that, we did this design session where we almost had a whiteboarding session with all our customers and said, "Okay, tell us what your pain points are.

Let me show you what we are doing." So those are the kind of in-person interactions that actually generate a lot of ideas, which then translate into functionality that we build for the customers. 

Richie Cotton: Okay. I love that idea of having a customer advisory board and you'd speak to "Okay, these are our most important customers.

We're gonna listen to what they say," and then you have other mechanisms for, speaking to everyone else. 

Srini Raghavan: That's right. 

Richie Cotton: All right. So what do you do when customers have really stupid ideas? 'Cause I think like everyone's human, they'll-- sometimes they want unrealistic things, sometimes they have bad ideas.

How do you go about triaging, like to make sure that you are actually building something sensible that, that will be used? Yeah. It's not those 80% of features that just get left unused. 

Srini Raghavan: Yeah. I don't think any idea is a bad idea, it's just timed badly. So we have this community forum where a lot of our users submit the user request of what they want.

Look, a Gail's Bakery that's in There's actually a thing called Gail's Bakery in UK and they are the baker cares about what they want, and they have two people using it. And then there is Seagate, which has 30,000 employees, and they care about other things. The, the beauty lies in, in providing the functionality that Gail's Bakery can use to their satisfaction and to Seagate that they can use for running their enterprise operations, right?

So like I said, there's no stupid idea. So for example, I'll give you a very simple example. Something as simple as, "Hey, I want an easy access to resolving something and closing a ticket," is a very simple thing. It's not something that a Seagate might submit, but a Gail's Bakery will submit.

But it is very useful for the for Seagate because it makes thousands of people be more effective. So the, the-- So when t- when cost to build is zero, the most important thing is judgment. How to, for a product manager or a product builder to judge what is the thing that causes the most impact. I mentioned earlier that 80% of the thing that gets never used, I think with the new paradigm, that's going to flip.

80% of the things that we build going forward will actually be used because now you're getting a lot of signals from customers. And also you can personal- as I mentioned earlier, you can personalize the things for each persona. That means, things that you build are used by that persona. So that's how you make sure that it's not like stupid ideas, but you're taking the ideas that are most relevant and has the highest amount of impact across the wide swath of customers.

Richie Cotton: Okay. Yeah. So a, a lot of it's just thinking carefully about is this actually gonna be used by customers who is this relevant for- Yeah ... and really trying to pin down the user story. That's right. Okay. Because we keep coming back to this idea that 80% of features of software don't get used, or at least by most people.

So because it's now much quicker to build new features do you think we're gonna see a run of pressure just to build more and more features 'cause that's the easy thing to do, and then you end up with all the bloated software? Do you think that's a risk? 

Srini Raghavan: Potentially a risk.

If there's no judgment involved and you're just building things, we have 70,000 plus customer base, and if you build every single thing that every one of those 70,000 customers want, then you're going to build-- Of course, the cost to build is almost zero, so you can build like really fast and product becomes so clunky that it almost seems like nobody can use it, right?

It's like I remember Apple, Apple came up with their with their iPhone. Essentially Steve Jobs said, it has the functionality of a phone, and it has a GPS, and it has a music player all put together in, in one piece," right? And same thing you-- But it was super elegant to use.

Yeah. You don't have to carry three devices, you can just carry one device, and all your songs fit into one device. That's the elegance of doing things. So when the cost to build comes to zero, the most important thing is judgment and elegance, and it's the judgment of of what is needed and how people can use it most intuitive fashion becomes very important.

So the fact that you can build really fast doesn't mean that you need to build a million things. It means that you pick the 10 things that make it super easy for people to adopt and to use and those are the things that you do, and you do that better than everybody else in the market. 

Richie Cotton: I love that idea of focusing on elegance, and to do that you need to have judgment.

So I guess th- that's the hard part, right? Is you need to figure out what's gonna add the most value. Are there any good metrics for this? How do you go about deciding up front is something gonna add value? 

Srini Raghavan: So I s- I say this to all my PMs, that a third of the job is actually building things.

Two-thirds of the job is about looking at the thing that we have built how are the customers using it? What does the adoption metrics look like? Which parts of the thing that we built they are using? We look at monthly active users, we look at the number of clicks, we look at the number of transactions that are enabled.

So different metrics based on what the functionality is. We look at different metrics for different products, but at the end of it, it's about usage. And then finally, what is the level of frustration? You measure the frustration of the user, happiness or the frustration of the user. So we have in-product surveys that we do to gauge, like these are not your NPS surveys that goes out to, an admin and the admin gives based on listening to 20 people.

Like these are like actual users that are using the product in the moment that they are using the product. Of course, we don't disturb them while they're using, but inside the product they get the surveys, and we sample approximately 5% to 10% of the users every month and get the feedback and say, "Okay, how is this how is the satisfaction of you using the functionality?"

So it's a combination of usage metrics and satisfaction metrics is what the signals are that we get to make it way more effective. 

Richie Cotton: Okay. That's really interesting to know. I think we talked a lot about building new software, but actually the, the software life cycle is much broader than that, so you do need to think about adoption and usage and- yeah. How are those later parts of the software life cycle changing then? Have you seen differences in how you approach increasing adoption metrics, for example? 

Srini Raghavan: Yeah. So what we have seen is in terms of the building things, the bottleneck right now is is the testing and quality management of and then how we release things.

So we-- you can almost do a canary testing where we say that there is a... so previously it was really hard. In consumer it happens very often where you can do alpha beta testing for for different cohorts of users. Now, what we are able to do in SaaS is do this A/B testing for different kinds of functionality.

Expose one, one type. When you have a debate saying that, "Hey, is user experience A good or user experience B good for the end user?" Oftentimes it's a judgment call and now you don't necessarily have to make a judgment call. What you can do is, let me give this type of functionality to this cohort of users and this type of functionality to this cohort of users and see which one sort of wins out and what causes the most engagement.

Think of this as, this happens in biotech all the time where people get the actual drug and they get the placebo and you test both the things at the same time and see if there is actually an impact. So that's how we measure the usage metrics and see which one works out and then finally we roll it out on the things that are actually getting a lot of user engagement and most importantly, the outcomes.

Like what are the outcomes that they're delivering to end customers? 

Richie Cotton: This is fascinating because A/B testing has been like a, a staple of software development and software improvement for, more than a decade now. But you're saying it's changing. So rather than randomizing people between users you're specifically picking cohort-- different cohorts for different features then, depending on what you think they're interested in.

Is that how it works now? 

Srini Raghavan: That's right. So it's almost getting the consumer ethos into enterprise software. In consumer ethos think about the the LinkedIn example that I gave you or X or Facebook. Think about your favorite consumer app. They keep testing these A/B tests all the time where they're testing it on one group of users some functionality, the other group, other functionality, other group of users.

In enterprise software, it doesn't happen as much because the cost to build things and the cost to release and the cost to test was very high. Now, since those costs have come down, almost the consumer grade kind of testing and experiences are coming in enterprise software, and that's what we are doing as well, is we get a lot more chance to experiment things and to try out things on our user base than than what I, I ever have experienced in my career.

Richie Cotton: Okay. This sounds like very good news, 'cause I think enterprise software has a bad reputation in general because it's-- there's a lot of very clunky software people use at work because someone high up in the organization has bought it for everyone, and it's the, the people actually using it don't get a choice.

So talk me through th- these feedback loops changing. Are we actually getting to the point where we can have great enterprise software that you can really actually enjoy using at work? 

Srini Raghavan: Yeah, totally. A-absolutely. I think when people said that SaaSocalypse has happened, I think SaaSocalypse has happened for this clunky enterprise software that somebody high up in the organization bought, and then the users have to just live with it now.

And these are usually three-year, five-year contracts, and people just have to live with it. Now what's happening is the users, although they didn't have necessarily have that big of a say in buying of the software, they do have a big say in how they use it and what they need from it, how they, how it can be personalized for them.

And the enterprise software providers who are nimble in delivering those things personalized to the end users are the ones that are going to win in the longer term. For example, we heard our customers. We heard that for, for them to build AI agents. So in Freshworks, we launched something called AI Agent Studio two months back.

And there were three elements that our customers kept asking for. The themes that came back is, "Hey, I want to discover what my automation opportunities are. I want to build AI agents very simple, and I want to operate those agents." So these things, and I don't want to have the industry talks about these FDEs, who are, like, these people embedded within organizations, and they help them adopt software, and these are, like, long customization cycles.

They said, "We don't want that. We just want it to simply work out of the box." And that helped us to build something out of the box, the Agent Studio that we built for them. We simply said, "Here are the three things that you asked for. Here are the three things that we can do, and we can do them really well, and it can get up and running in minutes."

And then they gave us feedback saying that this automation takes a little bit more time. Can you do this?" So we were able to rapidly trade on it and then give them the functionality that they needed to f- to discover the automation. Then they said your automation works on chat, but we have a lot of emails.

Can you do the automation for email?" So we were then able to introduce email in the AI agent as a channel. So you can see how rapidly, based on the user feedback, you can give them the functionality that they want. 

Richie Cotton: Okay. I love the idea of just really focusing on stuff that works out the box and doesn't require customization setup time and focusing on core features.

Is-- I'm wondering, is there a trade-off then between having that simple software that just works and having personalized software where you've got different versions for different groups of users that want slightly different things? And I think that's when things start to get complicated, right? How do you deal with this trade-off?

Srini Raghavan: So think of personalization versus simplicity, I don't think of it as a trade-off. I think it's more of you need to make the personalization v- personalization, the goal of personalization is to make it simple for the end user. So y- we can build a lot of functionality. The product can have a lot of functionality, but the thing that is needed for example, healthcare users have a great amount of emphasis on PII.

They want to protect the user's data. Like that kind of functionality, we can customize it and say that for this particular industry, have this functionality so that the PII data and their concerns are addressed in a very transparent manner. I almost think of it like think of the example of personalization as when you buy a car, there's different kinds of cars that you can go buy, but the one that you buy is what's personalized for your family.

I have a family of five, so I need a seven-seater. So I'm gonna buy a seven-seater car. But when I don't have seven people in my car and I'm going on a biking or hiking, I want to use the last two seats, just fold them down, put my bike in there, and then take my bike to wherever I'm going for biking, right?

So that is personalization. So the seats folding down and me being able to use the space for something else is personalization that is happening for me. Enterprise software is exactly the same thing. You want to personalize it and make so that it's very simple for the end user to use. 

Richie Cotton: Okay, so you're not building one car that is suitable for every different possible user with lots of different configurations of seats or whatever for, depending on whether you have a family of seven or just a single driver.

Okay. I like that. Now one of the kind of things we talked about is that a lot of software now involves like agentic features. Like sometimes, particularly with enterprise software, you tend to get AI features being thrust into it wherever, 'cause, AI stuff is popular.

There's a lot of hype around it. How do you make sure that the AI features are naturally integrated rather than being bolted on? 

Srini Raghavan: So look, this is a challenge that a, a lot of the incumbents face. It's the, it's

sort of the innovator's dilemma where our end users, a lot of them are used to the workflow software that they're used to, and they want to use it in manual workflows, and they want to configure things the way they want. But when the world evolves, and it has evolved significantly, instead of saying that, "Hey, here's a AI capability that's part of the workflow.

You can replace it with this, and I'm gonna bolt on." What customers are looking for is, "Hey, I already have a workflow. How can I make it more automated?" Think of a very simple example. Let me give you a simple example that we looked at last year, which is think about IT agents, human IT agents that can resolve different kinds of things.

Someone might be an expert in solving Windows issues. Somebody might be an expert in solving Mac issues. Somebody might be an expert in solving server issues. These are three different human beings that are experts in dif- evol- solving different things. Previously, there used to be a routing and and these, there may be, on any given day, these people might be getting a lot of volume on Mac because Mac introduced a new Mac software and there's a lot of Mac issues that are coming in because of that.

Previously, these three individuals were in their own lane, and they could solve only their areas of expertise, issues that are relevant to their areas of expertise. What we said is, "Let's embed a copilot for each one of them, and we will make a, a specialist into an expert in multiple things."

So what the copilot now helps is the guy who's an expert in Windows can also solve the Mac issues because we are taking the expertise of the Mac person and the knowledge that they have and embedding it so that the Windows person, if there is a spike in Mac issues, a Windows person can solve it.

And the way the issues are automated so issues are routed, is also through leveraging the AI capabilities rather than starting routing rules. So this is an instance where the workflow of these people have not changed. They're still there in the system that they have, but now AI is helping them to be more effective by giving them suggestions, by giving them recommendations on how they can be more effective.

And before even the issue hits a human being, an end user can solve it with their AI agents, by going to Slack and asking questions. So this is an example where but if the human has to solve it, they can solve it in the interface that they have. It's an example where you're not bolting on the AI capabilities, but you're bolstering the capabilities or the workflows that they already have.

I think it's the, the mentality shift between bolting things versus bolstering things that users already know. 

Richie Cotton: Okay. I do like the idea that you are considering what the user's workflows are and using AI to assist them rather than just being like, "Oh we thought of a cool AI feature.

Let's just dump it in the product and then see if anyone actually uses it." We're back to that idea of judgment about adding product features again. Okay. I'd love to talk a bit about career skills. So you talked about having AI help people in their work. Now particularly if you're a, a software builder or you're a product person, what sort of skills do you think are going to help you navigate this kind of AI wave?

'Cause the, when you've got AI assistants I feel like product jobs are changing a lot. What do you need to know to stay current? 

Srini Raghavan: I would say judgment. I think the most important skill... Look, when I started my programming career, I was-- I started in school. I was doing kernel programming, which means I was literally using-- I was reprogramming the kernel, and I was doing that using C.

Which I don't know many people recognize now. So I was doing C programming, then I was doing C++ programming, then I did Java programming then I did .NET programming, then I did Python. So my skill set as an engineer was learning new languages and my expertise was learning these new languages.

Syntactically, they're all almost similar but you're learning the nuances of every language. Th-then I actually became an an investment banker where I had to learn a new tool called Excel, and I had to become no pun intended, but I had to excel at Excel, so to speak. Then it was about learning financial modeling.

Then when I came into product management, I was learning Jira the tiering system. Then I was learning Figma Make because I wanted to learn about design. So my career has been about learning different tools, different languages, different syntaxes which gives it-- which is good, but the underlying thing that I developed over a period of time is judgment and intuition.

And now what I would recommend for people who are early in their careers is to build that judgment, build that intuition. Because the cost of learning a language is almost zero because, Cloud Code or Codex will build the thing. Just give it a prompt and it'll build it in the language of your choice.

So that's not important. But what's important is, did it do the right thing? Did it optimize the things in the right way? Can it be production grade? What are the scalability things that I need to consider? What are the usability things that will come up? So j- in the design when you're evaluating. So these are the things that are way more important than knowing what language it is and what syntax it is.

That is less important right now. So English is the new programming language, right? You don't need to know C or C++, Java, all those things. English is the language right now. So you can use your you can use plain natural language to build things. And when that happens, then what's important is judgment.

So I would say the most important thing is judgment and the taste 

Richie Cotton: Yeah I love the the idea that you don't need to worry quite so much about code now, but you do need good judgment. That seems to have been a recurring theme. I'm curious as to how you get good judgment. I feel like like every parent's like thinking about their child right now going, "I'm not sure my child has good judgment."

How do you learn judgment? 

Srini Raghavan: Yeah. Trust me, I have three little kids. You know- ... my four-- the, the youngest one is four, the oldest one is 10, and they all think they have great judgment. Better than me, and I'm sure they don't. In, in building software, the judgment comes from talking to end users, talking to your persona, understanding the market, what's going on in the market, and what's working.

So there should be almost be a obsessive focus on understanding the details of the user experience, understanding what the users want, and how can we do it not half one times better, two times better. How can we do it 10 times better? How can we improve their productivity, their workflows, and their efficiency by almost 10X?

And that comes from a maniacal focus on understanding the users. I'm intentionally avoiding customers. I like using the word users rather than customers because ultimately users are the ones that are using your products. And at the same time, understanding what is the thing that helps customers.

Now I'm using the word customers because the customers who are essentially the decision makers and understanding their business better. The judgment comes from understanding the business of the end users and understanding the user behavior. I think those are the two key elements that you need to understand.

You don't need to spend time now in understanding how the code is and how it's written and all of that. What you need to understand is, this product is used by a financial services company, which is a bank, and it has these kind of end customers. These are the kind of questions that they get.

How do I address them in the context of a community bank, for example? What is the type of customer? What are the types of requests that the community banks get? So I think the product builders need to spend a lot more time in understanding the business of the end users which will give them a lot better judgment.

And the taste, which I said, is by talking to the end users, spending time with the end users on how they're using it. So there's no replacement for that. 

Richie Cotton: Okay, so that sounds like good news for extroverts, bad news for introverts. You've gotta spend a lot of time talking to your customers and your users.

Okay.

Srini Raghavan: I would, I, I, I-- Look, I'm an introvert myself. I used to be a huge introvert and even n-now I need to spend time with a lot, talking to people I'm still an introvert, but I derive my energy from having genuine conversations with people. So if you're having a scripted conversation, you're having a conversation just for the heck of it, then it drains you.

But if you have an intellectual curiosity of learning things. Intro-- A lot of the introverts actually are really curious to learn things. I know one because I am one. So I think it's good news for the introverts as well because they can learn and be inquisitive about learning things.

And in some pla- If they really don't wanna talk to people, there are enough tools out there that you can get the insights from the conversation that the extroverts are having. But I think this is a moment where the introverts can use their expertise of being inquisitive to learn about things.

Richie Cotton: Absolutely. I feel like having conversations with users is gonna be a very interesting thing whether you in general e-enjoy conversations or not. Okay. You talked about your career history. You went through like several iterations of being an engineer, you were an investment banker, now you're a product person, and all these required big shifts, and you're having to learn new things.

So there's been this sort of theme of like continual learning. Talk me through how you've approached like dealing with these career shifts. 

Srini Raghavan: Yeah. Look, like I mentioned earlier, I don't think of these as career shifts. I'm a inquisitive person, so when I started my career, I actually started in support.

I was literally carrying a Motorola pager where I was getting paged in the middle of the night. I had to wake up to fix the servers. That's how I started my career. It gives a deep appreciation of how not to break things, which then led to me being a good engineer and how to build things that doesn't break and ruin the life of some other person that has to wake up in the middle of the night.

And then that led me to then I spent some time in professional services. Once you build the thing, somebody has to deploy the thing and actually be in front of the customers and implement things and see them use it. So I was in professional services after that, which then said, "Okay, now I understand all these things.

Now let me go become a product manager so I can build the thing." So that's what led me to becoming a product manager. Then I understand the nitty-gritty details of how things are, and let me understand the macro level of how the business decisions are made and strategically understand things.

That's what led me to being a investment banker, whereas advising boards and C-level on on strategic aspect like, how do I grow? Whether I grow organically and how do I raise capital for it or, do I acquire my way into it and how do I accelerate the acquisitions part of it?

Then I came back into tech. All of this was in tech, then I came back into tech and and then I progressively grew in my product management career after that. I think if there's one thread that I would say, the, it's it's being very inquisitive. It's being very inquisitive to know the various aspect.

Like I said it's this it's always having this beginner mindset. It's always like what Jeff Bezos said, right? It's always day zero at Amazon. So it's always day zero in your career. You wake up tomorrow and you need to be very enthusiastic about learning about something new. Career is just an arc.

It just comes by itself. I never solve for being the CPO of a company. I always solve for what is a new thing that I can learn and I also get bored. I get bored every 18 months to two years. So that helps because I wanna go do something new every 18 to, 18 to 24 months, I wanna go do something new.

Richie Cotton: Okay. I love that idea of treat every day as day zero. It's like, okay, I'm gonna wake up, I'm gonna do something today, I'm gonna learn something new keep my spirit of inquisition alive or inquisitiveness alive. Nice. All right. Dipen Chip, like what are you most excited about at the moment?

Yeah what's exciting you in the world of AI and SaaS and product? 

Srini Raghavan: Look, I-- A lot of people will say the most exciting thing is is the, is these AI models that are coming out every day and how fast is it to build things and to, to, to launch things and to test things, all of that. But I think what I'm most excited at right now is is it's a change in career moment for for the CIOs, for for the IT.

And take for example and these are the people that are driving the change inside the organization, especially the mid-market companies, right? Where you're almost taking a bet and saying that, "Look, AI is going to work." There's a lot of noise out there like this is the cool thing, and then there's a lo- lot of noise out there that AI is cool but doesn't really show value.

Somebody's taking a bet, and in every organization, somebody's taking a career bet and saying, "You know what? I will take this and I will make it work." And those are the people that I'm most excited to talk about and to help. For example, we have a we have a customer called AmeriSure, which is a mid-market insurance company, and they consolidated a ton of tools that they have into into for service.

And they and then they leverage AI agent capabilities to drive automation inside their company. Another example is New Balance. New Balance is a agile, what we call as an agile enterprise, right? They compete with Nike, and Nike has this huge budget while New Balance has to do with the budget that they have.

So what I am really excited now is how these agile enterprises can take on behemoths and punch way above their weight and and grow much more faster. That's what I'm excited about, is not necessarily the, the cool thing that AI brings in, which is, which in, in by itself is great, but how people are leveraging it to to grow faster and to compete more effectively.

Richie Cotton: Okay. Yeah. So not necessarily getting exactly over the tools more the implications of that the fact that everything's being disrupted. Yeah, certainly exciting times. I like that. Totally. And finally I always want more people to learn from. So who's work are you most excited about at the moment?

Srini Raghavan: I have I have a couple of things that I'm excited about now is num-number one is I really want to see how the models that are emerging can be run on personal devices. Look, we have this humongous amount of CapEx spend that's going on. People are building these massive data centers assuming that there is a lot of AI workloads that will come in.

But what I'm really excited to see, it's and there's a lot of startups that are doing this, is almost you can pick the right model for the right task, and you can make it run on your own personal device, whether it's your laptop or phone or endpoint device, whichever device it is. I'm really learning, I'm really intellectually curious to see how you can break this log jam of having to spend billions of dollars on spending data centers and a ton of equipment that you need to make it work versus making it work with the billions of devices that all of us already have and making it much more easier for us to use the power of AI in the pocket-sized device.

Richie Cotton: Yeah. That, that's cool stuff. I love the idea of AI on your own devices, like the idea- like edge AI. It's sort of- Yes ... maybe the next big thing in the future. Yeah looking forward to that. All right. Wonderful. Thank you so much for your time, Srini. It was a pleasure chatting with you.

Srini Raghavan: Same here, Richie. It was really a pleasure talking to you. Thank you.