Why founders, not product teams
Anastasiya: Hello, Emrecan. I'm so pleased to have you today. Thanks for coming.
Emrecan: Thanks a lot, Anna. It's great to be here. Thanks for hosting me.
Anastasiya: I wanted to boast to my colleague in San Francisco and told him that I will be talking to the product lead of Glean. Have you heard about them? And he said, "Yes, of course, I've heard about them. Everyone wants to be Glean." So everyone knows about your success. And maybe the thing I wanted to start with is this: you contributed to raising the valuation of the company from 2.2 billion to 7 billion in one year. That's just amazing. And in the article you mentioned that success is a product of reiteration, change and reflection of founders — on the part of founders. So I wanted to unpack this a little bit. Why founders, not the product team?
Emrecan: First of all, thanks a lot for digging into that article. I didn't know anybody read that at this time and age, but that makes me feel quite special about my background.
So first and foremost, I'm a founder. I think that's why I anchor a lot on entrepreneurship and on being a founder. A huge reason I am at Glean is because it is still founder-led. I will be very clear about something — not necessarily a positive thing — but the longest I have worked for somebody else in this life is less than four years, and that was LinkedIn, and that was only because I sold my previous company to LinkedIn.
I was building my new company when I realized, thanks to a former VC investor of mine, that a company called Glean existed, and apparently I was building something that Glean could compete with me on. Actually, I didn't know about Glean at the time, but when I realized a company called Glean existed, I got really scared by these folks. They built a formidable company. And I told myself: my first startup, I ran it for six long years before I sold it to LinkedIn. I don't know if I want to compete with Glean for the next 10 years of my life. So I joined.
But going back to your question — totally. I think that would apply to product teams across the board. But I think that applies in an outsized way for founders, or founding PMs, or early members of the product team in a private company, where you are competing against behemoths, against the incumbents, and you've got to take some risks. You've got to make some asymmetrical decisions, where when you are the incumbent, when you are the leader, you actually don't make those decisions necessarily. So my thinking around constant reiteration — not giving up, not backing down, not taking failure as given, or not getting discouraged by it — is very much driven by the need for a PM or a designer working in a small-scale company, fighting against the incumbents or trying to scale the company to its full potential.
The contrarian bets Glean was founded on
Anastasiya: What do you think is the secret sauce of Glean's success? Why does everyone want to become Glean?
Emrecan: Well, I am hoping that secret sauce keeps changing, but I will at least share with you what is deeply rooted at Glean.
Glean made a number of contrarian, non-consensus bets. We are in this stage with Glean's vision being quite unchanged from its first day. Glean is almost a seven-year-old company, and we set out to enable employees to do their best work.
AI was of course some part of the enabler, like some part of our strategy, but I think it's important to distinguish that Glean is not built because we are having the AI moment, because we are finally experiencing the full capability of AI. Glean was founded because our founders, especially Arvind, had seen before Glean how otherwise very fast-growing organizations can still become trapped in silos, in communication and coordination challenges. And while it grows the headcount, such organizations for some reason end up shipping slower, end up changing slower, iterating slower. So he set out to solve that problem.
So I think first and foremost Glean committed to solving a set of jobs to be done for the world's leading growing organizations, rather than indexing to a particular technology or particular capability and creating value out of it.
So still today, one of our four core values is make it customer-driven. So when I think about what to build next, of course I love using the most recent AI capabilities. But as an organization we index the most on understanding what jobs our customers are trying to get done, and many of them are not solved as of today. So we keep a huge running list of them, and any time something changes within our R&D or in the broader market, there's an opportunity for us to say: is it now time to solve that previously unsolved problem for our customers?
Search across your SaaS stack, breaking down the SaaS silos, breaking down the data silos for thousands of employees in the same organization — these were the jobs to be done we got extremely interested about when nobody was interested in it over the last 10, 15, 20 years, when we saw the SaaS proliferation. So I think that is the contrarian perspective Glean was founded on: that search is valuable, that breaking down the information silos within large organizations is valuable. And we started from there.
Why CIOs believe the silo problem is unsolvable
Anastasiya: You solve a real, tangible problem that companies have, but based on studies only 25% of leaders actually want to find the solution and solve the problem. So although companies do have that problem, maybe they don't acknowledge it. How many companies actually even want to solve this problem? Because there is always some resistance — sometimes teams can hoard the information. So what's your take? First of all, how do you fight this resistance, and how many companies really want to break out of those silos?
Emrecan: Yeah, sure. So maybe I will give a little bit of a contrarian take on that number, at least on the 25%.
First, when I engage with our buyers — the CIO, CISO, or increasingly chief AI officers within our prospects and customers — the sentiment feels a lot higher than 25%. It does feel like everybody wants to solve that problem. But I'll be very clear: that problem is felt as an unsolvable problem by the CIOs. So maybe they actually don't want to admit that this is a problem I want to solve, because the moment they think about solving it they realize how big of a data mess they are in, and how many years — if not decades — it would take, in their mind, to clean up their data structure and their data. And only then do they believe they would have solved the silo problem, and then they are ready to adopt AI.
So maybe there is something there about not wanting to solve the problem, because the problem feels insurmountable in some way. But I definitely think every CIO, every chief AI officer right now wants to solve that problem. It might be different whether they believe it is solvable by their own means, in their own remaining lifetime in the company.
But once they start committing to "okay, I want to solve it in some way", then I can talk about some insights that cut across, that repeat across these organizations.
So, one. We talk about silos as if they are bad things, negative things, and I would actually agree with it. But think of why companies end up with silos. It's almost like silos are a feature of scale — they are not actually a bug. They happen to deal with this beautiful problem, because over the years they end up building a lasting company. They hired great people. They shipped great products and services. They ended up growing. But over this time, as they were growing, either call it incentives, fragmented tooling, specialization of individuals, teams, business units — they all harden into walls as they grow. And then that's what we call silos today.
Something that most folks don't realize is that communication challenges grow much faster than headcount. It's almost an exponential power of the headcount growth. But when you look at how teams organize, the teams optimize locally and then they end up drifting globally. So when CIOs or the leaders realize that they are encumbered by silos, that they are kind of like prisoners of silos, that's because it's a byproduct, it's a feature of their long-running scale. And they don't try to tackle communication and coordination challenges until it is very late.
And maybe the last point I'll make, Anna, is that over the last 15 to 20 years we have seen incredible SaaS businesses be built, and every SaaS product or startup that was built, that product was more vertically oriented than all the SaaS companies that came before. Because you wouldn't build a fully horizontal SaaS company if you are a startup founder coming into the space in 2020. So the way you create value is you focus on a much narrower user problem — like how do teams run tasks and projects — and you built a company like Linear, where you build an amazing product but it is only doing one type of job to be done well.
So what happens is these specialized products, best-of-breed products, they end up acting like natural silos too. They offer a great user experience, but in return the users start building information silos within that small SaaS ecosystem, and the rest of the organization cannot tap into tickets, chats, docs, any other system of artifacts in that tool. So it's, I think, a natural byproduct of the SaaS problem we experienced over the last 20 years too. Better product managers, better designers — they ended up contributing to the formation of silos in some ways.
Why Glean's adoption starts in the C-suite
Anastasiya: You also mentioned that you work with CIOs mostly to drive the adoption. Is that just a strategy for this type of product that is adopted by organizations, or is there another way? This is also related to organizational change, because this is about breaking those walls, making information more transparent. And I always bring this up because organizational transformations are really hard, and there are two ways — evolutionary or revolutionary, top-down or bottom-up. So as I understand it, is the strategy that you have mostly top-down, when you work with C-level people who push this change? Or are there cases when it's driven bottom-up, like from a frustrated team that wants to get more information, and they push this solution and it expands as an evolution?
Emrecan: Love the question, and I think it's a moving target as well. The capabilities and potential of AI is changing the mindsets and the behaviors quite a bit today.
But Glean historically has been a fan favorite product in the C-suite. And then there are a few reasons why.
One is that there is potentially incredible information flow about the biggest bottlenecks, the biggest challenges of the entire organization, where a specific team might not see it as the biggest bottleneck in how they operate day to day, but the C-suite might see that while the headcount is growing, their cumulative throughput — in terms of shipping products, or growing revenue, or bringing employees to a productive state — might actually be faltering behind. So in terms of just problem identification or discovery, there are certain things the CIO might have a better single pane of glass on, about the health of the organization, that anybody else might not be seeing. So that puts the C-suite in the driver's seat to look for solutions before anybody else.
The second aspect is that increasingly we are hearing about top-down mandates, where the board, or again the executive function, is putting some company-level goals for AI adoption, for changing the productivity — the headcount productivity — of the entire organization. So the goal the C-suite is on the hook for might be driving this CIO- or CISO-driven search for tools like Glean.
But what I care the most about, as we are talking about products here: Glean is a product for every single employee. It is not for software engineers. It is not for senior managers. It is not just for the interns who don't know how to code as well as maybe a seasoned programmer. It is for every function, every employee, no matter which office, which geography you sit in, no matter how tenured you are in the organization or not.
So for a wall-to-wall product like this, it is most welcoming or productive or efficient to have that buy-in at the C-suite, and bring the Glean magic across the organization in almost an overnight way.
And I'll mention the last bit. For Glean to show its magic — as we have discussed with silos a few minutes earlier — Glean needs to connect to your data silos, to your data corpus, and start making magic happen by correlating what happens in one IT system with what's happening in another. And that permission doesn't come from regular employees. Those permissions come from CIOs and CISOs and the IT admins. That is also why, when Glean deploys, the motion is very much at the top, because the connectors, the privileges, the authentication tokens need to be provided by the central IT organizations.
The AI maturity spectrum, from day-one queries to agent builders
Anastasiya: You also mentioned AI adoption, and I assume that enterprises have a really wide range — there's a learning curve, and there are people who are early adopters and definitely there are laggards. Do you have practical advice on how to drive adoption? Do you run trainings, some secret sauce for onboarding, to drive that adoption across the board — especially with people with different technical backgrounds? Because you mentioned it's not only about engineers, but also accountants, ops, maybe people who are not English speakers as well.
Emrecan: Yes, love the question. I think we have been doing that quite a bit in our life cycle, but it's also very much a moving target.
So you can't believe how wide the current spectrum is for customers on the AI maturity curve. There are some organizations who really love the fact that when Glean is deployed to the organization and turned on, the first query is: who is the expert on topic X, who is the lead on project Y. So just the notion of finding the right person to talk to, to have a meeting — that is a very visceral use case for somebody who is getting Glean access on day one.
Compare that to a deeper, more advanced cohort of a Glean customer, where not only are they well deployed for the last two years, but many of the employees switched from being pure consumers of AI and instead actually started building agents on Glean — building agents, iterating on them, then distributing these agents to their teammates, collecting feedback through insights tools, through productized evals, improving those agents. So this kind of organization looks very different from an AI maturity standpoint, and the trainings we need to do on how to create effective agents for the go-to-market organization are very different from Glean 101, to answer more simplistic information-seeking queries.
So as the product team, we've got to deal with a very wide spectrum of AI maturity or AI adoption. And of course we cannot scale this usage all through training and handholding means. So we aspire to build a consumer-like product where the product just explains itself, becomes contextual for the end user, and the end user has a very low-friction way of adopting the product and realizing that they can use the product day in, day out, every minute, every hour.
Anastasiya: Yeah. I just feel that in this case product and design might be very important, to make it consumer-like so that you can just understand what it does.
Stubborn on the vision, flexible on the details
Anastasiya: Another thing that I wanted to dive deep into as well, since this is enterprise industry — companies with a range or scale of needs. And I think that products that are built for enterprise have a risk of tailoring it to meet the needs of a specific customer, a big customer who has a very loud voice. And how do you learn to — do you have a framework to say no to some requests, because it will be over-skewing and derailing from the main course? I think that you mentioned it a little bit earlier before, but maybe we can dive a little deeper into your prioritization framework.
Emrecan: Love it. Look, this scenario, this area — I am still super fascinated by it. And this is what I feel is one of the most fortunate things about being a designer, a product builder, an engineer at Glean.
So at Glean we have this notion of being very stubborn on our vision, but we are extremely flexible on the details — so on how we get there. And our product development process is very much driven by our customers.
Our customers get their hands on the product on day one. Each one of the products looks the same. But then, just like you mentioned, every enterprise is kind of unique in how they run things idiosyncratically, and how their silos have occurred or shaped over time. So they end up running different types of queries, or they end up evaluating Glean's performance or outcomes on their team somewhat differently. So we have this amazing fire hose of feedback coming to us that I will say is very different from when I go to the public web and read sources about what the trends are. So I consider one of our competitive moats to be how close we are with our customers, and how our customers shape invention and prioritization in what we build.
Of course, like you mentioned, the larger the customer is, then the more bespoke or tailored the request could be. But then this is where the strategic importance of the product team comes in. Can the product team connect the dots between what customer A, B, C and D are saying about the solution they want? But can the product team go beyond the surface-level definition, get deep enough to the job to be done, to the pain point? Some approaches to this — I'm sure you covered this with your previous guests in the series — like the five Ws. In many of these cases our customers start by saying, "Okay, I want this solution." But how do you go from that to the job the end user is trying to get done in their work life?
Once you get there, there's a lot more opportunity to build a standardized product. But if you stay at the surface-level solution, then every request will feel like a bespoke solution.
So I am extremely proud that not only does the Glean product team have that ethos of going deeper, but also we leverage AI to the max to help us with that. So increasingly, across hundreds of customers, with our customer support tickets, conversations, real or video conferencing meetings — how do we distill the insights, the requests, the jobs to be done, and how do we connect the dots? It is increasingly a human and AI joint operation for our product team. And I'm sure we can get into that, but I do consider that as walking the talk, and running a pretty unique product organization that helps us build a standardized product and yet win with our customers with the features we prioritize.
If AI is not in the critical path, you are not AI native
Anastasiya: Let's then dive into what you do differently. As you mentioned, in the AI era everyone tries to use those tools to make work more effective, more productive — but what makes your product team stand out? You mentioned using AI to process meetings, to dive deeper into insights, but is there anything else that stands out?
Emrecan: I will never feel that we are doing enough in this area. So I'm going to share a few provocative thoughts, hopefully, and then we can maybe dive deeper into some of them. I'm quite excited about discussing them, because I don't have all the answers, and discussions like this help me broaden my perspective as well. So I'd love to tap into your wisdom on this one.
But I think I will open this one by saying the following. In any team — I represent product, data, design at Glean, but this applies to I think any team, R&D or non-R&D — if AI is not in the critical path, then you are not AI native. Which means when you are trying to do X, if AI sits in the critical path of doing that, then you can say, okay, I am operating as an AI-native company, individual, team. Otherwise, at best I think you are AI adjacent. You might choose to use AI, you might choose not to use AI. If you are getting things done that way, then at best you are AI adjacent.
But I am extremely excited about transforming my own team to be AI native, AI first, and helping our customers get there faster.
So as a corollary to it, I think many, many of us use AI as a feature today. But I think this is the time to see AI as the collaborator. It's almost like an intern, a new hire, your chief of staff in your team. You manage AI like it is one of your employees, your direct reports. It's not just one particular workflow, one particular UI affordance. It is actually a collaborator you get things done with.
So that also means if there's an outage, it's almost equivalent to AI not showing up to work that day. Maybe it's a sick day or a vacation day. But you know what I mean — that's what it means for AI to be on the critical path, for good or bad.
So what comes from it is: imagine how we worked with our teams as people managers. We give feedback, we look for ways to grow our teams, get them skills. But this whole notion of feedback is an incredible thing when you are working with AI. AI is infinitely hungry for feedback. All of a sudden you don't need to worry about the following thing: if I give this piece of feedback to Anna, the human employee, will she feel offended, stressed? Am I giving too much feedback? There is a reason we do performance reviews every six months, or every year, only because too much feedback can be too much for humans. But AI agents don't have that kind of feelings. They will not feel overwhelmed by the amount of feedback and evaluation.
So any worker today, they are the bottleneck to sharpen and improve the AI agents and tools they use for their work. I haven't gone to every single one of my AI agents today and told them how they can do even better work for myself, because I didn't have the time to do it.
One of my best AI agents is actually helping me prepare for my customer meetings in a very deep way. I'll be honest, for this meeting prep for our podcast, I used AI in a tremendous way, and I found ways it didn't do as good of a job. So hopefully tonight I'll have time to give some feedback to my AI agent, so that the next time you and I meet I will hopefully have even more provocative answers for you.
But that notion of how AI agents improve — it is really the function of the human manager responsible for it. And all of a sudden, as the humans, we become the bottleneck on how well or poorly the AI performs. I could keep going, but I will take a pause here to see if this stirs up any thoughts on your side.
Glean as an ever-present context engine
Anastasiya: Yeah, I think that it also means that everyone will have an AI agent who does the job. It creates a little bit of tension and requires tuning, creating this, customizing, giving feedback, adjusting, evaluating — but hopefully, if it works well, it can speed up our work. But I think for product managers, people who are responsible for strategy and decision-making, some parts of their work require a lot of context and are not repeatable as much. And that's a struggle that I face sometimes. I do have different cloud projects and agents, but not always do I have something repeatable, like preparing for meetings. That's usually customer research, user insight processing. There are some parts that are automated, but most of your time you're in meetings. And so far I've found tools like Granola, which are on the side and keep track of all conversations and distill insights from that. So if you constantly find yourself stuck and don't do a lot of work as an individual contributor, and most of your time is consumed by meetings and conversations, then it's like not everything could be automated. That's my take — maybe it will change. And I do think that strategic decisions will be the bottleneck. But I think AI will have a way to collect more context from different sources, because right now you need to manage the context — you just give it, "I know about this, this, this", and that's the context that you're giving it, because you think that is important. But eventually AI will understand the context itself, which it doesn't now.
Emrecan: Well, I totally agree with your first part. The second part — when you use Glean, Glean is exactly doing that. Glean is this ever-present contextual engine around you. So I will give you some examples, some magical outcomes that you only get to see when you actually use Glean in that context.
So let's take you and I. A very common situation that we would get into is writing some sort of a product strategy, PRD, spec. And when we think about the impact of AI on the writing experience, the more obvious part of it is "help me write faster, help me write better". That sounds great, and many AI tools can help with it. If you can get deeper, better context, then the output, the first draft, will be much better, of course.
But here is a non-obvious but very powerful way Glean brings that enterprise context into the act of writing, the journey of writing. When I am writing, there is always an audience that I am writing to, and then that changes. So sometimes I'm writing something to define, let's say, our direction for only the product managers and the designers, whereas some other time I am part of our C-staff, so I'm writing about a particular decision or an M&A activity. But imagine all the locked-in context about who you are writing to, the cast of characters and their idiosyncrasies.
If you think about going to an AI tool and saying, "Hey, I need to write a product strategy and my audience is my CEO, my CMO and my CRO, so help me write a doc that proactively addresses what questions or challenges they would bring to the table if I shipped this document to them" — imagine how difficult it would be to get that context.
But with Glean, I'm able to do it. Why? Because when I tell Glean to do this task, Glean is able to go and say, "Hey, who is the CMO of Glean?" Okay, I know who that person is. Now I'm going to look at how the CMO engaged in different product reviews, in different strategy discussions. What questions did she ask? What questions did she not ask? How did she respond to challenges? So there could be that context engine that is bringing all this incredibly tested but valuable knowledge that is not documented anywhere, because there is not a document that says "here is a one-pager on what the CMO asks when she sees strategy reviews". So that is the power of AI used in non-obvious ways, and I think this is an area I am extremely excited about.
So, one second if I may, I want to share something about exactly what you said on AI not working for all our use cases right now, and that's something that I'm very excited about. Earlier you asked: these enterprise customers, they might have so many needs, so many bulk needs. I have this accumulating insights — if that's the right way to call it — where I have thousands of pain points that I heard from our customers that AI is not able to solve yet. So I am keeping it, call it an ice box or something like that. But every time our R&D creates a new capability, every time a new model is released — and the industry is so vibrant right now — it enables some of those jobs to be done that were previously unsolvable at a good, let's say, performance level to become solvable.
So that is the incredible journey, I think, we are in today, where if you understand Anna's jobs to be done, as you said, you cannot use AI for every single thing you do on a day-to-day basis. But somebody will build that, because the industry will improve a capability, enrich any feature. All of a sudden that JTBD will become solvable, doable, and will deliver delight. So this is how we think about solving our customers' problems: running a huge list of what AI is not capable of doing today, but constantly assessing, as an industry, that we get things better at the speed of light, basically.
The future of SaaS and the gap in AI affordances
Anastasiya: I've got another controversial question for you, about the future. As you mentioned, long-term AI could have capabilities to solve more different use cases. But what about the future of SaaS products — are they at risk? Because eventually there could be capabilities of building custom solutions for different sizes of companies, for big ones, smaller ones, depending on the need.
Emrecan: I mean, for sure the answer is yes — but I think not collectively. I think it's going to change the ordering of some competitors, whether they are leaving the market or they are getting a small part of the pie.
Some imperfect example I'm going to give you. I have been a huge movie and film and TV series enthusiast. So if you think about what happened with streaming — streaming was an incredible source of innovation, but increasingly, when we look at the state of streaming sources today, they look very much like the TV channels of 15 years ago. There are like, I need to have so many subscriptions, and each one has a piece of the puzzle. If I want to watch certain things, it is there. Now, what happened at the end: industry fragmentation kind of didn't change, but Netflix ended up being the biggest winner. Like, they weren't playing a role in the TV channel scaffolding. Now they are the largest streaming player, but then everybody else is still there.
So probably with SaaS we will experience something like that. The ordering in the ARR or competitive size will change, but they will still be there.
I think what is — of course, the analogy I gave you is a very imperfect analogy. So I want to get back to the core of AI. So, stopping that analogy right now.
I think right now the industry is extremely focused on shipping AI features and capability at all costs, so that they can put a check mark saying, hey, we also have an AI tier. I think what is grossly understated, undercared for, is the affordances and the user experience around AI. This also bites into why we have such a wide spectrum of AI maturity, and why most knowledge workers don't have extremely meaningful ways of using AI daily — because we haven't spent as much time innovating on the affordances and user experience journeys. We don't have AI-native interfaces that can morph to what the user is doing today.
So that's where I think SaaS companies will need to evolve faster if they want to actually stay abreast, because one thing will not change, and that is the need for humans to connect to these services or experiences we built as R&D functions.
Full-stack builders, and the parts that haven't changed
Anastasiya: Yeah, that's a great topic that we can dive deep into as well, because I think that although technology evolves really fast, the software development life cycle and processes are lagging, and they are still — some companies are still working on waterfall, some are trying to adopt proper agile. And building for AI requires a totally different approach, like roles are mixed. One person can be responsible for the entire shipment of the features, starting from brainstorming, designing and even implementation. So I think that processes will be evolving, and who knows how it will work, what team structures will look like. But maybe I can ask: how do you actually structure your teams? Do you have any kind of new processes involved in the process of creating solutions?
Emrecan: Love it. I love it, and it's very much in flux. Maybe I'll share with you what has changed significantly, and also contrast it a little bit with what hasn't changed at all — and what is still as important in a traditional sense. At least for Glean.
So one, we are experiencing these notions of — and we might have different names for it in different parts of the industry — anything from full-stack builder to a product builder to a design engineer, where we are really talking about, give or take, the same person: a full-stack person that can write code, whether it is vibe code or actual coding, design interfaces, do the user studies, connect with customers, assess product-market fit, and get the product built to a certain level of maturity. Maybe it is going to GA, general availability. Maybe it is being able to run a functioning beta, or in the worst case running a working prototype in a user experience research, so that you can get the product-market fit signals to build the conviction.
But the rise of the, let's say, full-stack builder is extremely vital. And I do think for companies that exist today — I think we can talk about if you and I were building a new company from scratch, how we would approach it, but at least for companies that exist today — I think the full-stack builder or the design engineer is not something where you wipe the entire organization and say that everybody is a builder all of a sudden. It is something that I think you walk the journey: you identify who are the early adopters of this ethos, this approach, in your organization, give them the projects, see if it's actually working, establish them as ambassadors or coaches, change your hiring practices so that you hire more of them, and then over time you kind of run a sustainable transformation, if you are an existing company.
Of course, if you and I are building our next startup from scratch tomorrow — and we should exchange ideas if you have some — then we would approach it differently, in a lot more extreme way. But that part is changing quite a bit within Glean's R&D. I could easily point to software engineers that started operating as product managers, designers that started doing more of the code. But it is a very bottoms-up motion. Some people are adopting it much faster than others, but they are lifting all the boats, because they are acting as change agents for more people to join the movement already.
So that part is very ripe for disruption. The part that we should take as more granted is that no matter how you are building the product, getting the customers — especially in B2B settings, enterprise software settings — getting the feature ready for change management, delivering it to admins, running product release notes, providing the right help center documentation so that they understand, and giving them the tools for them to roll out to the test groups and then to specific employees and not to the entire company: those aspects are not changing.
So there is this notion of — I think you mentioned it as some product management and building processes — especially when it is about rolling out to customers in a bug-free, highly performant way, caring about metrics, assessing product-market fit. I haven't seen as many agents or AI practices doing that. And we still need great collaboration with go-to-market functions, the go-to-market organization, to handle that well. Otherwise a great feature gets botched in the product release cycle, because the customers cannot adopt it fully, and you never reach product-market fit with that feature. Does that make sense?
Anastasiya: Totally. There are so many things that we can go into. I would love to talk about success metrics and analytics for AI — that's a thing that I also struggle with, because I think that the current approach for tracking performance, the classical ones, are not well suited for AI solutions where the output of the AI should be evaluated by users. And there is another way, or trend, for product management as an entire knowledge pillar to evaluate AI output. But that's, I think, a different story. I'm just keeping an eye on the timing.
Emrecan: I'm happy to come back for a part two. I'm quite excited about those topics as well.
Why the right investor matters more than the size of the round
Anastasiya: Nice. Maybe we can schedule a follow-up. There is one more thing that I wanted to talk about, maybe briefly, before we dive into a round of quick questions — about the tension of raising a lot of funds. Because I think that startups are really excited about getting a lot of money from investors, but it comes at a cost. So their processes can actually change, and now they have additional stakeholders who may impact the decision-making. So do you feel that raised funds somehow changed the way you work, like the processes or jobs that you do?
Emrecan: I totally, I totally feel it. But I think I am seeing it as a net positive for a few reasons.
I'm a former entrepreneur. I raised funds. The funds I raised seem minuscule compared to how seeds and pre-seeds are happening at this stage, of course. But for a company like Glean, of course, if we brought in some arbitrary investor, regardless of how little or how heavy money they put in, it could have been easily the counterproductive outcome that you were describing. But getting the right investor could matter more than anything right now for a B2B or an enterprise company.
Let me tell you how I meet some of my most insightful prospects. The world's leading CIOs, CISOs, chief AI officers — they reach out to the right VC partners. I won't say every VC partner. To say, hey, what are you seeing as the most important AI tools for me to consider for my 200-person, 200,000-person organization?
So I care deeply about the investor's impact on understanding, again, the company's vision — not the products that we are building. But remember, we are stubborn on the vision but very flexible on the details of what we ship in a given quarter or two. When the investor understands that vision well and can actually represent the company, the startup, in meetings, rooms, discussions where the startup is not part of that, that can be game-changing for the company in terms of sourcing customers in a highly trusted way. And I have seen that first and foremost with Glean and the investors we have. They are making a huge difference in creating very meaningful conversations at the strategic level.
Second, the world's brightest minds are building AI right today. So many entrepreneurs, scientists, product managers, designers are building AI inventions today. So the stronger of a war chest you have, then the more innovation you can bring into your organization with M&A activity. Many of these entrepreneurs, let's be clear, they will never reach commercial success, but they will build incredibly useful technologies, components, product experiences. So when you have enough money, you can actually act very fast and then complete part of your suite with this best-of-breed, again, technological components or product experiences.
So, of course, these are the positive spins I see. But one needs to account for: when this money is raised, it no longer translates directly into "hey, I raised $100 million, so I'm going to 5x my headcount". Remember how we started this discussion — headcount grows, but the communication, collaboration and coordination challenges grow exponentially the more you add. So I think it's important that when you raise the war chest, it can be deployed actually into investing in AI research or some core technological advancements that you wouldn't be able to afford otherwise. So it shouldn't directly translate into growing the headcount linearly.
Quick questions
Anastasiya: For sure. Quick questions. I think we can at least cover two. Do you have a favorite quote?
Emrecan: Do I have a favorite quote? I have so many of them. Yes, I think the number one piece is: everything is obvious once you know the answer. It is something I go back to so many times.
Anastasiya: I love it. What about — what book influenced your product or business vision?
Emrecan: Okay, I am such a nerdy person. So there is this author called Steven Johnson. I read all of his books. He goes very deep in investigative thinking. So he wrote this book called Where Good Ideas Come From: The History of Innovation — I think that's the total name of the book. It's rather lengthy, but it has a fascinating deep dive into just a few innovations that changed the world in some very unexpected ways. But it grounds me a lot on how and where invention can and will come from.
Anastasiya: And the last question: what's the most unusual feedback you've got from a user about one of your products?
Emrecan: Most unusual feedback — I need to ask Glean about it, if you give me 30 seconds. Joke aside — no, look, I will share two, because they are equally fascinating.
Number one: you won't believe how many job applications we receive from our users, because they love Glean so much that they actually reach out and say, "Hey, I would rather work at Glean." So the user feedback was once: hey, why don't you put inside the product some quick and easy way of applying to a job at Glean, because you know what function I work at, you know I'm a product manager, you know my work, so I can submit my application with all my context in it. So that's maybe one.
Second aspect: I deal with the unheard part of Glean a lot — deploying Glean, administering it, iterating it, rolling it out to more users. And so our user — there's a type of user that we call admins, like the Glean admins. And I always thought about Glean admins in a way: hey, this is an IT admin. They manage hundreds of different software deployments. Glean is one of them.
But one piece of feedback was amazing. Somebody reached out and said, "Hey, Emrecan, can you answer these questions for me?" And I said, of course, but what is this? And she said, "Hey, Glean was the single most important thing I did the entire year in my role, and I am up for promotion and I'm writing my performance review and promotion reasoning, and I want to talk about all the great things I achieved with Glean."
So that perspective — how important the product is to my IT admin — that was completely unknown to me, and totally gave me a whole new perspective.
Anastasiya: Wow. Nice. Thanks for sharing this story and all the other things that we discussed today. It was a fascinating conversation. I really loved talking to you today. I hope you have a nice rest of the day, and I wish great luck to Glean — to evolve, expand, and just become the top product on the market.
Emrecan: Thank you so much. This was so great.
About Emrecan Dogan
Emrecan Dogan is Head of Product at Glean, where he leads product, data science, product operations and technical project management. Before Glean he held product roles at Stripe and LinkedIn, joining LinkedIn after selling the startup he had run for six years. He holds an MBA from Stanford Graduate School of Business and a BSc in Industrial Engineering from Boğaziçi University, and is based in the San Francisco Bay Area.
