Good afternoon, good evening, wherever you are dialing in. I'm Ben Cesnoka, partner here at Village Global. And we're delighted to have Jennifer Tejada, who's CEO of PagerDuty. Many of you know PagerDuty. She's helped scale the company from a promising little startup to now, of course, a public company with 30,000 plus customers around the world. And she's also an LP here at Village Global. Our plan for the next 55 minutes or so is Jen and I are going to chat for about 20 minutes on the state of PagerDuty, the impact of AI, maybe some tips and tricks on how each of us can accelerate our go-to-market and sales motions. Then we're going to shift and invite four successive founders to join the conversation one by one. We'll each have five or six minutes to talk about what they're working on, show a quick demo, solicit some input and reactions from Jen, and then we'll wrap up. So Jen, welcome. Thanks for doing this.
Thank you. Thanks so much for having me.
So let's start just to orient everyone and level set. Tell us the state of PagerDuty today. What's the current product offering and scale for those who aren't aware?
I mean there's really never been a more exciting time to be at PagerDuty. I always say to people like when you're the CEO, there's no getting promoted. So you have to reinvent yourself and find growth opportunities in disrupting the business, disrupting yourself, finding new paths to growth, finding new markets, solving new problems. And you know, I think as somebody who's been in this industry for a number of decades now, we really have just never seen a transformation or like the tectonic shift that we're seeing with AI move so fast. You know, I was around for the smartphone transition. It was the year of mobile for 10 years, right? Cloud, you talk to any of the cloud providers, they'd tell you there's still a long way to go in cloud adoption. That's not a mature market in their view. But the AI transformation is just happening so fast. You know, we're seeing such a different pace and velocity of change and it makes for some uncomfortable moments, you know, because a lot of the old playbooks that you would throw at some of these business challenges don't apply. But at the same time, it makes for really exciting moments. I was in town hall yesterday and I said to my employees like there's no limit on your capacity if you figure out how to deploy AI against some of the challenges and opportunities you're trying to address. So in this world where we needed a new person or new skill set to do something, like that's really not the case anymore if you learn how to leverage these tools in your daily work. You know, the second thing is like the way we operate and run businesses is being entirely disrupted and people don't like change and so you know the people who are willing to embrace change and be open to new ways of doing things are going to be more successful faster than the people who aren't. That's simply the case.
When you talk to enterprise customers today who are AI curious, there's some mandate coming down from the board that they need to embark on digital transformation or implement AI or whatever. What are the kind of core anxieties that you hear from your customer base? What are the key misconceptions that they harbor about the potential of AI or, you know, where the pitfalls may lie? Like what are you hearing from your customer base? And remember the folks joined today are mostly early stage, you know, AI native startups who are selling into enterprise and are always trying to work with these customers and figure out a solution that can work for them.
And they're complicated, these customers, these big enterprises, right? I mean I don't think you can ever underestimate, you know, how many layers there are to that onion in a large enterprise. And I also think one thing that continues to hold true is the aspect or the view on this set of challenges and opportunities is very different based on the persona, right? So, you're going to have a very different conversation with the CIO than you're going to have with the developer than you're going to have with the head of infrastructure versus the chief marketing officer or the chief customer officer or someone in middle management. Right? So, you've got to know what your starting point is and really try and understand before you even have a conversation, what does this persona, this person really care about? What gets them promoted? What gets them fired? You know, and then you can get a sense of like where their anxiety is going to come from. But I would say one, we're kind of seeing this shift from fear of missing out, like I got to be doing something, I got to be saying something, I got to have an agent to fear of getting in. What if I do this and I do it poorly, wrong, or it's too expensive, or I can't do it, or fear of screwing up, which is like what if it goes really badly and it destroys business trust, it destroys financial capacity, etc. So there is a lot of fear and uncertainty because we just don't have experience with something that's moving at this scale and at this speed. And so that's natural, but fear is good, right? Like I'm a skier, right? And if you stand over the top of a cliff and look down a crevice and you don't have any fear, you're going to do really stupid things. You need to figure out how to help your customer sort of harness that fear into, well, what would happen if I could solve these problems that you're worried about, right? So start to be part of their solution and harness that fear. But the things that people are worried about are the things you're worried about: security, how do I make sure this new AI investment that I'm deploying is going to be resilient and not cause more problems than solutions, right? They're worried about people, how do I manage the people transition? You know, and I see people learning the hard way asking folks who do the work today to employ AI to replace themselves. Like psychologically that's just not a prospect that's going to manifest itself quickly and so sometimes thinking about how you organize to get that work done has got to be different. So you have to have that conversation at the right level and then at the level of the people that, you know, may find that the work they do today is no longer necessarily necessary because a platform can do it or the AI can do it. You have to help them transition to where they can add value in the future.
Yeah. And let me just pause for one there, Jen, because I think you're making a couple good points and I want to make sure I understand them. So the first is you're saying across the enterprise today with respect to AI opportunities, there might have been a sort of psychological evolution from we must get in, we're fear of missing out, they're like talking about it everywhere, right? And then we've shifted perhaps to a fear of getting in. So from fear of missing out to fear of getting in and worried about unintended consequences, etc. And that's important I guess for everyone selling to the enterprise with an AI product today. If what you're saying is true, at least in some organizations, having a sales strategy that aligns with a customer that might be fearful rather than just raw unbridled excitement. So that's one point that's I think really interesting.
And I'd put a pin on that point, Ben, because in the old days when we were small, I would hear us say, 'Well, we're developers building for developers, so we know who our customers are.' And I would have to remind my team that the development team at Morgan Stanley is working on different things with different constraints than the development team at a Silicon Valley startup, right? So yes, it's true, you're all developers, but the problem set is different, the regulatory environment is different, the scale is different, etc. So you have to know, you have to meet your customers where they're at in enterprise and they're not likely to be at the same place you are. Even a person in this your VP of infrastructure and a Fortune 500 company's VP of infrastructure are not in the same place.
Yeah. Got it. And then okay, makes sense. And then in terms of this very interesting dynamic of hey, we have a product that will allow you to, you know, eliminate these three human jobs or make more efficient these five people. It is a funny sort of tactical sales question of if that's the value prop of your product and you're talking to the human on the other side of the table who will be directly impacted. How are they going to take that? They're probably not going to be a rational assessor of your product. So is your sales advice you have to be talking basically one or two levels up in the organization to someone that has the broader view on ROI?
For sure. My sales advice is that you have to align with the executive or the leader who owns the end, the lagging indicator, the end output. So in our case, we often speak to either the CTO who owns customer-facing applications, customer-facing agents, or the head of that digital business that owns that P&L because at the end of the day for them it's not just that the infrastructure, the ecosystem is not working correctly. It's that their end customer didn't have the experience that was expected and they're losing transaction velocity. They're having shopping cart abandonment. They're seeing revenue impacted by a technical failure. And that's a very different conversation than I can show you hard cost savings by automating your network operation center. You can see the difference and you can see why I can build a champion in line of business that then can help me move the needle, you know, in the IT organization. So, you sort of have to work the ecosystem.
Now, if we've shifted from FOMO to FOGI, and I guess we've just—I don't know if we've just invented that acronym in real time here, but if so, that's a great legacy for all of us. If we've shifted from FOMO to FOGI, then it raises fear of getting in. It raises this kind of evergreen question that all startups and probably all even companies at PagerDuty scale struggle with, which is how do you create urgency in a sales process to get these enterprise buyers to lean in? Right? If there's actually kind of a fear orientation or nervousness, that's usually cause for bureaucratic process: let's do it, let's triple check, let's do another review, let's think about it. What have you learned over these years? And what advice do you find yourself giving to early stage entrepreneurs and sales teams as they're meeting with customers to accelerate a go-to-market motion?
There is no substitute for discovery. And I think when sales teams are in a hurry or founders are in a hurry, I don't see this so much with founders tend to be so curious and they're constantly trying to understand the problem. But sales teams want the fastest way to get to the money. And so they often will skip the discovery, make assumptions and then get stuck later on in the process in a different stage of an opportunity. And so really trying to standardize and structure discovery and teach your sales people and your customer success people how to really understand where the customers is because there are some parts of the team like a lot of enterprise organizations now have dedicated AI teams and their only job is to support AI adoption in the business and they're going to move a lot faster than somebody who is maybe protecting their empire or their domain. So finding the right places to have that conversation is a big part of the discovery process. And in enterprise, one of the things I've learned is, you know, if you rely too heavily on assumptions and patterns, you will miss opportunity because every enterprise looks a little different. And our reps who have been the most successful in the early days are the ones that really walk the halls, really understand what makes the organization tick, really know who actually has power and influence and who doesn't as opposed to making assumptions about who has power, budget and influence.
Yeah, it's a powerful reminder. It is the case, isn't it, that as people, especially if they have some early success, early momentum, you begin to kind of ossify around a worldview or a set of assumptions as you say about what customers want. And this idea that you have to revisit those assumptions routinely, tune in to what the prospect you're talking to today, what do they really want? What are their pain points in the drive for urgency? We can forget that sort of basic first step sometimes.
100%, 100%. And it's especially more important now because the sands are shifting faster. So like even the playbook that worked for you two years ago may not work for you this year, right? Even the playbook that worked for you at this customer two quarters ago may not work because we're—one of the other things we're seeing is these organizations are changing and evolving so rapidly. Leadership's moving around. You know, headcount is compressing because of layoffs. Like people are moving around. So there's a lot more thrash in enterprise teams than there was maybe four or five years ago. And so also just staying in touch with what's happening in that company requires a lot more effort. But at the same time there are AI tools that can help you do it.
Kind of it reminds me, I believe there's been studies done in like, you know, doctor effectiveness and the patient-doctor relationship. And you know most patients when they go and see their healthcare provider walk out and report that they did not feel listened to or heard by their doctor, right? Because there's this incentive to churn through these appointments as quickly as possible. And that doctors that just take a little bit more time to listen find that they are dealing then with patients who are much more compliant in accepting the recommendations. Right? Like when if the doctor listens first and then says, 'Okay, you need to take these two pieces of medicine.' The patient's much more likely to say, 'Okay, I'll do that.' versus push back. And so being heard is a huge psychological unlock for people in every—
It's a huge foundation to partnership, right? So most of my conversations when I'm talking to executives in our customer base, whether it's now or nine years ago when we were small, have been, you know, please give me feedback on what you're hearing from your teams, what you think about our products and services and what I can do to help you get more value from what you've already bought.
Yeah, that's great. Look, we had a question come in from a founder, Jonathan from Ursula, who wanted to ask you, Jen, how did you structure early partnerships or pilot programs at PagerDuty before perhaps on product capabilities you hadn't built yet? Like how do you think about the roadmap and what's to come and wanting to close sort of early pilots and maybe a little bit of vaporware that's part of all enterprise sales processes without overcommitting? How do you think about that?
We have the opposite problem. We've never been good at vaporware. We were like founded in resilience engineering. So I kind of had the opposite issue here, but I've seen the problem that you describe. And you know what I would say is be really clear with a customer as to whether they're part of an early design partnership or whether they are part of, you know, being an early customer in your generally available product. I think the truth is always on your side here. There's nothing worse than having maybe an exaggeration catch up with you in the form of disappointment with the customer and it leads to churn. It leads to bad word of mouth. It leads to a lot of things that are much more damaging than just being honest upfront and having sort of clear design elements around what is early design, what is generally available. But I also think you can really drive time-based milestones within your organization around how long are we willing to be in early design because sometimes I think the mindset of best efforts leads to these early design programs bleeding on forever and that just makes them incredibly expensive, poorly controlled experiments.
One last question for me, then we'll bring up the founders. So Jen, you did not found PagerDuty. You joined as CEO and you've done an incredible job scaling the org since you're joining. How do you—what advice do you give founders who are contemplating bringing on, uh, you know, seasoned exec maybe to replace themselves as CEO potentially but even just to fill out an exec team to be a partner, to be a COO, to be a president alongside them in the journey. What has to be true for a partnership between the original founder and a hired exec to be successful?
Yeah, in any partnership I think it's incredibly important to very early days and then often on an ongoing basis to have clear expectations on who owns what, who's going to do what. And so in the case of if you were contemplating bringing on an experienced executive as a CEO, no experienced executive worth their salt is going to consider a role where they don't have autonomy to design and lead and operate the business, right? And so oftentimes what I'll see founders do is say, 'I really want a new CEO, but I'm going to keep finance and product.' And an experienced CEO is going to say, 'That's not a CEO job. No, thank you.' Right? If you're looking for experienced executives, I think there has to be a lot of intellectual honesty and self-awareness on the part of the founder on, you know, what do they know and understand that is unique to the leadership team, where they spike and where they will add a lot of value. What does an experienced executive bring, you know, that they know and understand that fills a gap and complements the founder and how do those two things interplay? Where it tends to come unstuck is when one or the other believes their knowledge and expertise overrides the other person's vision and ideas and that they're not open to having a healthy debate and agreeing to disagree sometimes, right? But it starts with the foundation of what are the expectations around what you own and what you have decision rights on, what I own and what I have decision rights on.
And I—I'd also say that like it requires a lot of humility, right? I mean, if I had come in and said, you know, I've been at this for ever long and I know how to fix all the things that you did. Imagine like the defense mechanism that's going to automatically deploy. And likewise, and sorry, and just because we're going to bring Danny up in a sec, but I strongly agree with this. So self-awareness on both the part of the founder and the exec. And then a humility from all parties. And I think self-awareness often in short supply. Humility often in short supply. It's no wonder why a lot of these hires don't work out inside companies. It's a testament to you and the founders of PagerDuty that it's been such a successful partnership. Let's spotlight Danny, Sheila, Jen. What we're going to do now is five or six minutes per founder and they'll tell you what they're working on, maybe a couple questions, you can screen share if you want, Danny, and show the product and then we'll move on to the next person. So Danny, take it away. Introduce yourself.
Hey everyone. Hey Jen. I'm Danny. Very happy PagerDuty customer mostly because we have no incidents. I'm just kidding. So we started Jam to make software a lot faster to develop and the bottleneck that we were focused on is how do we make it so that every time a customer has some sort of issue or there's some sort of incident or something has gone wrong that an engineer can spend time fixing it instead of just trying to figure out how to replicate this issue. So let me show you what we've built. I have here a web application that has bugs on purpose. Like this upgrade flow doesn't work. But luckily, I have a really great way to record it for engineers. I can just share what just happened. It captured what is on the screen. It automatically reduces PII. It grabs everything from the console logs, network requests, AI writes a description, all the repro steps with timestamps for the engineer. You can send it to a ticket and essentially what the engineer gets is a perfect bug report on the other end. And so you get all the session details, console logs, network requests, and you can send it to an AI to debug it for you. And so what we hear from customers that use it is, you know, before Jam, like something would go wrong and then they would like hop in a screen share, the PM would get a lot of questions. A customer would have to get questions and after Jam something goes wrong, an engineer hears about it and then it just gets fixed, you know, move on. And so this has been live for three years. A quarter of a million people used it last month to debug almost 800,000 issues. It's growing. It's crazy. And then we started to think, well, what if you don't have to report a bug at all? And that's what I'm so excited to show you. We built a product called Please Fix, which allows anyone when they're just looking at the site, if they see something that they want to fix, to not even have to ask an engineer to do it. They can just fix it themselves. Like they can fix copy or they can change some styles. They can also use AI to change more complex styles. Like I can just say make this hero section look more like Apple. And an AI will actually look at the page, think about it, and do it for me. And when I'm happy with all these changes, it's so easy. I just click publish to GitHub. I'll show you in a second. Okay. I don't love this gray background, but I love everything else and I don't love the shadow either. But it's really easy to just edit. You can just edit in line like you would edit a Figma and when you're happy with your changes, you can create a PR. And so I think the change that I'm personally very excited about and very interested to hear your take on is in the past when someone wanted to see something that they wanted to fix it would have to be like communicated through product bubbled up to engineering prioritized and in the future I think everyone is becoming a product builder and this is uncomfortable for engineers and it's actually uncomfortable for everyone but I think in the future everyone is going to be an extended part of the engineering team. Everyone is going to be on the product team.
I love it. I mean, what I really like about it is you've disrupted the entire workflow and attacked the problem differently. And so AI is a great enabler to that, but it's actually the way you've deconstructed the problem that I think is so ingenious. And the other thing that I like about it is it's kind of hard to argue that this isn't a better, faster workflow. I think for enterprises, one question that they will have on their mind that could potentially become an obstacle or a barrier, an excuse is how does this interact with my change controls? And particularly in highly regulated industries like financial services where the idea that somebody could just change something from somewhere in the business would make them really nervous. And I'm sure you've got an answer for that.
Yeah, and which is it just pushes to get, and it's the same change controls you've always had.
Got it. Got it. I love it. Danny, tell us—and by the way Dan, if you could stop sharing your screen for a sec just so we can see the full size again. Awesome. Tell us looking forward over the next like six to 12 months. What are you most excited about in terms of how especially AI is enabling your product roadmap?
Annie, we talked to a lot of engineering leaders. We talked to a lot of leaders of support, product, design, marketing teams. They are all rolling out Cursor licenses for their entire teams. They're feeling very forward-looking when they buy the licenses and then, you know, actually the licenses don't get used and the reason is there's a huge delta between having Cursor and actually being able to use it because you need to run a local dev environment, you need to maintain your local dev environment, you need to use git, it's kind of out of the skill set of most non-engineers and so the thing that I'm very excited about is I believe that at every company everyone needs a Please Fix seat, it's the in-between a Cursor and actually a Figma, it's the non-engineer way to actually—
Contribute and make the dream real, and we love reducing toil for human beings. A lot of what you're attacking here is really frustrating paper-cut toil, so I love that.
Is it true, Danny? I haven't seen stats on the Cursor utilization question. Obviously the ARR growth and customer base is massive, but is this anecdotal or have you seen data on low utilization after people implement Cursor?
In Cursor's customer base, it's probably mostly engineers. There's probably a very high utilization rate. When we talk to our customers and they are trying to roll out Cursor to their design team or customer support team who are on the front line of hearing about fixes, those utilization rates are extremely low.
It's the code system for everybody else.
