Inside Ramp, the $32B Company Where AI Agents Run Everything | Geoff Charles

If you're not using clot code this year, no matter what your role is, you're probably underperforming compared to others on the company. PMs often pride themselves on the spec, the perfect spec. They have to understand that it's actually AI that's reading the spec now versus engineers. 50% of RAMs code is built by AI. That's 50% up from 30% in December. It'll probably be 80% by March. And this is not just like a front end prototype, right? This is the real product back in front end and I have a PR and I can just submit it to the engineer team. And this is what happens when you're using a lot of data. Last year, Jeff and Tim shipped over 500 features and hit over $1 billion in revenue all with around 25 pips. So yeah, really excited to talk to Jeff today and welcome Jeff. Super excited to be here. Thanks for having me, Peter. Awesome, man. So, you know, I've worked a lot of big tech companies, but like can you give us quick overview of how ramp ships features like from ideal to launch? Yeah, I'll skip the basics and just jump into the fact that it's a crazy time right now. And the way that we are building has always been around velocity and the way that you move fast is by leveraging tools and AI is just an incredible accelerant to everything that we do. And I hope during this call that I'll be able to share a few of the ways that we've leveraged AI to accelerate to inspire folks and help amplify. Then the learnings, I also expect that a lot of the things that we're going to talk about today are going to be outdated, you know, even by the time that that you even share this this recording. So I'm excited for it. But yeah, I mean, the the pro development process, you know, hasn't dramatically changed in terms of principles, right? It's about understanding customer pain point about identifying the right solution about building the solution and then testing and iterating. And I think AI just lowered the cost of each of these sections dramatically, you know, the cost of code is basically down to almost zero apart from the tokens. And so PMs just need to be actually writing the specs for the agents rather than engineers themselves. And I think that's a that's a complete shift in terms of how we go about it. Yeah, so basically the PMs will make the will make the product first pretty much by themselves or make a prototype at least and like get some validation before doing it. Yeah, I mean, we, you know, PMs often pride themselves on like the spec, the perfect spec. And they have to understand that it's actually AI that's reading the spec now versus engineers. And so the spec itself is is basically the output of a prompt. And then the output of the spec is the product. So at the end of the day, it's just prompt a product back to prompt back to product. And yeah, we are essentially collaborating on an actual product itself in a prototype. I would even call it a prototype. It's actually a working product rather than the actual spec itself. Yeah, I always suspect that engineers don't read my specs carefully. I always try to keep my specs to like less than two pages to bigger with because you know, no one wants to read it shit. But like, yeah, the AI agent will actually really read it. So that's a good thing. Okay, so before we get to the spec though, like first you have to like you said you have to understand the customer understand the problem. And like, how do you how do you guys work with AI to figure out what to build or what the customer pain point is? Yeah, so the advantage that we have is that you know, we have we have 50,000 plus customers on ramp and growing super super fast. We have over a million end users. And so that gives us a ton of signal. We also have a ton of people on on sales on support on account management. And so those are all touch points that we can leverage to understand kind of what the problems are and what opportunities are and what we should be focusing on. The question is around like, how do you actually sift through all this noise? And that's where like a large language of models fantastic. So the first thing we invested in is what we call voice of the customer. And typically was it was it was a person that we hired that that tried to you know, do all this work themselves now it's basically an Asian. And and that agent is essentially able to sift through all our going recordings all our sales force notes all in up surveys all support tickets all in up chats. Any email that is being sent to to account managers and essentially gather all that context as well as our snowflake database and analytics and help answer any question that that product managers have around their persona. The pain points that their workflows and the gaps of their products. So happy to jump into that. But that's a huge thing that we've invested in. Yeah, do you want to do you want to give a live demo of that or like show us how that works? Let me share one version of that. So yeah, this is our course of the customer tool. And and as you can see, you can ask any question on this on this on this bot. And this bot will literally go through any type of question. So you know, for this demo, I asked you know what's feedback that we people have on our procurement product. Right. And you can you can see that the sources. So do you want me look through support tickets, chat logs sales research feature requests, etc. I said, OK, let's just go through support ticket and chat logs. It literally went through 90 days of support tickets and chat logs and identified the actual key topics that we need to focus on as well as links to the underlying assets for me to double click into. So you know purchase order manager and approval for routing chat, you know, chat understanding with ramp assist exports currency constraints. I mean, this is like this was done in, you know, from 38 to 40. So about eight minutes and something that would have taken eight days for a human to actually do across the entire volume. Yeah, I mean, this is basically like kind of part has your roadmap for you are it like has a number of support tickets and everything. It at least helps you identify with a ton of context that the problems that your customers are facing with and enables you to go deeper. So then you can you know, it's essentially a conversation, right. Imagine you have this like full blown analyst. How do you continue prompting the analyst to go deeper. So now it's like, OK, I want to go super deep on this specific problem case, bring customer quotes, bring me some like log rocket sessions, bring me, you know, customer ideas that I can go on research to create a email that I can go that I can use. Draft that in my Gmail account for me to actually automatically send to set customer to book meetings on my behalf. All of these things are basically prompts and this agent actually has all the connectivity to be able to do these things. And I love how the user faces just like a Slack channel or like I guess you can DM the agent to if you want. Yeah, 100%. We've seen like Slack being a great place to actually host these things because that's essentially what you would do with a human right you would you would slack your product operator or slack a team channel be like go do these things. So it's a very natural way of of of of doing work and personalizing these these agents as essentially your coworkers. Oh wow, OK, OK. This episode is brought to you by granola. If you're in back to back meetings, you know how much work it is to take notes live and clean them up afterwards. That's why I love granola the best AI meeting notes app in the market. Here's how I use it. granola automatically takes notes during a meeting. And I can add my own notes to after the meeting ends I use a granola recipe to extract clear takeaways and next steps in the exact format that I want. Then I can just shoot her notes directly in Slack with my colleagues or even get granola to shoot her notes automatically. Honestly, of all the AI apps that I use granola is the one that saves me the most time. Try now at granola dot AI slash Peter and use the code Peter to sign up and get three months free. granola dot AI slash Peter now back to your episode. So that's that's a quality piece that you show me what about the metrics and the data piece like how do you like to just give people access to like poll data themselves or how do you. Yeah, so there's. The space is moving very quickly so six months ago, you know, we we launched our own bot for data analysis. I'll give a quick quick quick view of this and this is now outdated and I'll tell you why. So we launched what we call ramp research. So it's funny like before you would you would ask a data analyst or you would try to do it yourself with you know looker hex is getting pretty good at like creating your prompts etc. It's still you know fairly fairly a lot of work to like get an answer to a question right and now it's like hey I have a question give me the answer. So now we have a research that essentially I mean in the use cases are insane and actually by making it easier for people to ask questions about data you actually you actually increase the number of people who actually ask questions about data and you actually become more data centric as a company. You know what's an example you know let's say that you have an an automated email campaign you want to understand the performance what's the open rate of automated emails that customers sent boom. You know ramp research understands our entire database and understand all the schemas and understands what you're trying to do and automatically like generates the actual interpretation of of set results and this is you know this is used so much and this was this was in two minutes right. Yeah by literally everyone so sales people trying to find you know what are our customers in Milwaukee support people trying to figure out like the common use cases of XYZ product marketers trying to figure out the performances of their campaigns etc. But I I shared that this was outdated in the sense that we now basically have moved to snowflake CLI plus cloud plus skills. Essentially we we've now moved to using you know cloud code we have our own database of skills that we've developed so we have a data analyst skill that essentially fully understands our database and understands how we go about approaching a data analytics problem and the best practices of that. we essentially can now prompt Cloud to say, hey, build me a full report of the performance of our procurement product and identify the top reasons why people opt in, the top blockers in our funnel, and draft with me 10 different growth ideas that we can be running. And Cloud will actually generate a full HTML report fully baked into our data that is directly actionable. Yeah, OK, so it's not just security anymore. It's actually doing work for you. That's why it's better than the thing. Yeah, I mean, at the end of the day, it's funny. You ask a question, but you have a goal. So sometimes you ask the question and you get the result. But you should just tell AI what your goal is. And you'll actually be surprised at the questions that AI can actually ask themselves to get to the goal. And have you given the entire company access to Cloud Cloud Code or is it just engineers or everybody can use it? Anyone can use it. And in fact, we'll get into this around how you actually become more data driven as a company. But if you're not using Cloud Code this year, no matter what your role is, you're probably underperforming compared to others on the company. And so it's certainly not a product for engineers. It is absolutely a product for builders. And we're talking a lot about Cloud Code right now. Opus 4546, big launches and a big movement in last three months. You just saw the anthropic $30 billion raise. But I expect the tools to continue evolving. By the time we meet next, the next 90 days, it might actually be completely different. And so it's less about forcing people to use one tool. It's about giving people full access to any tool they want to share openly what people are using and then get people to adopt, to get to the aha moment. And then-- we don't want to be dogmatic. But we want to radically empower and also have full visibility on what people are doing. Yeah, let's talk about it later, man. Because I think so many companies still don't get this. They're like, oh, what's the cost of this? What's the ROI of this? Why should I give some salesperson this thing? Just don't get it, man. We'll talk about it later. Yeah. So let's keep going. Let's keep going down the product development process. So now you have all this crazy feedback coming in. I mean, people talk about product sense. It's some mythical thing. But I think it's just like how much product feedback are you getting? How much are you embedded in the feedback loops and the data every single day? And then you kind of just develop that as a second nature kind of thing. But after you have that, how do you actually-- you mentioned that you don't actually respect anymore. How do you define the solution? Just make the product throughout the battle. Yeah. So there's the problem notification that is the actual writing of requirements. And we have our own cloud skills for that. So cloud has full access to our notion. Notion has the full context on all our personas and all the research we've done that's all automatically transcribed and aggregated. And then we have skills in cloud that is like your product-spec skill. And we've designed it so that it's a conversation-based approach. So just like you have maybe a manager or a peer reviewer on your spec, cloud will actually interact with you and ask you for clarifying questions. So for example, what's the main goal here? What do the main-- here are the trade-offs. Should we trade-off this or that? Have you thought about this? What is the intersection with that? It has all the context about what we're trying to do because it has all the other projects that we're building and all of that is a notion. And so it helps you basically refine and get to an end state. But yes, we don't really talk about the spec itself. That's just a step in the process. We talk about the actual product. And so happy to share a little bit of how fast we move in terms of prototypes and show you what we're talking about here. Yeah, yeah. Please show us the skill and everything else. Yeah, so let's go through an example of this skill. And then we'll talk about the actual how we build. So this is an example of cloud skill. Folks should be pretty well versed in this world. Yeah, so product shaping, defining the role, push for simplicity, surface trade-offs, surface questions, key definition of the problem, like looking up all the data that we have access to, do the actual research, look at different competitors, customer evidence is, it has links to all these different things. Symphasize the completion, help me shape this question. So present the synthesis, ask 20 questions around the forcing decisions, all the different principles that we have, and then relate to skills. So this is a skill that we load up. And this was actually just built by one of my PMs. Other PMs actually have their own skills. We're trying to figure out how we actually get to one strong skill as part of the evaluation process. But this is one of the examples. I want to share-- So you basically just have to be like, hey, I want to build some expansion tracking feature. This thing actually drives the conversation, right? You actually drive the conversation with you. Yeah, exactly. And then let's go into the build. So 50% of RAMS code is built by-- and that's 50% up from 30% in December. And it's not inconceivable for it to be 90% to 100%. Like we've hit coding, escape velocity, and it's a brave new world out there. The question becomes, how do you make it easy for a non-builder to engage with code? Because it's obviously pretty intimidating. So we invested a lot in building our own visual on top of any large language model and to radically accelerate how builders can build, and how even PMs can build. I mean, if you have infinite coders at your disposal, you are actually the bottleneck. And you actually need to start moving faster. So I'll give you an example. Let's say that you actually want to-- you have a lot of feedback from customers saying, hey, I need more visibility on what needs my attention. And I need to understand what's overdue, what's on track, and what's upcoming. So I need to understand my accounts payable cash flow. So all I need to do is I will go in and say, OK, please build me a report on top of this table that has four metrics. My overdue bills, my upcoming bills, 0, 30 days, 30, 90 days, and the total amount outstanding that we'll need to pay. So this is obviously a shitty spec. This is just for demo purposes. But inspect will go, and it will actually implement this product. And it will understand the task it needs to do. It'll actually plan. It'll understand the code base. You've already directed it exactly to where you actually need. And it also has access to our design component library. So I don't need to teach it to design what a metric should look like, what a module should look like, what a click should look like. It has all these components baked in. And so it's actually able to just reuse a lot of our existing code to build this thing. And I actually did this yesterday for this demo purposes. So here's where it gets to. See if this is working. Boom. So now you have on top of the bills table, your entire metrics, what's past due, what's coming up in the total amount of pay. And this took five minutes. And this is not just a front end prototype. This is the real product. This is the real product back in front end. And a lot of this is front end code, though, because I didn't need to create more end points. We already have all these end points. But inspect is able to do both front end and back end. Dude, I've been using Google AI Studio and stuff just to make prototypes. That's just pure front end code. You can't actually push through a prod. But it sounds like-- And it doesn't have context on your code base. It doesn't look the same as your product. No, I mean, here I can literally now I can go in. And I have a PR. And I can just submit it to the engineer team. And we have automatic PR review processes where a double digit percentage of our PRs are automatically approved. So PMs are shipping tons using inspect. And so are designers, so are operators, so are some extent like account managers and salespeople are also getting activated on this piece. So it's just a massive accelerant. And the number one users are also engineers. Engineers using inspect. And here's the other crazy thing about this technology that I want to share. So oftentimes you have feedback. So we love feedback. We obsess over customer feedback. We have tons of stock channels where people are just constantly posting things. It's very overwhelming once you have the number of customers that we have. This is an example of a UX channel. And basic thing, pay treasuries of product. It should probably be case-sensitive. Add inspect. In the Web Repo side, now I have changed the following sentence. PR merged. This is just one and this is a very easy thing. >> Yeah. >> But like anything, any question that you have, say you're energy or say, where do I get started? There's an escalation, a problem. Like anytime there's an escalation on ramp, AI takes the first step. It understands exactly what happened, it understands where in the code base, it creates the actual PR and oftentimes it ships it. Same thing with support tickets. Anytime there's a support ticket that comes in or someone is confused, we haven't specced basically run through that and recommend changes and have the PR up and ready for the PM or the product operator even the engineer to review and ship it. But the speed at which we can move with some of these things is like radical. >> This is AI to get the first pass. >> Yeah. First pass, everything. >> Let me push back my little bit. >> If everyone in the company is shipping this PR, how are you going to keep the product? He's like, "I keep the quality bar high." >> A lot of the PRs themselves are quality of life improvements. We also, within inspect, we have an understanding of complexity and so we do have a process by which we review things based on the sheer amount of complexity that it has. It does route to the right person based on whether this is a big change on the product side or on the engineering side, etc. But we haven't yet gone to a big problem. We also have a pretty robust release process. So once the PR is merged, we will slowly roll it out. Before any major changes happen on the product that goes to the rest of our customers, we have an on made process by which I can involve the directors of product and involved as well. >> Okay, so you have the typical first, like everyone in the company plays with it. And then if I think breaks, you could beta users to play with it, and then you'd roll out to all users? >> Yeah, exactly. So we have docked fooding, alpha is like your customers that are, as part of your research group, beta is anyone that opts into the beta tier. We have about 10% of our customer base that's in the beta tier. So you can launch very, very quickly to beta, and then you track analytics on that. And then to go to from beta to GGA, we basically require for large announcements, like not really like this naming convention or anything like that. For any large feature that is material to the customer, we basically have a reprocess that's fully automated. So because everything is in our databases, we have another bot, ramp releases, that creates a ramp release report. It pulls all the information of the context. It pulls a preview of the actual product that we can use. It pulls from our snowflake databases. The impact this feature has had, it pulls from any Slack channel, the summary of all the work that was done. And it basically synthesizes all the things that it also can do work. So to do release, you basically need a help center article that it gets written automatically. You probably need like an internal enablement of what this feature is, how to use it, why did we build it? It writes that automatically, you can also post in Slack. So yeah, that's a little bit of how we speed up that process. And when we review these larger features, are you reviewing the actual product or are you reviewing? Because a lot of companies, they just like the PM writes some sort of document, right? And then it goes through multiple rounds of reviews. And then you approve it. And then they finally go build product. But I don't think that's how I write a ramp, right? Yeah, I mean, the question is, what is my role in all of this now, right? And I think in the past, my role was, well, I'm the best at the craft, or I'm the best at understanding what customers want, or I'm the best at understanding the data. And that's no longer true. Like you have a super intelligent platform that you can leverage. So yes, I will try my best to look at all the customer feedback, make sure that this is actually meeting the customer feedback. I will look at the metrics and call bullshit on like this is not good enough, or this is not big enough. That's something that is fairly subjective. I will go into the product and test it out and play with it and like really just hone in on like what's working, what's not working. But I think the higher level job for leaders now is based on your feedback, what broke down in the in the process? Right. So if you caught a poor user experience, what broke down? What prompt failed? What skill failed? What design system failed? Because giving feedback to the person and so that it can just fix it, that's a one time banding. What you want to do is you want to figure out within the process what broke down and fixed that process. So the next time you never have that feedback again, like a classic example for me is like, I've told the team 10 times. The call to action needs to be above the fold. That's what I told you. You want to just six years of A/B testing, you want to increase conversion? It's a big button that's above the fold. That's it. And I've said that like 10 times, maybe 100 times. But now it's part of our design, create process, which is a fully automated process in and of itself. And so before it gets to me, you know, within our Figma prototypes, those core concepts are actually fully integrated. OK, got it. OK, so you don't have to say the same thing over again. You can provide a little bit of high level of feedback or something. Yeah. My job is to automate my job. And all our jobs is to automate our jobs. Yeah, we can talk about what happens next. But yeah. And how about the other thing that sucks up a lot of time is just annual planning process of like, I spent like a month to figure out we're going to build for the year or like for the next three, three years. Like, how do you guys manage that process? Or is there even like a-- like how far do you go? How far are you guys look on this stuff? Honestly, three months. OK. We can only predict within three months now. And by the way, within three months, you can do what you can do in three years. Now, so like three months is actually a really long time. Yeah. You know, planning for me is-- I think there's actually like three main objectives to planning. One is actually aligning on strategy, which is much, much more important. Like, what problems are you focused on? What are problems you're not focused on? And which customer segments are you going after? And how are you thinking that we're going to win long term? Like, what is the end state for this thing? So it's about trade-offs. And I think like the conversation should really be about trade-offs. The second thing that the planning is good for is just having some level of commitment from the teams, right? Some level of accountability. And the third is to have some baseline for sales to know what's coming. For them, when they talk to a customer and the customer asks, OK, like this is great, but I have a lot more needs when it comes to our international exposure. And the sales team needs some basic assets. And so that's the third kind of pillar. And that also is like fairly automated. So once the team does their backlog and their plan in notion, we have an automatic process that creates one pageers and then it creates slides and content for the sales organization within our own branding guidelines. And then the sales team can essentially just look at a higher level of your roadmap to be able to self-effectively guess it. Wow, OK. And then you have all these vision and how we're going to win stuff. Obviously, AI can read it and if something changes, you can just ask AI to update it. Is that the hard work? I mean, what I ask AI to do is to synthesize information. Like a lot of leadership time is about helicoptering between the nitty-gritty problems and then to higher level like strategy and roadmap and making sure that every level of the organization understands information at the bottom and information at the top. Like how you communicate to the CEO and the board is very different than how you communicate to the director is very different to how you communicate with the teams. And that LLMs are incredibly good at because so the translation layer, right, when I'm on an all-hands meeting versus when I'm at a team meeting versus when I'm in the board room, very, very different. And so I waste a lot less time on those things. Got it. Great. Let's get to the key question then. I mean, you just mentioned that your job is to automate your job and I'm sure all your PMs feel the same way. And so what's going to happen to the PM function? Do you think it's getting over? Yeah. What's going on? It's funny. I was surprised by once you automate code, a lot of people concluded that PMs are over for PMs. And I thought to myself, it's over for the engineer. For most engineers, maybe it's like a lot of engineers who are like, I'm going to be a PM now because the engineering function has changed a lot. Now obviously there's a ton of value for engineers because I think an engineer now is managing hundreds of thousands of agents and they can actually scale their impact. But let's go back to the PM role. Like a lot of what, there's a lot of bad PMs out there or badly trained PMs. I think that the way we've trained PMs in the past has been really, really bad. And we've trained them on stakeholder management. We've trained them on prioritization. We've trained on communication. We've trained them on frameworks. And those are all outdated because code is free. And so like all that matters now is, are we going the right direction? How fast can we go? And how do we remove bottlenecks and how do we build a system by which like we can accelerate? And to do that I think PMs need to really rethink their skills. So like a lot of PMs join product management because it's a safe job. They might not be good enough at the engineering task. They might not be good enough at design tasks, but they're really good at the consultant and I'm an ex consultant. That's why I joined the function. I understand that the customer, I can communicate to engineers and I can really, I can somewhat facilitate decision. make it. The downside is that if you're a risk of a versus PM, you're not going to change your way. So I still see, you know, very high performing PMs who don't get it, who haven't yet adopted these these core skills, who haven't changed the way that they're working, because it's worked for them so far in their career, they've been successful because of it. That is the biggest dangers I'm seeing. And so I think that the role of the PM is going to shift, and I think it's going to shift in two directions. Things are going to become much more builders, right, because code is free. So just like I showed like a product, right, that I basically built in five minutes. It's going to require then like the iteration from the product very, very quickly. And so I think I think the craft and the building is going to be like really, really essential versus the spec. Like you no longer have to write the spec anymore. You need to actually like be in the product itself. Now an engineer, a great product engineer can do that and a great product designer can do that. The other path for product is the business side. So what engineers are and designers often lack is an understanding of the context in which the business operates and what actually matters. And how we're going to win long term. So they're really, really good. Maybe they really get a building, really good products. And so give them that. And then the product team should be focused on like, okay, but now that we have this really good product, like how are we competing, how are we positioning, how are distributing, how are we monetizing, how are we actually using this to win and drive enterprise value. And I think that, you know, even looking at opening on a topic, like the, it's a decision of strategy. Yeah. They have different strategies. And that's actually where the PM should be, should be really, really focused is the underlying way that we're going to win and playing the GM mindset because because they're going to have a ton of builders that can, that can build great products that can iterate on customer feedback that have all the context. You built that system. So now focus on like what actually no one can do, which is to make sure that the product that you're building is going to have insane amount of value in the market and insane value of my free business. And like a lot of PMs are just like stuck, like you mentioned, they're stuck in like cross-functional line and meetings all day, like back to back. So like, and I think it's like a company culture kind of thing, too, right? Like do you make sure your PMs actually have time to build or is this sort of like, do they have to get a line of 10 people to ship anything? No, it doesn't seem like that's the case. Yeah. No, I mean, we've designed the organization so that we do not have committees and we do not have sign-offs. You just need to prove that you've added value and then you can go for the races. I will say that like it's, it's actually really, really important for PMs to carve out time to build. And I say this not just PMs, but like managers. I think that it's a really tough time to be a manager right now because you're managing a team whose skill set needs to change and you might not actually have that skill set. So I think that right now, like going back to IC mode is paramount. And I've done this for myself where I say like, hey guys, like I'm going to be way less meetings. I'm going to be way less than one-on-ones. And I'm going to be like, I'm just going to be adopting AI tools. I'm going to be building and vibe coding and understanding what's working, what's not working. So that I can be become more educated because this is just the beginning. I mean, the sheer amount of changes that happen over the last like three months is profound. And I think if you're stuck in meetings, you're not going to be effective. So definitely creating space for work. And honestly, you know, that's also where nice and weekends come in, which is like, this is the year that like, you need to really prioritize learning and growth because yeah, no one's going to do that for you. So yeah, it's going to be a well-dried. And if you're doing the old way, like your company's going to die basically, right? If you're doing the waterfall and all this kind of stuff, it's not going to survive. Yeah. A skip to talking about companies that are watching this, they want to become AI native, like ramp, like how you guys operate, like how do you go about like doing like, you know, building systems and that kind of stuff? Yeah. So there isn't like one right way, but I'll share kind of what we've done. And we've kind of like built a framework around this. So we think about like being AI proficient in like multiple levels. Okay. The bottom level is like people who sometimes use chat GPT. Right. We'll call them like the L0. Okay. The level one is like people who build their custom GPTs. Maybe they built a notion agent. Maybe they've built, they've used like log code to like do some of these things. The level level two is people who are actually like fairly proficient. They they are they have been able to build an app that that automates part of their job. They have been able to commit code or feedback to other people's work. And then level three is like the fundamental like systems builders. Okay. And our job is to get everyone in the organization up the ladder. And the way we do that is as follows. The people who are still now zero, they they will most likely not be at the company because the fact is like you can you can you can tell them as much as possible. If you're not a self-starter and you don't have that growth mindset, like it's going to be very, very hard to train to train you out. So so that's the L0. The L1s to go L2s and L2s and L3s and L3s like basically like influence and the rest of the organization. And the way we do that is we have a lot of public channels around people sharing what they built. We made it really, really easy for anyone to adopt these things. So we've removed any constraints around access around tokens around budgets. We've we have like the setup of those tools are are are extremely well done. So you access to all the different MCPs. You have access to all the different skills. We even have like an eternal repository of skills that people are deploying to you can pull from those. And then we have you know a lot of culture around you know in all hands around like showcasing non builders doing things. You know our finance team building their own treasure management system. Our legal team you know doing contract reviews. Our marketing teams automating like website creation to get people inspired. And then we have office hours that that people can join to to ask any questions to get set up. We have designated experts that people can just ping and like their entire job is to get to evangelize to get you set up to get you comfortable to get you going. Those are like some of the principles there. And then we we and then the other piece is just like you know hiring a performance management. So on the hiring front we now have an absolute requirement for anyone that joins the company to be somewhat proficient for these tools. This just absolutely no excuses. And in the interview process will have basically a dedicated session for this where like they will either I mean for the product team I literally have a session where you're going to build up you're going to build a product like you're going to show me a product that you built. And you can tell me exactly why you built in how you built in how it works. Like it is a full blown prototype. And then we also track usage of AI across the company. So you know we have we've I've coded this product even within the team where we can see every other company and their full usage of tokens across notion AI, chat GPT, Cloud code, Cloud co-worker are inspect tools are any of the internal apps. And we can see kind of like who is actually pushing the bar to amplify and who's not and who we need to intervene on. Do you worry about like cost of running out of control or like the RRI is so clear that there's no it's just fucking just give her one access. Let them do it. Yeah. I mean I haven't done the RRI around like if you let's say you have a person who's who has $100,000 salary. How many how many tokens should this person use? Yeah. And there's debates right now around you know productivity versus just like noise and you know I'm actually need these things. I think right now we need to invest the budget for people to discover and if we are not as efficient in that spend that's okay. That's our competitive advantage. That's why we raised money. That's why we have a pretty good war chest. Yeah. But I can safely say that you know we pair employees a lot of money and the token consumption per employee is not even close to double digits. And I think it's not unreasonable to think that it should be higher than your salary. Because like if you have agents that that are able to do 10 times more work than you then why would you not pay them twice as much as you. And so I think that's like the way that we should be really framing it. But but yeah I would say like we're not really worried about costs. We're worried. We're mainly worried around we have like the next X months or X years where AI has not yet fully one shot at a ramp platform. And we need to use that to our competitive advantage to move as fast as possible. Yeah. I feel like a lot of the internal tools that you show me are also really good for ramp cost customers. You can just like like that available for ramp cost. 100% okay. Last question man. So if I'm a PM or builder like how should I think about my career these days like the old time the latter to VP or whatever like is that still going to work or how should I think about being employable still. I would say I think that the where you should be optimizing is not management. It is being the best builder in the world. I would say that management is probably dead. There's always going to be value in someone giving you feedback and coaching and and and and being you advocate and being a team leader. But now is not the time to build that skill set. Now is the time to like be very very proficient in this new technology and to radically improve the the way that you use it. And so I would say for for all the PMs out there you know get really embedded in these tools. And that's why engineers are so good at at you know understand What it is. people love because they live and breed it. Like that's the first knowledge work that has been mostly automated with coding engines. But it's coming for everyone else. I mean, it's going to come for PMs, it's going to come for designers, it's going to come for any white collar job. And so I would say just get very, very proficient in using these tools. And ultimately, the career is about impact. And right now, the impact that you can have is to ship great products faster and move more metrics for customers into the business. And so create a lot of space to learn these things and have the beginner's mindset, the humility, to understand that the way you're doing things is not the best way. This is like a bum. And I think my job as a leader is just to get people to get to that aha moment. And even my brightest PMs, I had to sit down with them and say, we're going to go through this workflow together. What have you done today? And I will show you a new way of doing it. And once you get that aha moment, that red pill, there's no coming back. You're like, oh, I get it now. And it'll also make you a better builder, because the software you're building, if you're in B2B, and even in B2C, it is going to look radically different than what is this today. I mean, fundamentally software is dead. It's all going to be co-workers. And if you haven't used co-workers in your own job, you don't understand how-- that actually might look like your product a lot more than you think. So you don't have the process. Yeah. That's exactly right. Ramp itself is going to look much more like a finance co-worker than it does tables and charts and workflows. Yeah, I find-- it's all like-- I'll be using OpenClaw. I think it's all like CLIs. And the one who wants to touch buttons in any way is just like-- let me talk to my co-worker and give him to do stuff for me. So that's basically it. Yeah. Cool. And how do you build one of those great co-workers? Domain level expertise is another one. I think that in the past, it was like-- when we talk to customers, I'm going to kind of understand the requirements and kind of build a product for them to do their job. But if you're doing the job of your customers, so that they can do other things, you need to actually be an expert. Or you need to build a system by which you can ingest that expertise. So accounting. You can build an accounting workflow where they have to go and code things. But if you're actually going to code on behalf of the accounted, you need to deeply understand that the philosophy or be able to extract that knowledge. Like how do you download CPA and all the best practices and actually bake that into your product? It's a very different way of thinking, where fundamentally a login in your product in the future I think is going to be a failure. And I think that's also how we think about it. We track the amount of time you spend in RAM and how we can actually reduce that time as much as possible. Which is, by the way, the opposite of how many pms are trained, the Facebook and Netflix, the fangs of the world that are mainly advertising businesses, it is the opposite. And I think it is going to be reckoning for sure. But also a very exciting time. I mean, I think it's very scary. And a lot of people are alarmist. And everyone should be paranoid. But man, it's an amazing time to be built right now, and especially a product manager where you have taste and vision. The time it takes to go from your taste and vision to a product is shorter than ever. And I think it's a really, really exciting time to be a builder here. Yeah. And I think another thing you mentioned is just setting up systems to delegate all the bullshit work to AI, right? So you can focus on stuff that you actually enjoy doing. That's a key part of it. So yeah. All right, Jeff. Well, I mean, thanks for being inspiration, man. I think hopefully-- well, hopefully every company can learn how to opt up or like, rap. Yeah. We're just getting started. There's also a lot of things that we're not doing well. That other companies are doing super, super well. I think part of me going on this talk is not to share that we have-- that we all have figured out. Most of the things that you saw here are things that we built in the last months. So excited to keep the conversation going. Excited to continue learning. And really a privilege to be your say. Thanks a lot for grabbing me. Yeah. Thanks, Jeff.