← Building One with Tomer Cohen
Building One with Tomer Cohen
Building Glean with Arvind Jain: Scaling Enterprise Search with AI Innovation
00:48:09
Loading summary
Transcript75 lines
- [00:01]
Tomer Cohen
LinkedIn news.
- [00:07]
Arvind Jain
Innovation ultimately is solving problems.
- [00:09]
Tomer Cohen
It came back to my own personal pain point.
- [00:12]
Arvind Jain
It just takes a while to build that trust. The problem that I was trying to solve, it was all I was thinking about. You have to be obsessed with the human condition. I'm Tomer Coyne, Chief product officer of LinkedIn, and this is building one.
- [00:26]
Tomer Cohen
When we actually try to go and buy a product, we realize that there's nothing to buy. There's no product that would actually connect with all of those systems that we had and actually make things searchable within them. I was surprised. Like, this is not a problem that's unique to us.
- [00:38]
Arvind Jain
That's Arvind Jain, the CEO and founder of Glean, an innovator in the enterprise search space that is on a mission to finally unlock knowledge sharing within a company. He's talking to me about the pressing need that put him on this amazing entrepreneurial journey to build Glean. We're going to get into that and so much more. So stick around. If you worked at a company long enough, you've definitely felt this pain. You wanted to find information that you knew existed but couldn't locate. Maybe it was the company's dental benefits policy or the specification document your colleague wrote right before she left. Maybe even your own files. And you might have wondered, why is it so easy to find something on the Internet, but so hard to find it within my own company? I've long believed that this new wave of AI will have its greatest impact actually in enterprise products, and Glean is a great example of that. That's why I'm thrilled to be speaking today with Arvind Jain, the CEO and co founder of Glean. Glean is a search service and assistant for enterprises that allows workers to ask questions and search across the company's entire knowledge base. You could say it's like Google for enterprises, but that might be oversimplifying it. It helps retrieve and synthesize information within a company while respecting a number of security protocols and other factors that are extremely important within an enterprise. Arvind founded Glean in 2019 with a deep background in search, having joined Google as an engineer when it was still a startup. At Google, he innovated on everything from web search to Google Maps to YouTube and more, eventually being elevated to Google's rare distinguished engineer title. In 2014, he left to co found Rubik, a cybersecurity company, before ultimately coming to grips with the problem that led him to found Glean. There's a lot of interesting insights in this episode, like why he Built Glean for massive scalability right from the start. How? Gleam looks at explicit and implicit signals to gauge its success. Arvind's approach for balancing scalability with customization, which most enterprise startups struggle with, and his thoughts about entrepreneurship and competition in emerging fields. Let's get into it. Before we go to Glean, I'm curious. When you look back at your journey, what was your drive? What was your motivation? And in some way, how did it turn out differently, your journey, than what you actually expected at the beginning?
- [03:04]
Tomer Cohen
I feel like that I've been really, really fortunate and have achieved more success than I ever dreamt of. It's actually interesting. Like, you know, when I started my career, I had this, you know, big desire to be an entrepreneur. There's something about, like, you know, just my upbringing where I grew up, and there was this, like, deep respect and fascination for people who set out on their own way. So I wanted to be an entrepreneur, but actually never became one. And I think, like, over time, that desire for entrepreneurship sort of actually, you know, went away to some extent, and it got replaced by a desire to actually build great products with great colleagues and make an impact on the world. This was something that changed for me when I was at Google because it really gave me that opportunity to actually build something that then every friend of yours, everybody who, you know, your family, everybody uses these products. So that became a big thing for me, like, you know, build great products, make an impact to the world. Google gave me that opportunity. And then ironically, when I was not really thinking about entrepreneurship is, you know, when my entrepreneurship journey started, you know, very. It's interesting, like, you know, where life takes you.
- [04:06]
Arvind Jain
And when you think about the Glean backstory right now, like, one of the reasons I enjoy working with entrepreneurs so much is that they bring this profound understanding of an unmet need.
- [04:17]
Tomer Cohen
Yeah.
- [04:18]
Arvind Jain
Like, when you talk with entrepreneurs about what they're building, usually there's something very specific that they feel they know really intimately. They can describe every aspect of it. And you shared once that I'm going to quote this. I always thought that people became entrepreneurs when they encountered a problem that nagged them and that nobody else wanted to solve or knew how to solve but them. And I'm curious, when you think about the insight for Glean, it came for you when you build Rubrik, but what was the insight behind it so we could understand it really, really well.
- [04:47]
Tomer Cohen
Yeah. So before Glean, I was working on this startup, Rubrik, Rubrik, as a company, we grew very rapidly in about four to five years, we were more than 1500 people in the company. As the company grew, you know, we saw that we're not keeping up when it comes to productivity. In fact, you know, you'll always see that when companies grow that things become more complex. You know, it takes more time to.
- [05:09]
Arvind Jain
Do things, which is a common axiom, right? Like diminishing returns.
- [05:13]
Tomer Cohen
In a way, that's right. But I think it was stark in our case. Like we had actually tripled the size of our engineering team, but our commit charts were flat. And so, like, sure, you know, I can expect 20%, 30% reduction in productivity, but it almost felt like there was a ceiling and we just couldn't get more work done after some time. So there was a big drop in productivity across the board. Not just developers, but like sales. And we used to run this Pulse survey. And one of the questions in that survey was that, hey, do you have the information that you need to do your work? Do you have the help that you need from people inside the company to do your work? And we would score very, very low on that question. That was one of the lowest scoring questions for us. People were complaining loud and clear that I cannot find anything in this company. I don't know where to go and look for things and I don't know who to go and ask for help. You know, we didn't have any notion of an employee directory which described who works on what. Like, you know, like as a startup, like, you know, things just sort of come together. You know, there's a time when everybody sort of knows everyone and they know who works on what. But then like, you know, as you grow, like you suddenly lose that and you haven't built any systems to make it easy for people to understand those things. So we went through that journey and, you know, that was a pain point that I myself had. Like, you know, whenever I was looking for something, I could never find it. Because, you know, at Rubrik, we were using about 300 different cloud based SaaS systems. All of our company's knowledge and data was really spread across all those systems. So very hard to sort of find things. So I saw that it's not just my problem, it's like everybody in the company is facing it. So I said, okay, let's go and solve it. Like, you know, this is not hard. You know, we have knowledge across many different systems. Let's just go and buy a search engine that can actually sit on top of all of that knowledge and help people find things. And when we actually tried to go and Buy a product. We realized that there's nothing to buy. There's no product that would actually connect with all of those systems that we had and, and actually make things searchable within them. I was surprised. Like, this is not a problem that's unique to us. I actually talked to some of my friends who were running companies, and everybody who I would go and talk to would actually tell me the same thing, that, hey, look, this is a big problem for us too. Like if you solve the problem and then come and tell us how you solved it. But nobody actually had answers for me. So that was sort of the journey that I went through, like trying to solve this problem. I recognize that this is big. Every single person in the world has this problem, and yet there are no products to buy. And that got me excited. Like, you know, I do have background in that, the search engineer, you know, I felt I could actually go and build, build a good product in this domain and that's what got us started to build Lean. Yeah.
- [07:33]
Arvind Jain
So I think in many ways the idea of knowledge searching inside of a company is a big pain point for many. It's a constant complaint. I wonder, what was the pro survey average across the industry? I'm sure it was pretty low also, but not many actually decided to go after it and try to solve it. And for you, it was a cause and effect with engineering productivity in many ways. I'm curious, did you ask yourself, why would a Google or a Microsoft not solve it? Coming from Google, working on search again, search, enterprise search web is very different. But when you looked at those two giants that basically have a lot of big footprint within enterprises, did you have that thought process about they cannot solve it, or actually maybe they tried, but they're trying to build something different.
- [08:19]
Tomer Cohen
These companies, they can of course go and solve this problem in some ways. The way I think about it is that they have basically pretty much more of everything than you. They're more engineers, they have great people, they have resources, they have the brand. It's not like whether they can build it or not. It's a question of whether they will because they also have a few other thousand things that they need to focus on. And at Google, like, you know, I was there for a long time and solving search for the enterprise was not, I think maybe, you know, they felt there was not a big enough opportunity or business for them. Google actually had a product, but it never worked well because we just didn't put enough, you know, R and D attention to it. But it's an interesting question, like you know, my learning now, like, you know, after all these years in the industry, like, I've come to this conclusion that if you see a problem that is unsolved right now, then you can assume that nobody else is going to solve it and that you actually have the right to go and solve it and achieve success with it. It's just so hard to build products. It's not competition that is actually ever going to be the reason why you won't succeed.
- [09:26]
Arvind Jain
Yeah. I think you just described the entrepreneurship, leap of faith kind of thing.
- [09:30]
Tomer Cohen
Yeah. And there is enough opportunity. Think about this problem of search. We're building a product that every person in every company in the world is going to benefit from. It's not the case that there's going to be one company that's going to actually serve the entire world with it. Like, you know, different people are going to have different types of needs, so you have a big space you can actually go in, even if, you know other people are going to come and build some products. There's also the law of large numbers. When you actually solve a new problem, you know, even if there are, you know, five other companies that are actually trying to solve the same problem, there's a very low chance that you'll actually overlap at a particular customer. Right. So I sort of have this firm belief. I don't think competition matters. What's more difficult is that can you actually go and build a good product?
- [10:14]
Arvind Jain
In many ways, I think this was almost like a destiny for you because we've had knowledge search products inside of our company. We tried them. They just were awful. And I think in many ways they were trying to do a lot more. They went back to the same problem set that you went from. And instead of trying to solve that very focused in a very simple way, like Lin is doing with a search bar. And literally, it's like, it's an experience we all learned to use. We've been taught how to use search bars for such a long time with basic information and actually just finding the artifact I need to find. They've built this kind of repositories and collaboration tools, which is fine once you solve the core problem, but you haven't solved the core problem yet as a product. So I think what in many ways was. I don't know if it feels like a destiny for you to be in that position, was then I know how I can solve that core pain point, and then from there I can grow. But that core problem has to be solved for us before I build some kind of complex SaaS tool on top of it.
- [11:14]
Tomer Cohen
That's right.
- [11:15]
Arvind Jain
When I was asking people about Lean, one of the things that was mentioned to me was it's a rare company in the sense that it's a company that can actually scale with some of the largest enterprise customers in the world as a startup. And that was pretty unique and actually highly resonates with me because usually when startups pitch selling into LinkedIn, the biggest problem we have, even if I like the product, it doesn't scale with what we need, it doesn't scale to our solutions. And I was curious what some of the key product engineering or engineering principles you made early on to ensure the scalability because that sounds like a pretty big part of the success of the company.
- [11:51]
Tomer Cohen
First, I would clarify that in this company I've been less of a technologist because my role has been the CEO. So it's our team that actually does that great work. And, and so first some of these things have actually become easier over time. You get a lot of great infrastructure today in these cloud environments that actually allow you to build scalable systems in a much more like easier fashion. Like the level of infrastructure that you start building on top of is actually taking care of a whole bunch of things for you from a fundamental platform perspective. So the design choices for us, so first when we started out like, you know, we knew that this is a pain point that large enterprises are going to have even more than mid sized companies. So we build with that assumption that our customer is going to be these world's largest companies. So any system that we build, make sure that you are keeping that scale requirements in mind, you know, like in search, most of us actually came from Google. Building scalable system is sort of like, you know, in the DNA because at Google you don't get that choice. Any product that you're going to launch is going to be launched to like you know, a billion plus people. And so scalability, in fact I would say that you know, our engineering team may over index on that. They may build a system that is even more scalable scalable than what you'll have the need for in the next one or two years.
- [13:03]
Arvind Jain
And you were not worried that like that kind of emphasis on scalability will take away from seeing if this is actually a valuable product?
- [13:09]
Tomer Cohen
First no, there was a focus on scalability, but I think it's sort of inherent. Like I think when you build search systems you just build it in a way where you know that yes, I'm going to build it in a distributed fashion. To support larger workload, just like increase the degree of parallelism. So I think it's okay. Like I think I would say like these days because of all the great building blocks in the cloud technology systems, the experience and making the right choices, you can actually build very scalable systems from the get go and from a search system you do have to design. So there's a very simple sort of input metric which is how many documents should the system be able to handle? When we started out, we said that, okay, look, build a system that should be able to handle 100 million documents. And that 100 million was actually good enough for us to actually cover 90% of the market. And so we started with that as the goal that actually allowed us to make the right choices in terms of the design of the system, our search index and other things. And then one day we actually get a client which has 250 million documents. And that's new. And so most of the things actually still continue to work because they were built with the right design in mind. But some things start to break apart. Like one of the things, for example, I'll tell you which broke apart was within our system we have this concept of identities and group expansion. If you imagine like in any company you have notion of, you know, users and then groups. Groups are like a collection of people who for example, may have permissions to certain set of documents. So typically like, you know, you'd imagine that a company will have a thousand groups, like maybe 5,000 groups at max. But then we ran into a customer, you know, they had almost like a million different groups inside the company. And that sort of broke the architecture because, you know, we just fundamentally didn't conceive like, you know, why would you have more groups in the company than the number of people. And so that sort of like, you know, then puts us back on the drawing board and like sometimes we have to then go and re engineer. So it's a collection of both, like making some good choices from the get go. But then also as you get more and more larger customers, they sort of force you to make the system scale like even more, fix some of those things that start to become bottlenecks.
- [15:13]
Arvind Jain
That's a great insight. You know, if we go back to the. I don't know if this is very early, but still early days. I think you said once that the market was not necessarily ready for glean, so you kind of, you wanted to offer it for free at first. It's a fun story about how you use LinkedIn to do cold outreaches. You called yourself SDR number one, self development rep number one. And as somebody who is naturally a technologist, I wonder, what was that biggest learning for you for that early validation? Was this about craft? Was this about really understanding the problem so well before you build something, Was this about making sure that before you charge, you actually build trust with customers? What was your motivation for that and what was your biggest learning from that journey?
- [15:56]
Tomer Cohen
So first, you're right that building an enterprise search company was something that nobody was excited about. You know, even when I went out to actually raise funds, there were people, like, who were willing to invest in me because I've been an entrepreneur before and I'd shown some proof that I built some products in the past. But that category itself was not exciting to people, partly because it was a product that people felt was optional. Like, that you can live without it. Of course, you're living without it already, so that's true that you can live without it. But you know, that life is not great. In my mind.
- [16:28]
Arvind Jain
There's no existing budget for it, for example.
- [16:30]
Tomer Cohen
Yeah, there's no existing budget for it. But I think for me, what kept me on this path, despite a lot of indication, like, you know, a lot of sort of guidance from the market that we need to do something different, was fundamentally, it came back to my own personal pain point. And the pain point that I knew everybody who I know has, which is that people do find it hard to find information at work, and I'm going to add value to them, and I don't have a doubt, you know, any doubt about it. So we sort of continued on on that journey. We had to go through that period of, you know, where to actually do a lot of convincing. People would always ask us that, hey, like, even if I buy this, how am I going to tell whether, you know, this was useful to me or how much productivity gains I'm going to getting? Like, what's the ROI on this? And I have no answers to any one of those questions. So when you don't have answers to those questions, you will tell them that, hey, look, just try it out for free and see if it actually helps you. And so that's the path that we had to take. We felt that we had to go and create that market, create that opportunity, and so get people to try your product out first. I think if you have a good product, if it's also a real need, then ultimately they will come and pay for it.
- [17:42]
Arvind Jain
It's a great story about leading with belief. You wanted to solve it because you knew the problem so well, market or customers might have doubted. So in many ways you're like, hey, try it out first and then see it. What was you said? Like, they didn't know how to measure the productivity gains, ROI gains. Now that you're kind of past that stage. And what is the kind of success criteria that you look at, unlike in Google, successful searches. I'm sure it was a successful search session. You could look at bounce rate retention, but like, what is it that you look at right now for something that started stuff a bit fuzzy because there was no category for it.
- [18:18]
Tomer Cohen
So from a product success point of view, we look at all these metrics that you mentioned. Like, we want to make sure that the product is actually working well. And when people come and ask questions, that we are actually providing the right answers back to them. So that's the number one thing we have to make sure that it solves the need for our people. For me, that has always been the most important metric. More important than like, how many users within a company are using the product. Because the mindset has to be that even if it's, you know, to a small set of people, make sure that you're actually being useful to them. So that's how we actually think about it. For users who are, you know, exposed to the platform, who have seen it once, like, make sure that they are successful, they always find answers to their questions that our session satisfaction scores are high in those customers.
- [19:03]
Arvind Jain
This is qualitative. Like, you do surveys or it's both.
- [19:08]
Tomer Cohen
Well, there are three things. You know, typically we don't do surveys. Like our customers will do survey. Okay, that's how they determine, like, you know, whether this is a product that they want to keep in their enterprise or not. We look at both explicit and implicit signals that people actually give us just by using the product. As an example for search, you come and ask a question. After that, if you actually spend some good amount of time on a document and then you don't do another search very quickly and refine your searches, that's a good indication that the user actually found something useful. As opposed to, like, you know, if you did a search, you look at some results, you click on some documents, you come back and you actually change your search to something else. That sort of tells you that, like, look, you know, you failed in the first one, maybe you'll succeed in the second one. So you can actually collect these implicit metrics on user behavior that tells you how well you're doing. And then we use that of Course, to go look at bad queries, look at cases where we didn't do a good job for people and then improve our systems and then hope those metrics move up over time.
- [20:03]
Arvind Jain
And the ultimate goal is productivity gain. So for folks trying to understand, how do I learn from Arvind how to tie this all the way back? So when I talk to the customer, I'm like, hey, look, this quarter I bring in more builders to the company, but I'm necessarily seeing more productivity. And I was able to connect dots from a poll server that they have really hard time accessing knowledge. It doesn't matter if I have bring more people, but they can collaborate, they can work. Are you able to connect that all the way through or is this kind of. When you talk to the customer, for us, internally, qualitatively, people are saying, I love Glynn. Like I just use it much better. It works across. Those are all kind of hallway conversations in many ways. Are you able to tie that all the way back to show like a percentage gain or that's a little bit coming from the people themselves.
- [20:49]
Tomer Cohen
It's a very interesting question. Like there is that challenge that we still have. But if you think about it, there are a lot of productivity software where it's very hard to actually measure value, but you just know simply that you need them. For example, email, it's very hard to figure out what's the monetary value of email.
- [21:09]
Arvind Jain
Just try to take it away.
- [21:11]
Tomer Cohen
Yeah, well, it just won't work. Yeah. And similarly, if you have a video conferencing system like Zoom or Teams, these are fundamental tools that we need today. My personal belief is that having a really good search and question answering service inside your company over your company knowledge is so fundamental. Many of our customers actually are of that mindset where they feel like, hey, this is so fundamental, I'm going to bring it in. I know my company needs it and I don't need to go and measure its roi. So we have customers who are like that, but then we have customers who want to actually see. I want to actually make sure that the system is actually working well. I want to see some qualitative metrics or quantitative metrics. And so they will do surveys. I don't know why it is so consistent, but typically people will say that like, you know, Glean saves them three to four hours of time every week. Now I can do the ROI math using that. I know how much each hour is worth. I can sort of come back and do a roi, you know, analysis for Glean and see if it is actually a technology that's worthwhile but still fuzzy. It's still fuzzy because, like, okay, so what if you save time? Did it actually result in, like, more work or did employees just spend less time at work? So people have all these kind of questions. So that's also not enough. But luckily, once you start to look into more specific functional use cases or departments, then you have very concrete business metrics that you sort of already have in place. And you can see movement on those metrics after the introduction of Glean.
- [22:42]
Arvind Jain
What's an example? Arvind.
- [22:43]
Tomer Cohen
So we worked with this really large telecom company and they've actually put Glean in front of 60,000 customer care agents that they have. After they did that, they saw a 42% reduction in case resolution time. So it's actually the number of how fast you resolve a case and then as a result, how many cases an agent can now resolve in a day. You know, they saw this huge improvement and like, they can actually directly tie it to the roi. They use that data to figure out they're driving tens of millions of dollars in cost savings because their agents can actually resolve more cases on a daily basis. So once you sort of go functional, then you will see that there are existing business metrics that actually clean. Helps you make a big movement on.
- [23:29]
Arvind Jain
There's a great learning here. So some customers will believe, because they believe that the nature of work should be done a certain way.
- [23:35]
Tomer Cohen
Yeah.
- [23:36]
Arvind Jain
And probably they felt the pain points. It just works for them. Some will probably push on surveys or like, measure time. And for some, it's kind of functionally focusing on, like, very specific use cases that obviously the idea of, like, retrieval information is key.
- [23:52]
Tomer Cohen
Yeah.
- [23:53]
Arvind Jain
And then you can measure that, like, really, really well. That's fantastic. We're going to take a quick break, but don't go anywhere. When we come back, Arvind is going to share his thoughts about balancing scale with customization.
- [24:04]
Tomer Cohen
Every customer is going to take you in different direction, and it's very hard to actually say no to them because you need that revenue.
- [24:16]
Arvind Jain
Race the rudders, Race the sails. Race the sails. Captain, an unidentified ship is approaching. Over. Roger, wait. Is that an enterprise sales solution? Reach sales professionals, not professional sales. With LinkedIn ads, you can target the right people by industry, job title, and more. We'll even give you a $100 credit on your next campaign. Get started today@LinkedIn.com marketer terms and conditions apply. Welcome back. We're chatting with Arvind Jain, the CEO and founder of Glean. You know, we talked a lot about product quality and setting a high bar, something that you believe in. And enterprise size, sometimes it's filled with over promises and it sounds like very counter to how you build. I think you said in the past you build with trust and you build from there. You came from the consumer side in Google. You scaled like you build for web and YouTube and maps and now you shifted to enterprise grade. What do you see as the principles for enterprise grade? You mentioned? Scalability, which is really important. Trust, which is really important. Anything that comes to mind to you when you think about enterprise grade?
- [25:23]
Tomer Cohen
One of the really big things when you start building a product for an enterprise is first of all, you have more than just end users who are going to be using a product. You have a champion, you have a buyer that actually goes and buys a product. And there are a lot of additional considerations that you have to actually solve for. One of the things for us in Glean is we build a great product. But then you still have to actually answer the security team at an enterprise why they should feel comfortable about Glean and why should they actually let Glean have access to all of their sensitive internal.
- [26:01]
Arvind Jain
That was our number one question. Because all the documents were open before, so people were freaking out that they'll be able to reset.
- [26:07]
Tomer Cohen
That's right. So that's both like in terms of how will you make sure that you don't leak information internally, but how do you also make sure that you'll keep my data safe? So I think when you build enterprise software, it's sort of both good and bad. Like, you know, the good of building an enterprise software is that you always have relationships. Like, you actually get to work with people who you can spend time with. They can actually share their requirements in a very articulate fashion back to you and then you can actually go and meet all those requirements. But of course they have more requirements. So you do like sometimes use like, you know, 50% of your work is to actually harden your product, you know, to satisfy the enterprise requirement. And you know you're only getting to do another 50% of work to actually build that the actual value that you're trying to build for the end user. But at least you have a communication channel, you get to actually collaborate, you get to get clear indication of what's important to your customers through those channels.
- [27:00]
Arvind Jain
Have you found a happy path on the customization versus scalability? Because, you know, every enterprise customer wants things to be done in a certain way for them that is unique for them. So you're building almost like a feature set for them versus the desire to build something which is more horizontal that scales for everybody.
- [27:16]
Tomer Cohen
You have to be very, very careful about it. That's a great question actually, especially for folks who are early in their journey building enterprise companies right now is that every customer is going to take you in different direction and it's very hard to actually say no to them because you need that revenue. You need that revenue to fund your business and make progress. So say it requires deep discipline. You have to like, you know, listen to your customers. You have to actually incorporate their needs in your roadmap while also in parallel having your own version of where you want your product to go to. And every time you have a new customer, you have to share with them honestly what your roadmap is and what capabilities you actually can provide to them versus what you feel are like really the scope, you know, something that you can tell them that, look, these are the three requirements. Like you have these 10 requirements. For me, like those seven I've actually heard from many other customers and therefore that's important for us. And I'm actually putting it in our roadmap. I'm going to serve it for you. But those three I've not heard from anybody else. And so maybe we should go and have a little bit more discussion. Are those first of all, even the right requirements? And if they are, then can I do something where I can give you a platform where you can actually do a little bit of that work on your side? If you are going to build a scalable product company, it has to be one product. It has to be one release, one engineering team that actually maintains that. If you have 10 different permutations and it's going to become really hard to scale over time. And you can always have a separate services team that can work with your customers to build some of those customizations.
- [28:46]
Arvind Jain
The engineering team you brought in had scalability in their DNA. And enterprise requires this notion of modularity. There is ideal flexibility. In the end, do you think that comes all the way back to how you build the stack? Or it's more of a mindset you add?
- [29:00]
Tomer Cohen
In the end, it'll be wrong to say that you predict everything as an engineering team and you built a amazing modular system and you build amazing scalable system. It doesn't like, you know, it's not perfect like that. Right? You try to make the best choices, you know, always be ready to change, you know, as requirements change, you change your product, you know, update your systems. Ultimately, I always feel like we will succeed as long as we're agile. We have made like plenty of wrong decisions in the past, like some of the decisions that we now feel like were fundamentally wrong, but we have the mindset to go and fix them.
- [29:33]
Arvind Jain
Very helpful. All right, I want to shift quickly to AI. Glean was early with LLMs. Very early. In fact, I think almost from the beginning for the company. Were you already envisioning a response engine versus a search engine? Was that back to the vision of the company? It wasn't blue links that you had in mind?
- [29:51]
Tomer Cohen
This is a great question. Even in 2019, Google was not just the 10 blue links search product. Many questions when you go to Google, they would answer those questions for you. And so we had the same vision from day one that we'll build this product. People will come and ask questions, we'll surface the links to the right resources, but whenever we can, we will actually try to answer the questions. And language models were actually sort of already in the market, not like today where everybody talks about large language models and it's so pervasive. At that time, I think they were very restricted and people in search industry knew about them a little bit because these language models initially were developed in Google to make Google search better. So we knew about them. So I think we probably implemented the first version of vector search in the enterprise, the first version of custom embeddings on enterprise content. So we did some of these things before anybody else. But the idea was always to sort of use the language models to understand content so that we can surface the right results back to the user so we can do good high quality semantic search. And the goal was also to extract answers. So initially when we started, we would actually go and look at like documents. We'll see like what kind of questions it answers and we would extract them so that when people come in and ask questions, we could actually show that extracted answer like whenever we could. That was the extent of our imagination at that time. We didn't actually, you know, think that the models will get so much better that they will make their own sentences and statements. I didn't have that foresight. Maybe the researchers who are building these models had. But I feel like everybody was surprised with how fast these emergent capabilities sort of advanced over time. So when we saw that happening, when we saw that the model can actually summarize or take three different documents and actually synthesize an answer from information that's living in three different places, then it was actually very natural for us to incorporate that capability into our product because we're already trying to answer people's questions whenever we could.
- [31:46]
Arvind Jain
It was a tailwind for you. You were already ready for that.
- [31:48]
Tomer Cohen
Exactly.
- [31:49]
Arvind Jain
That's amazing. You know, in many ways, like I think about this LLM revolution, it feels like it's an enterprise first revolution. Ver mobile, which was more a consumer first revolution, really didn't touch the enterprise as much. But LLMs feels like very much like really centered around enterprise given the complexity, given the need to bring artifacts together, given the productivity gains. So in many ways it feels like it was an amazing stars aligning moment for glean.
- [32:13]
Tomer Cohen
Absolutely. We give ourselves a little bit credit for trying to solve a problem that nobody else wanted to solve and actually deploy language models early in this technology. But I think the timing for the company has been really fantastic. Like, you know, we are very lucky that we built all this, you know, core technology which is like search and retrieval over all of your enterprise knowledge in a safe and secure way. And now that has become a fundamental component of any AI application that you're going to be building inside your company. So definitely, like, you know, timing has been great for us.
- [32:44]
Arvind Jain
And I mean, given that you've been very ahead of the thinking when it comes to enterprise in this era of AI, I wonder what do you see as the biggest misconception around RAG around retrieval augmentation generation technology today? Before we go any further, I want to take a moment here. For the listeners who are unfamiliar with rag, which is retrieval augmentation generation. It's a very important technique used today to enhance the performance of LLMs. It improves the accuracy and relevance of the response by grounding it with specific information versus just relying on the model's own training data. Let me give you a quick example. Imagine you're using a standard LLM to ask about the latest scientific research on climate change. If the LLM is not enhanced with rag, the response will be generic and it will not include the latest research findings on information. If the LLM is enhanced with rag, the model first retrieves the most recent and relevant documents about climate change. It will then use this information to ground itself and then it will generate a more accurate and up to date response. Anyway, back to the interview. Back to rag. It's very much like a hot topic right now. Everybody's trying to talk about it in the way they use it, but you're actually building it and it's a deployed product. You actually do really, really well. And you were early to that. So I'm curious, what do you see as the Misconceptions out there in the.
- [34:05]
Tomer Cohen
Market, you often see people talk about hallucinations. I think the misconception that people have is that these hallucinations are because the models are random. But we feel like the Rack architecture itself is actually limited in some ways. Because a lot of times the mistakes that happen inside an enterprise is because your retrieval system didn't do a good job even picking the right information that you could make the model work on. And typically most of the errors that we see, not in our product, but in general, these poor experiences, oftentimes they are a result of giving bad input to the models as opposed to the models hallucinating. That's one big problem that we've seen with the RAG architecture. Like you have to put a lot of investment in the retrieval part of that layer. Folks these days believe that building an AI application is easy. Like I take content, I dump it into a vector database and then given a question, I get something from that vector database and dump it to a model and everything is going to be done. I think folks are discovering like AI applications can be magical, but they're actually very, very hard to build. Like you have to actually put in a lot of investment into building these Rack style applications.
- [35:20]
Arvind Jain
I very much agree. When you think about the nature of work, Glean maybe started as a knowledge response, knowledge search, but your ambition is productivity and you have a very high bar for what the product looks like for that. When you look three, five years out, what other problems are you expecting to solve with this? What benefits do you see kind of coming into the flow of the nature of work? That will basically be almost like a before and after moment for us.
- [35:45]
Tomer Cohen
So first, I fundamentally believe that AI technology is incredible. It has capabilities that as software engineers, oftentimes we can't even fathom the kind of things that can do. It's very new, it's actually a game changer. But it's also very difficult to actually put it to use. Like people actually found it very hard. Like if you look at like enterprises today, most of them are actually struggling to get real value from it. With all that said, we believe that, you know, the world is going to change very quickly. In fact, in five years from now, a lot of work that we do today, that we're okay doing today, we won't be doing anymore, is going to be done by AI, by AI assistants and companions. We are going to see it. The question is like, how are you going to get there as a company? Glean is going to actually stay focused on just that one mission, which is that how can I actually build that truly amazing personal assistant to every worker in every company in the world that can actually do majority of their work for them? And there's a lot of work that needs to happen on that front. So from a product perspective, we're not trying to broaden our horizons too much. And then the second thing, just like how every employee will have amazing help in form of these AI assistants and companions, the company itself, there's going to be these really powerful enterprise AI platforms that build on top of these foundation models built by other companies that companies will be relying on to bring AI into each one of their business processes. So we are looking at a very massive transformation that's going to be happening over the next five years and it's going to create a lot of opportunities for lots of new startups, lots of new enterprises, and that's the most exciting part.
- [37:36]
Arvind Jain
Yeah, I can't wait. You know, we are now in the early innings of that productivity slope and what you're describing. In fact, it's really hard to fathom because when you play five, six, seven years out, just the exponential curve of development and the ability coming into the flow should just change naturally the way you work in a phenomenal way, in a very positive way. So when you look at companies that inspire, glean who comes to mind for you.
- [38:01]
Tomer Cohen
So definitely Google and now OpenAI. These are amazing companies and I love them because of the unconstrained ambition that these companies have.
- [38:13]
Arvind Jain
I like the unconstrained vision aspect to it. And given your expertise with search over the years, what's one thing you wish search could do for you that it's not currently possible?
- [38:25]
Tomer Cohen
Actually, quite a bit. Like, you know, I think a lot of questions today are like, search is actually very transactional today, which is that you can ask a simple question and it can actually look over some information and answer those questions back for you. But like, most of my questions are often more complicated. Like, you know, it requires like, you know, some level of orchestration and, you know, breaking my problem down into multiple different steps. For example, a regular task that I have every day is tell me what my team did last week. And I wish the search or the assistant product lane could actually answer that. It's a simple question, it's only five words. But to actually go and solve that, you know, it requires a different paradigm where you have to sort of break down the problem and then search for multiple pieces of information and then put it all together. So that's one question that like, you know, I wish search could solve that. It doesn't do today.
- [39:12]
Arvind Jain
Yeah, this highly resonates. We taught ourselves because of Google to talk in keywords when we talk to machines. And even with AI today and LLMs, the best practice right now is still give it one specific task and do not get it confused with the prompt. Right. Make sure it's indexing on one specific thing. So I love the idea of the question behind the question is much broader than what I'm actually asking right now.
- [39:38]
Tomer Cohen
That's right.
- [39:39]
Arvind Jain
Curious also, what's a product that you did not think would work but actually worked in the end?
- [39:45]
Tomer Cohen
Something that I, that I worked on.
- [39:47]
Arvind Jain
Myself or could be somebody else's. Could be consumer. Could be.
- [39:51]
Tomer Cohen
You know, before you showed me ChatGPT, I would have said that that's a product that cannot work. There's no way that machines can do that thing that they're doing today. So that's the most recent example. It was just something that I, I fundamentally felt could not be done that that product did. I think AI is showing those kind of capabilities. Like even now when you see the video models and the kind of imagery they can create, I mean these are something that I guess it's hard for technologies like we've built technology for so long and when we know how it works and then we see something that nothing that we ever built could have done that. That's just amazing thing to see.
- [40:32]
Arvind Jain
Yeah. The first moment I saw GPT4 I thought this was one of those pre canned demos where you can the whole thing.
- [40:41]
Tomer Cohen
Exactly.
- [40:41]
Arvind Jain
Took me a while to realize no, no, this is real. Thank you Arvin for joining me. There are so many great takeaways and I'm excited to get into a few of them. First, one of the reasons I love entrepreneurs is that they lead with belief. They already know their idea lacks proven evidence. They already know that large incumbents can pose a massive risk. But their profound understanding of the pain point is what gives them a unique edge. As Arvind shares, he realized that nobody else is going to solve or even understand the pain point that he so deeply internalized already. Despite many doubters, he trusted his gut and expertise building search products in order to force his belief into a reality. Second, whenever you hear about a new venture, there's the inevitable question of when and how it will scale. Now, conventional wisdom holds that it's more appropriate to build a smaller product to start with and then figure out scaling once you've proven the main value. Prop Gleam's situation is very different from the get go, Arvind knew his customers would not just be any enterprises, but the world's largest companies. Therefore, he built the product with scale in mind from the beginning, which is very unique. Glean's engineers were hired with that mindset, so much so that the engineering team might actually overindex on scaling. But that's an intelligent bet for a company whose main value prop is to reason over massive sets of internal data within large companies. Next, when creating a new product, especially software as a service, you need to think about what your success metrics would be. Sure, just like any company, Glean gets product metrics like successful searches that result in dwell time or unsuccessful searches that result in short bounce rates. But that's not enough for Glean. There was no demand for Arvin's product and he had to create it to do so. Arvin not only showed quite a bit of data for employees that indicated how valuable their product was, but also he showed time saved so he could prove to a CFO or a CIO the productivity gains. Arvind also shares a case study of a very narrow field of customer service and how it could show material gains when they use Glean. Lastly, think about balancing the customization and scalability of your product. Especially in enterprise products, it's important to listen intently to your customers, but you also need to know how to hold the line on your own product roadmap, especially when the ability to scale is so key to your product's success. Otherwise, you'll just get pulled in so many directions. As we covered in a Zoom episode, their cpo, Smith Hashim, listens intently to customer requests and actually tries to fulfill them all. But this is a tricky balance to achieve. If you don't do what your customers ask you to do, you might lose those customers. But if you do exactly everything they ask you to do, you'll fail for sure. Now back to Arvind's initial insight. What's a pain point that you see so deeply but nobody else gets? Are you passionate about building it? Let me know in the comments on LinkedIn. I'm Tomer Coyne. Thank you for listening. I learned a lot from this conversation and I hope you did as well.
- [43:46]
C
We'll be back in two weeks with Will Ahmed, the founder and CEO of Woop. Building one is a production of LinkedIn news. Our host is Tomer Cohen, LinkedIn's chief product officer. This episode was produced by Max Miller. Our associate producer is Rachel Karp. We're engineered and mixed by Asaf Gadraun, and we get additional production support from Alicia Mann at LinkedIn News. Sarah Storm is senior producer and Enrique Montalvo is our executive producer. Dave Pond is head of productions and creative operations. Maya Pope Chappelle is director of content and audience development. Courtney Koop is head of original programming. Dan Roth is the editor in chief of LinkedIn. If you know a product leader we can all learn from, send us a line@pitchesinkedin.com.