The product wisdom every CPO should ignore | Jeremy Epling (CPO, Vanta)

All right, let's do it. Thanks for joining. Yeah, thanks for having me. Normally when you look at someone with a background like yours, basically 20 years in various roles at Microsoft, they then join, not a small startup, but a scale-up startup, certainly relative to Microsoft, a tiny, tiny company. Within 90 days, it's a complete disaster and the person leaves and goes back to sort of the wonderful mothership. What is it about you and what you figured out, and maybe the specific things you worked on at Microsoft that you think allowed you to be effective in, after such a long time, changing context so dramatically? I think that for me, right out of university, I had like a startup. So I guess there's like a little bit of that like DNA in me. It lasted for like nine months, ended up getting me a bunch of job offers, but didn't like really go anywhere. So this is like back in the day when the bubble had like just burst on that first wave of like internet companies. I mean, I started Microsoft in 2002, so it was right around then. And so I think that a big part of the learning for me was I always wanted to switch teams and I've always wanted to learn new things. I think it's just like part of like my DNA. And so even when I was at Microsoft, I kept trying to switch teams every three or four years into like a brand new product area. So like when I started off, I was on Windows working on security and deep technical things. I was on Internet Explorer for a while, then I joined OneDrive and that was like a zero to one. And I really enjoyed that process of zero to one. I think a big transformative thing though was going to GitHub. When Microsoft purchased GitHub, I came over right after the purchase to lead all the new product development there. And to me, like Nat was just very much a like founder CEO. I mean, obviously he's exited a ton of companies, been a VC, done a bunch of amazing things. And that company was run very independently. Like I literally quit Microsoft, like your contract ended. It was like, we used all Google tools, everything was built on AWS, everything was Zoom. When Satya sent emails to the company, they didn't go to anybody that worked at GitHub. Like badges didn't work back and forth. HR benefits levels, everything was completely different. And so I think that really helped me get a taste of what it would be like. And I think one of the things that I loved was just the tight connection across the entire business. Like I feel like there's a lot of great things about Microsoft, but In my experience there, you kind of feel disconnected from the go to market motion. Like it's, it kind of feels like it's on another planet. It's like, you're just trying to build the best product. And then somewhere over in the ether, lots of money is made that like feels pretty disconnected. And I think at GitHub, I got to see it all come together. It was like being deeply involved from our product to the messaging, to the marketing, to the revenue, going deep with SEs, thinking about our positioning, all the pieces. And that just really excited me. And I was like, I want more of this. And then as GitHub grew, which is great, it like kept growing and growing. I was like, actually the most fun part was like the earlier stage. What's some of the stuff in the context of the GitHub experience when you went from being very product-centric to being much more full stack and at least owning or involved in a bunch of the commercial elements? What were some of the interesting learnings from that experience? I think some of the big ones was one, like I developed a really close relationship with our head of SE, which I think was really important. I think when you're doing like a technical sell like GitHub, you know, the SE team plays a huge part. Like AEs are critically important for setting up the relationship and navigating the org chart, doing all those pieces, but building that tight feedback loop of understanding practically what is working and what isn't each time they're going through the sales cycle and then how they're implementing with customers and driving that feedback back into the product. I think that loop, I had a little bit at Microsoft, but was not nearly as tight as it was at GitHub where I felt like I was talking to our head of SE, like almost every single day. And I was working on new products. You're kind of in that stage of like, you really need to figure it out. Nat, I think really pushed a culture around understanding like our marketing and positioning. So I got to spend a lot more time understanding how we're telling our story, how to tell our story a lot better, how we can go through in pricing and packaging, I think was something that I spent a lot more time on than I had at Microsoft. You know, with GitHub actions, that was like one of the products I built while I was there. You know, we were doing usage-based pricing. It was the first time GitHub had ever done usage-based pricing on anything. And so how do we think through that transformation? The nice thing is I could still go and talk to people in Azure that I knew and worked with of like, how did they go through that transformation? But then think about what does that mean for GitHub where, hey, we're selling a product every day. People are used to just buying licenses for every developer on their team. Now we're telling them to think about like compute and storage and how do they estimate that? And how do you make that friendly for an open source developer? How much should we give away for free for open source? And so I think that was like a really eye-opening experience to me of just the entire impact of the product holistically through the business of like the pricing and packaging side. I spent a lot of time thinking about COGS. When you're running like large infrastructure, like CICD for these like workloads at massive scale, it's very expensive. We actually racked our own Macs in our own data centers there. So like thinking about like the hardware supply chain and how long that takes of like, okay, we think there's going to be a new Mac mini coming out here. How do we need to go think about the networking setup and all those different pieces? So I think it just exposed me to a lot more breadth of the business and made me appreciate everything that goes to delivering like a great product experience versus just the individual kind of features or like the smaller bubble, at least in my time at Microsoft. I'm sure things have changed there that you were kind of kept in there. So with all that as a little bit of context, when you think about the job of the chief product officer in the context of sort of a scale-up startup, how do you define excellence? I think for me, you have to be in the details. Like I know there's been a lot of talk for the last year or so around like founder mode or not. I'd say I'm definitely on the side of like the founder mode interpretations. Like you need to be in the details. So for me, I want to understand what is the experience we're delivering to customers and how it's great. And I think the more disconnected you get from those, like when you start to become more of like a professional manager, I'm just guiding the team, giving strategy and things. I think you lose a lot in making sure you're building the right thing for customers. Because if you're not in those meetings, if you're not like selling the product, if you're not like demoing it and using it every single day, I think that's when you kind of get this disconnect. And I think that's what I see happen at times at larger companies where they get there. You kind of end up with this kind of professional management class and then the people like doing the work. And then I think that's when the product starts to get confused about what it's doing because not everyone's using it and like knowing like where it's going and why there's a clear direction behind it. So that's sort of one piece. What else is in like the job spec for a chief product officer? I mean, I think for me, understanding one of being able to deliver like at pace, I would say that is one of the biggest things. Like you need to keep up a high velocity set of new features coming out to customers, making sure that you're having like a really strong like win rate. I'd say win rate's like a metric that I think a lot about, especially if we lose, why are we losing? Is it pricing and packaging related? That's something product can go do work. Is it like a product deficiency? What can we go do there? I think on the side of like being able to cast out the vision, I think it depends on which CEO you have. Like some CEOs want to own all of that. Some of them want to delegate some of it or part of it to like the chief product officer. So I think understanding where you are there of like how much you're going to be doing on the vision and telling the narrative and the story. I do think even with marketing, being able to tell like amazing narratives, the product team needs to be able to explain because you're the one talking to customer kind of building the product and be like, okay, we're building it for this persona in this way and be able to like transfer that knowledge over. In my case, I also lead engineering. So for me, there's also like a technical side of the job as well of understanding the architecture, how we're doing on kind of like SLAs and scale, making sure we're building for the future while trading off for like short-term things that we need to go deliver, especially when you're in that scale-up phase. Like if you're joining at like a B or a C, I felt like a lot of my conversations were Those two things. So I usually come back to like the customer feedback loop, I think is interesting. I think I've had this experience in the past where the product usually falls into a bad place when it feels like the product team is just like order takers from like the revenue team. You know what I mean? Where it's like customers complained about these five things, go fix these five things. And it becomes very reactionary. Then you don't have much of a strategy of like where you're going. But there's also tension because there's a lot of goodness in that loop too. Right. And those are gonna land deals. So like you need to be able to do a certain amount of that. You just don't want it to go all the way there. So one of the things that we've been doing is trying to do a good job also sharing like, hey, the product team from all the calls we're in, here's what we're seeing from customers. Is it similar or different from like what the revenue team is seeing? When you think about this sort of fundamental tensions we're talking about between product and revenue, for example, how much of this solve is just a really excellent relationship between the chief product officer and chief revenue officer? And that it's two humans and if they generally enjoy and respect one another, it solves 70% or no, you can have that and there's just, there is a core. There's a physics of it all that you sort of have to manage around. Yeah, I mean, I think that's the core of like making it successful. And I think that's something that, you know, just Stevie and I have like leaned a lot into, is understanding like, hey, how can we quickly and easily work through things with our teams between the two of us? I do think there's always a bit of like built in tension, you know, in the system that I actually don't think is a bad thing. Like I'm comfortable with conflict and things and think like companies are more successful and more comfortable. They get with conflict and don't look at escalations as bad things. I think a lot of it comes down to that relationship. Like, can you share what you're really concerned about? Let the other person kind of like listen and take that in and then go back. Cause like there'll be, there'll be feedback going the other way too, right? Like the product team could sit in a couple sales calls and just be like, oh my gosh, we just shipped this amazing new thing. And like, no one's talking about it. Why aren't we talking about it? You know what I mean? And maybe that's a marketing thing or maybe it's like a sales training thing, or maybe it's just that seller didn't know where we haven't gotten the pipeline going. So I think that open lines of communication is really important. And I think that's what becomes that, that kind of like C Team thing that we mentioned before of just being able to share, like, hey, we're seeing this. And I think it's like coming less with solutions always works better, you know, probably on both sides, but I can at least say on the EPD side, you know, when someone comes to me and is like, hey, we have this problem. Like the competitive situation has changed here. What should we go do? I always feel like it turns me on to like a more receptive side than I get the like, can you please ship these three features like tomorrow? And then I'll just be like, what's the actual customer problem? Like maybe that is the right solution, but maybe it's not. And so I think the more everyone's interacting that way of like, what's the problem we're dealing with? Let's go look at it and see what everyone can go do to make it better. That's the best way to make it work. So how do you think about good conflict versus bad conflict in the in the context of an executive team? I like like just talking about things directly. So I feel like if people someone's like, hey, I don't think this is working. I would just want to go and like put it out on the table and just be like, great, let's go talk about it. And so I think when we end up like dancing around things or having too many one off conversations, it just gets exhausting for everyone. And, you know, this can be like everyone's kind of like talking about it, but not together one on one. And then you feel out of the loop or you hear about it third hand or whatever else. So I think one of the things Christina does really well is like we have a lot of time for like the C-suite to get together each week. And we go through and just be like, hey, these are the top topics that we need to go through. And all of us can put things on the list and it can be stuff to do with our team or not to do with our team. And I think we try to approach it all as like open and respectful, but also just be like, hey, here's here's the problem. Like, I'm not happy or I'm worried that ACVs are going down here or I'm like super excited that this product is doing really well and selling really well here. Like, should we I'm thinking about moving even more EPD resources to this, but that would mean I'd be sacrificing in this other area. Like, how does go to market feel about that? You know, and so I think it doesn't always have to be like issues that you're talking about there. It can be like exciting new things, but I always try to stay in front of things of what we're doing. I think overcommunicating is just key. I think it's something that like I still I'm trying to do better is like communicating more at the right level so everyone knows what's going on within my team because so much of what the product is doing just kind of has downstream effects on everyone else. So, you know, if we're like, hey, you know, we've done a big bet on like federal this year and we've gone through and done FedRAMP 20X, we got our low authorization and have been like really involved with all the changes that are happening to kind of like security from that regard, like with the administration and Congress and everything. And you know that meant trade-offs in other areas. Like, hey, that's a bet that we're making. So that was something I brought to like C Team and I was like, hey, here's why I want to make this bet, the, the intensity. Like, here's what it would impact in other areas. How does everyone feel about that? Like, can we still hit the revenue numbers? Do we agree that this growth opportunity is the same? What does that look like? I like docs a lot. So I'd say we have a pretty heavy doc writing culture, but we try to keep them like short. So like, I don't know, I have a bunch of catchphrases, but like one of them is like clarity through brevity. So I'm just like, just tell me exactly what we want to talk about. Can we just get some bullet points and like make a decision here versus, you know, like some 80 page PRD, which I just feel like is kind of like pretty outdated at this point. And at that point I'd much rather just get like a V0 or Figma make prototype or just show me pictures to see the customer experience. But like on the C Team side, yeah, I think it's talking about the hard problems. So it's not like there's like an elephant in the room, trying to be like really constructive around what that is and then bringing as much data as we can to it as well. I spend a bunch of time trying to understand our product revenue data, looking at like how things are going on, like the sales time, sales side, and then also on like just our use of product usage data so that we can like pull all these different pieces together. Our finance team does an amazing job pulling together like deep product revenue and then tying it with the sales pieces and bringing that in. So a lot of what I like to go do on decision-making is like, what do we need? What data do we need to make this decision confidently? Because like the thing I hate the most, I don't know if you've ever been in this situation. Microsoft had this term called like fetch a rock where like someone's like, hey, can you go fetch a rock? You're like, what rock? And you're like, I don't know, but like bring it and you bring it. And they're like, actually, it's not the right one. Well, what one do you want? I don't know, fetch another rock. And so I think that's the worst. So I try to, I think we try to define boundaries around things and say that, hey, here's the decision. What data do we all agree if we had this data on, like sometimes it'll be gut. Sometimes it'll be real data. We can make this decision and then we can all represent it as a group because like I think disagreeing and committing is also a big part of the job. Like there's definitely things where, you know, I don't know if I believed it and I was wrong in times where like I, you know, I was right and we didn't end up doing it, but like we all represented as like the group decision of like, hey, this is where we want to go and why. And we're all in it together. Do you think exec teams are most functional when you have all sorts of different personalities around the table, or is it much more functional when everybody's wired the same way? So the whole group is like a group of disagreeable people that like to debate and argue, or you want like one very opinionated, disagreeable person. You want more of a peacemaker personality. You want sort of that type of thing. I'm not sure. I think with us, I would say if everyone's disagreeing all the time, I think it's going to feel like The thing I learned at GitHub, I felt like working with Nat, who is like a product founder, I felt like was pretty similar as well where if someone on my team knew it better than me or anything, I'm like, Nat, just go work with like Chris on this thing or go work with like Neha on this thing. Like, don't ask me, you know, and I don't even need to be involved. And so I think when you get in this like command and control military style structure, everything has to go up and down and everything, like this is what kills like these big companies. And so to me, I want everyone to feel like they can work with the CEO on anything and feel comfortable working with them and that it's not a problem. And that I just know with Christina, I'm like, Great, you're on this one, so I'm not going to go and I'm going to go spend my time on these couple other things. And so I think just like being clear about like what those boundaries are is to me the most important part of it. In the way that you've seen it, when a CEO wants to get involved in some new product or some product detail, do you have the same standard that you expect them to operate in owning that? Or if the CEO is going to own this and it's not the way that like a diligent engaged, you know, PM that would own this, you give them slack or they're expected. If you want this, it's all you, but you better execute this well. Yeah, I never give them like complete ownership. If like in that regard, I would say I always assign a PM with it. And it's a PM that's like excited, it's cool to work with like the CEO and the founder on things. So like usually it's not hard. They don't feel like disempowered. They're like, Oh, yeah, this will be fun to get to work with Christina on it. And then it lets her still stay at a more conceptual level. So if something big does come up like, Oh my gosh, we're about to go do a fundraise. Like that's going to take a bunch of her time and she can't do the day-to-day work with like IC engineers and things. So I always try to have a PM and a designer, usually someone also that's more senior, like ideally staff level for us, or if not, like a higher senior person, so that they can just understand what like a high level exec communicating something means practically and how to translate that down. So like Christina isn't pulled into like, you know, detailed minutiae decisions. Do you think that way of operating, which is that a CEO can operate at any level in any function is just globally correct, or it just works in the context of some of the companies that you've worked at? I mean, I'm sure it hits scale limits. Like, you know, I doubt like, you know, Sundar or like Satya can operate that way, you know what I mean? With like whatever 200,000 people or whatever they have. I think those companies just become like very different when they get to that scale. I think when you're still in the thousands though, like you should still be doing it. And I think that's part of our philosophy, like at Vanta, I think we really expect people to be in the details. And that's something that I believe a lot. Like, it's just hard for me to think about how I can coach an engineer or designer or a PM to be better if I don't know what they're actually doing and how to go do that job. And I'm not in those details to some degree. Like, I mean, I, I tell our designers when they, when they come in and get hired, I'm like, I'm gonna be leaving comments in your Figma file. That should not scare you. It does not mean you're doing a bad thing, but like, just try to like normalize the behavior of like, Hey, we can have it. I think the thing that I've learned here and I learned from one of our design directors, Braden, that was really good. He came in with this like mechanism that was pretty good where he actually just puts like what level of feedback is in front of everything. Like, this is an idea. This is a suggestion or like, I expect you to take action on this. I think that's something I've learned from my team that, like the more I've kind of grown in the size of my team or seniority of my roles, like that executive megaphone, you just like, don't understand how it's going off and impacting all this other stuff in your org in negative ways. So I always try to be a lot better about that and repeat things multiple times. Like I send something to a team. I'm like, I'm expecting action on this like quickly or like, I just want to have a brainstorming conversation. Please do not change the roadmap. And I'll literally put it in like all caps. Like, I just want to talk. Even sometimes when I do that, they'll still be like, Okay, we made three adjustments. And I'm like, no. So I think there is, and that's the burden that kind of comes is like your team gets larger is really pushing on them to like set expectations of when you want something done versus when you don't. If you're going to allow that level of movement, you know what I mean? Where the CEO is going to come in and talk to the team about something or even me, like, I don't know how big the team is now. It's like 350 people or something like that. So like the EPD organization I have is like pretty large at this point, you know? And so it can be kind of scary for someone that just started for to come in and meet, like leave a comment on their like PRD. And they're not sure what that means, you know? And so we try to normalize that as much as we can. You touched on this a little bit, but you know, an engineer, when you think about the, the thing that they're producing, it's software. And then ideally a valuable product that a customer then wants in exchange for money. A designer is maybe doing prototypes or mocks or finished designs. And they, the output is design and maybe what they're responsible for depending on the organization is some version of product quality, impact, whatever. How do you define what the output of you in the chief product officer role is? I mean, I think for me at the highest level, I guess there's, do customers love the product? And like, how do you want to measure that? Some of that I think can be measured through looking at like win rates and how we're doing and how many showed those or like product efficiencies or not coming up. I think customer satisfaction on specific areas is really impactful to me. I'm not a big believer in NPS. I know some people like it. Like, I don't think it's like that useful, but I think going and doing customer satisfaction surveys for like core workflows of like, Hey, did this make your life better? Did it not? What were the gaps? How was it? Like those are other important areas to be looking at there. I think the like velocity of like, are we continuing just to ship new features and do we have like, not just a product that excites customers, but like a vision that excites customers and feels like differentiated. So I think those are some of the big, the big outputs we look at there. I mean, I think there's per product revenue is something I look at a lot. You know, I think the sales take, at least the way we do it and the way I've seen it at most companies is more like, you know, you have like new logo versus expansion. You have it broken out by like, you know, different segments and territories and all those different pieces. I instead find that the dashboard I go to and have the finance team build for me is all based on product lines. So I'm looking at like, great. Okay. We did a bunch of investments in this product. Are the ACVs going up? Like as an output metric, not like an in, there's lots of input metrics of like, are people using it and whatever else, but those are metrics. It's like, is it going up? Are we selling more of it? What does the attach rate look like there? Is it selling to the right persona and segment? So like in our marketing data, when we do like outbounds and when customers come in, we classify them into our different personas because security teams are pretty different. Like a startup, you probably have no one that's actually their job is security. It's like they're moonlighting as something else and it's just like the founder or the technical founder. And then you have big companies where they have like CISOs and like multiple layers of like hierarchy and high specialization where like, there's a whole team that just does internal risk that is different than the team that would be handling audits or internal audits and everything. So there's a lot of specialization. So we classify those and then we think about what we're building products like, Hey, I'm building a product for like Susie Security and for her, that persona is basically the first security hire in a company. And it's like, how are we doing against her? Is she buying the product we want? Is she using it the way we want? And like, how is that growing? And then is the breadth of our product offering growing? I think Christina has an approach that probably a lot of other founders do where like, you know, her first experience was at Dropbox, you know, and she was working on paper and it was like a product that they were trying to expand out to be more multi-product than they are today. And I think Dropbox has done that successfully in some ways, not in others. And I think she has brought that very fully into Vanta. Like we have to be multi-product and like to tie back, I find it just to be helpful, especially when you want to have this culture where there's not as much hierarchy. I think just like demystifying who I am and like what I do, and I try to be like vulnerable with my team. I try to tell them like areas where like, hey, I'm responsible for this. And I'm like, I think I messed this up, you know what I mean? And here's a mistake that we make that like I'm responsible for and like what I learned from it. So I think having a culture like that just makes it easier for everyone to work with people at like different levels, when they're just like, oh, my leader is doing this too. How long is each one of the slots that somebody can sign up for? Oh, on those, I think it's 20 minutes. And you get all sorts of range of things that people want to talk about. Yeah, yeah. I mean, I've had like brand new ICs that started the company that week and are like, hey, I'm so excited to be here. I just wanted to like meet and talk. And I'm like, great, let's grab that conversation. Versus someone's like, I have this super opinionated design decision. I would love to know if you think this makes sense or not. And we're like going into the pixels, you know what I mean? Very detail-oriented or it could be like I had one a week or two ago where our engineer that's leading kind of like, how are AI enabling our code base, just had a bunch of things he wanted to go talk to me about around, like, hey, so we've met with these different companies that are doing the same thing. Here's what I've learned. Do you have any strong opinions on these? Like, I'm drafting out these comms at the entire team. Does this seem right? Are you aligned with it? And I'm like, yeah, this sounds great. So that one was more of like a working meeting. I mean, I'm sure you can go do this. I don't think that I just can't imagine giving some of the feedback and conversations I want to have to people in like a group setting and that being the best way to get the outcome I want. Why do you think that is? And have you tried it? I have done it a couple times. I think sometimes I've done it good and just times I've done it not good. You know what I mean? Or I've maybe been like too harsh in like a group setting. I think there's a set of people that I've worked with who, you know, they kind of get these, there's like these triggering moments when it feels like I'm being like criticized in front of people or like that produces them into like a really negative, frustrated with their job, unhappy with you, feeling like you're attacking them. And then there's other people that are just like, oh, that's fine. I would say I'm very much in that latter camp where like, I don't know, Christina, like I tell her, it's like, I was like, you can disagree with me about anything in any meeting. Like, you know what I mean? It doesn't bother me. Obviously I'm going to feel bad for disagreeing all the time and like then I'll be like, okay, I'm probably having a performance problem, you know, that like I need to go improve. But I'm very comfortable with that. And I've just found there's a set of people that like aren't. And if I want to get the best out of them and I don't necessarily have to force them to work the way that I work. So there are people that I have longer one-on-ones with specifically because I know it helps them do better results. And I think it's worth it. I'm like, whatever, another 30 minutes, like a week, like, you know, for one of my directs, like that is completely worth it if I know it's going to help them do their job a ton better. Like I can adapt to people and not have them all be forced to adapt to me. Yeah. I mean, I, I think that, that companies and teams are these complex organisms. So like my guess is if Jensen has been running the company for decades like this and everyone's indoctrinated or there's positive selection bias where that's fun and enjoyable for them, that it can work incredibly well. I think the dangerous thing is to assume that in that, that organism it's successful, so you can just, just yank it out of there and jam it into your company and it's going to be successful. Yeah, I agree. I think there's like a whole, when you've, yeah, when you already have the system working that way, there's a bunch of people that are opting into that system. And then versus you're like, oh, I decided I'm going to go do this. And there's a bunch of people that are like, I did not sign up for this. Like, this feels bad. And like, maybe that's the right decision and you want to make it, but yeah, it's a lot different. When you think about influence in an organization, you have what the org chart says in most companies. Yeah. You have some sort of, you know. There's definitely the shadow org chart as well. But on that point, you have, you have sort of a director, VP, et cetera, et cetera. And they have influence and authority. You were mentioning this a little bit, but in any company, there's all sorts of people that aren't a director of this or VP of that, who end up having an incredible outsized influence on the company. Who are those people generally? Like, how do they end up in those positions of sort of informal authority or sort of these people that people end up going to, even if they're not a chief this or a VP of that? I think this is the opportunity for like ICs. I think a lot of companies don't celebrate ICs enough. And for us, like, I want ICs to be able to get all the way to the VP level, like at Vanta and have that level of impact. And so I think a lot of people that end up in these roles are often like ICs. You know, you can read the kind of like books about like Apple's past with Jobs and like different people that have done like amazing work there and how they were able to go and influence. I think one of the things about them is they're usually like extremely good at what they do. They can communicate it well to executives. And I think that is a skill. You know what I mean? Like they know how to, in our case, go or talk to Christina or in the GitHub case, talk to Nat in a way that like Nat will understand or Christina will understand like what they're saying. And see the value of it. Do you think those are two separate things between the two of them or there's a correct way to communicate to a C-level person or a CEO? I think it depends on the CEO, but I do think that being great at your job and being able to talk about it to like the leadership team are two different skills. The other thing that I think they do is they're usually more on like the, they're thinking about where we should be going and more like visionary where they're like, what is happening in the industry? Are pretty tapped into that and bringing that knowledge back and trying to like affect change. Like they will go through and be like, hey, this awesome thing happened in AI, like when computer use came out for the first time. And they're like, wow, this could be huge. I went and spent the last week prototyping all these things. Here's what I built. Here's what I learned. We should be doing more here. Here's why. And they kind of set these things up on like a platter and then they'll go and get a bunch of other people excited. And you can usually go to them. And I think there's about a bit of social influencing here too, where if someone that I know, I can go to and be like, hey, I really care about this. And if they care about it too, I can be like, can you help us drive this message across the team? And they're just kind of socially connected enough on the team. They'll bring it up in meetings. They'll like bring it up in all hands or they'll do different things and kind of like carry that message forward. So I think some of the things, and I don't think it's like someone that's like a perfect social butterfly. You know, I think there's like your stereotypical engineers that are like less that way that are still really good at this. But I think that's part of it. I think the negative, the bad part that can come of this is there kind of becomes like an in crowd and like an out crowd that I think you can control that like pretty well if you're thoughtful and like don't let the system getting abused. I think it is making it so it doesn't feel like they're invited to all these certain meetings and kind of get pulled in to discussions that like no one else is. Like I try to make it more informal. Like if you're in an office setting, it's just like, hey, we have some engineers that will just like always come to me. If I'm in the office, like I'm not, I'm remote, but like we'll come into Christina and like talk to them and go do those things. And I think that keeping it there, but we're not also gonna like be inviting them to like every C-team meeting. You know what I mean? And be like, oh, what is your thought here? And can you write this paper? And can you do all these things and we're not gonna tell your manager that they're doing it. And so I think that's when it starts to become negative, where it feels like this person now has been like, you know, kind of like elevated into a status that like no one else has been versus someone that's just doing really good work I'm like, you're 75, I start to get worried. Like, I want people to take a risk, too, and I don't want to build a culture that, like, sandbags everything so that they can say they hit all the dates. The last couple of things I wanted to talk about. When you think about the trajectory from being an ICPM or engineer all the way through running product design, engineering, what learnable skills were the hardest? Not that there's a lot of innate things, obviously, in you that you are well-built for this role. But what are the things that, like, you actually had to learn from a knowledge or skill set perspective that you found were both important and hard? It's just like, it's hard. You know, some people just aren't natural at it. I think I had some natural ability, but then a lot of it, like, I had to, like, just learn and practice. And you end up just, it's just reps. Yeah. You just put in the reps. I remember when we announced, like, GitHub Actions, I did, like, the big demo, and I remember being, like, super stressed, you know, before the demo. I must have run through it, like, at least, like, 40 times, you know, I'd go into the demo saying it all, was, like, super nervous. I think it came off, like, really well, but you know what I mean? I had to, like, put in the reps. And it's like, we've got VantaCon this week, and, like, I've done this now enough where it's, like, okay, I'm just gonna need, like, a rehearsal or two, and, like, I'll be fine, and I've read the script already. But I think those were things that you put in the reps. Those are the more performance ones. But then there's just the, hey, you need to be able to get the team jazzed and focused, you know, at the all-hands. Like, how often do you do those? If you do them, like, weekly or monthly, or, like, just be able to turn it on with, like, candidates and, like, get into that, like, sell mode. I think that generally, certain people just maybe don't have that, and it's something that you've got to go and learn and it was something that, you know, I had to go learn definitely parts of that. So I just want to wrap up. When you think about being effective in the role of chief product officer, who throughout your career has been the person that you've learned the most from? And is there, like, a tangible thing that is expressed in the way that you sort of execute in the job? I think it would probably be, like, Nat at GitHub. And I think the thing that I learned the most from him was just, what does it take to build and deliver a product quickly that people love? And I think I didn't really understand how I could do both of those. And I remember the first time I, like, signed up for, like, the big mission that we had, you know, when we came over, Microsoft bought GitHub. I had been part of, like, working on that acquisition. So I like kind of assumed that, like, I'd have a role when we were done with it and talked to Nat, and he's like, hey, we've got GitHub Actions. And he was like, you have, like, nine months to get this to GA. And there was, like, no question of, like, can I ask for more time or not? But it's, like, basically build it and get it to GA in nine months. How do we go and do it? And I think that working with him through that was, like, pushed me to the point where I was like, wow, I can do good work faster than I ever thought that I could. And how helpful that, like, deadlines were. And him being really involved in the beginning of, like, giving coaching of, like, okay, here's how you need to think about this or do this or that. And then just seeing him, like, fade away more over time gave me, like, more confidence. But yeah, I think that project was, like, a career-defining. And there's a bunch earlier in my career, but I would say more recently that was, like, seven years ago or something, was there where it was, like, a big business outcome we had to drive, and it was, like, really hard and, like, I wasn't sure I could go do it. But, like, you know, having someone that, like, believed in you and, like, pushed you and was like, here's how you can go do it, was really helpful to me. Is seeing him engage with you in that way, the learning there is how to play the role that Nat played for you. And then you try to play that role for people on the team. Exactly. Yeah. And I think that's the thing that I try to take forward is, like, one of the things I want for anybody that comes to Vanta or works with me anywhere is, like, to feel like that they, like, whenever they leave or move on, they're like, I did best work, my best work there, and I did better than I thought I could. And I think that was the thing that Nat was able to extract out of me out of that process where it's like, I did better work than I thought I could on, like, a faster schedule than I thought I could and, like, had more impact than I thought I could. And I'm like, how do I become that for, like, everyone on my team where I'm just like, okay, great. How do, like, I inspire you, give you the clarity, give you the freedom to create your own clarity, and, like, push on dates and ask hard questions, but, like, still make it reasonable enough where it's, like, achievable. I think that's what I try to, like, bring to my teams is, like, how to play that role for them so that they walk away and it's like, yeah, there's gonna be hard days. Like, you know what I mean? It's like, there's gonna be not fun days. There's gonna be late days and everything, but I want people to walk away and just be like, damn, I did stuff that I never thought I could go do, like, when I was at Vanta. And, like, that's what I want them to, like, walk away remembering. Great place to end. Thanks for joining. Yeah, thanks for having me. It was great.