Ramp's Product Playbook: How To Hire Product Teams

Welcome

Yeah. Absolutely. So I I’ve always been, like, very short term focused in my career, so I just I follow a lot of the energy, and I think that’s gonna be a theme throughout this this chat. The first, like, energy was management consulting out of college. So it’s all the hype around just how to think, how to structure, how to sell. Then I got kind of bored of PowerPoint presentations, so I I I wanted to get close to the metal in terms of big data. I’d and I joined a big data analytics company.

And that’s where I got my first foray into product, and I think that the way I did that was getting super close to the customer and understanding the customer pain points, and then having great relationship with the with the tech team and understanding, like, how do we build technology to solve those pain points? And I think the product team kinda came running for there.

I think you kinda have to walk in their shoes for a full day. Like, what do they listen to? Go listen to that. What conferences do they go to? Go to that conference. What are their pain? What are their aspirations? What does success look like in their role? What is their degree? What do they learn? What is the their habits? I spend a lot of time with customers and then it’s all about just like asking the right questions. Oftentimes like product managers, they have an idea and they they ask the question to validate their idea, and it’s actually the wrong idea.

And so just ask them like, what does success look like here? What is the worst part of your job? What takes a lot of your time? And and just continue digging in and digging in and digging in. So and then lastly, when you do have a product, sit down next to them or have them share their screen and just watch them do work in your product, and you will see how painful your product is and how many different ways you can improve that product. Oftentimes just PMs spend way too much time in the office and I think that’s just a huge downside, for your team.

Figure out like what gets you excited. You do have energy throughout the day, Like, what is that? Right? And for me, was it was all about building great products and seeing metrics move and and and waiting. Like, I I think I’m a very competitive person. And so figure out like the right industries. For me, like when I think about Ramp for example, it’s like probably the most competitive space. It is extremely metrics driven. I mean, everything is metrics to the point of whether, you know, it’s our risk or fraud losses or conversion or net retention or interchange margins and find the industry that will tick that box for you.

Also, note like what lowers your energy throughout the day. Like what really bothers you. You know, is it like large meetings? Is it bureaucracy? That was for me for sure. And so find the industries of the companies that don’t like meetings, that don’t like bureaucracy. I think at the very least, you can actually cut down a lot of things and that makes this the selection process a bit easier.

Oh, man. So many things. I think that we we did a lot of things right at Ramp. I think the things that we got wrong were always around hiring, and hiring is probably the hardest thing to to get right. But it’s especially hard when you don’t know what you actually need. The biggest mistakes were probably on go to market earlier on. You know, we we hired people who had seen success in growth, and it’s hard to disambiguate what was your role in that growth versus the company, and also what was the go to market motion of that company compared to the go to market motion that we strive for.

And so, you know, growth means a lot of different things. Is it performance marketing? Is it brand? Is it sales? Is it outbound? Is it customer success? Is it account management? Is it product led growth? There’s a lot of different combinations, and so, you know, people hire their first go to market leaders, and I’m sure you have another growth podcast that we could chat through. They often make a lot of mistakes there. It it took us a while to figure out the right combination, especially because, you know, Ramp is is both sales driven and product driven and marketing driven, and we have, like, you know, what we call product led sales.

I would say like be super clear on the strategy and then hire more more IC level people who can show you the right path and test whether that strategy is the right strategy for you.

It depends on how senior the person is. So for ICPMs on my team, I basically place them in teams that are high performing, and then we immediately see whether they are at the bar. So you you take basically something that is fixed. You add a variable. And if anything changes, it’s the variable that you added. Right? So that’s one way of just, like, being able to manage performance fairly well. It’s harder for senior people who you hire to also hire additional folks. And so that’s maybe, like, where I would say, like, don’t do that.

Don’t hire executives that will then hire people under them because that obfuscates a lot of their performance. And so be clear to the leaders that you’re hiring, like, you’re not gonna have that account for at least like six months. You’re gonna have to do the job, and that’s a really good way to actually assess performance. I think within three months, you should actually be able to say and figure out like is this person gonna hit it out of the park or is this person not gonna work out.

Stage. Anytime. I I think the category is not that relevant. You know, I come from more consumer than than b to b, and I think that’s actually an advantage because you’re focusing on metrics, you’re focusing on conversion, you’re focusing on models like lead scoring, elite routing, all the things that like b to b companies have done really poor job on. I think the stage is actually much more important. Oftentimes, if if you hire someone from a larger company, they come in and they they just get shocked like, where are all my resources?

Like, I’ve never been used to doing the work myself. Like, what do you mean I don’t have like 16 people just like supporting this one thing? And so I would much rather actually hire people who are coming from companies that are a bit more scrappy in terms of resources that have gotten their hands dirty, even if they come from a different space. It’s not rocket science. B to B SaaS is not rocket science.

So, I mean, in the early stage of of Ramp, you know, we were about 10 ish folks and we were just throwing everything at the wall to figure out like what makes people tick. And I think the advice there is products should sit with sales and should be in every single sales demo and every single on-site and use the sales process as a way to identify pain points.

Yes. The founder or the first product manager should be selling the first 100 customers. Like, absolutely. And that’s because the salesperson is the master of process of discovery and of trying to close, but they don’t deeply understand the product or even the pain points yet. Mean, they’re not enabled. There’s no product marketing team. They just really don’t understand those things. And so the the summary there is use the sales process as discovery. Sit with, you know, if it’s a larger customer, the CEO should definitely be there and dig into what’s working in the demo, what’s not working in the demo.

Where are their eyes opening up versus, you know, they’re looking away? What are the questions that they’re asking? And then basically just use the demo as like a prototype to your product and continue like that’s essentially your product at this stage. It’s the demo instance and the story you can tell. And then the things that they actually identify as like, oh, this is curious or like I do have a pain point there. Basically like run that back to your scrum teams, build a prototype or build a product very quickly and then the next demo, show them that you actually incorporate their feedback.

And that I think is also the the piece that people miss is you actually should be like a bit more professional services oriented as a product team earlier on than like saying like, oh, I have this vision. I’m gonna build this perfect thing. Like, if you actually find one or two design partners and you just build for them, they will love you way more than, you know, the the best in class SaaS pride that’s already in the market.

Look, I think I think it took us a while a while to get right, a while to to get the pride that really wowed them. I think what we did is we were extremely aggressive in terms of making it super easy for them to switch. And what I meant by that is like we literally had teams say, give me your old credit cards. I will log in to all of your other software, and I will switch your cards for you. I will sit with your finance team for a full day, and I would get them set sort of, like, basically give them no reason to say no.

The practice free. It’s better, and you’re not gonna have to lift a finger. And so just, be relentless there. That’d be my advice.

Yes.

So I’ve I’ve iterated a lot in terms of just product development processes, and and this is the process that I’ve I’ve come to love. I’ll be super tactical. So you have a Monday leads meeting where you talk about what is the actual plan for the next two weeks, and you alternate between tactical and strategic there. So one week, it’s like the tactical two weeks, and then the week in between, it’s the strategic around the next, like, couple months. That’s just the leads. So you align with leads, product engineering design leads as to what you need to achieve.

On the Tuesday morning, you have a team wide, like, scrum meeting, and that basically is your five to 10 people, 10 max, where you’re actually saying, we decided this is what we’re going to do, and that the decision has been made. And it’s all about people signing up for work. So don’t assign, but have people sign up. Hey, Joe. Here are our goals. What do you want to achieve and help us achieve in the next two weeks? And out of that meeting, you basically come back with the clear assignment of roles and responsibilities and then any additional, like, deep dives that people need to have in terms of specs or designs or decisions, etcetera.

There are no other meetings that are recurring in the entire product development process. Those are the only two one hour meetings that happen. Everything else is scheduled if there is a blocker or if there’s a question or if there is a a brainstorming session, etcetera. So every other meeting is extremely gold and extremely well run.

If you believe in empowerment, then then a lot of it has to come from the individuals. And I think that you have kind of a social force where people are looking at their peers and their peers like, I could do that. I could do that. I could do that. And they want to do more because their manager’s in the room. Right? So I think it’s a really important culture to have people sign up and take on take on more than to actually push these things down.

And so, we basically have engineers that sign up and then we post publicly, here are our goals and here’s who’s doing what. And so the scoreboard is super, super clear and then before the the start of the next sprint, we basically go and say, this is what we wanted to achieve. What have you achieved? And the individual say, I achieved this or I didn’t. Here’s why. And that’s essentially the scoreboard. So we also just do a lot of gratitude, meaning like, how has someone helped you achieve your goal?

So we can continue fostering a culture of of helping each other as well.

I think that people tend to put too much emphasis on like the task, the system, the meetings, and not enough on just like what do you need to achieve those goals. And product managers oftentimes become project managers where they’ll like do the work on behalf of the engineers that just like simply don’t want to do some of the work that that we’re putting them on them. What I mean by that is don’t write tickets on behalf of people. Like, let them write their own tickets. Give them the goal, not necessarily the task.

Have them manage up. If you’re constantly asking them for updates or you’re constantly asking them like what’s blocking them, you’re disempowering them and you’re emphasizing a culture of you project managing their work. Instead, every single person at Ramp owns their work and manages their own project and they’re managing up. This is the risk that I have. This is the question that I have. This is the key decision that I need you to make. And that just creates a culture of just empowerment and velocity. And so don’t treat your employees like babies because they will become babies or you will hire babies or you will retain babies.

Instead, like treat them like founders themselves. What do you do if they don’t set ambitious

If you have a core team that’s ambitious and you have one person in the team that’s not as ambitious as that team, you need to part ways with that person because it briskly lowers the bar and everyone becomes demotivated. It’s fairly easy to see as long as your core initial team is ambitious. And again, this goes back to, like, add one variable at a time into that team so that you can actually understand what are the drivers of headwinds.

Every quarter, we take a step back, and we look at, okay. Like, what did we achieve in the last three months? We basically have off sites per pod that are, like, customer centric oriented. And we ask ourselves, like, okay. Like, what does incredible look like in the next three months? Where do we wanna be at that time frame? That is a great moment to reenergize teams so they don’t, like, burn out on, like, just this two weeks sprint cadence. And they also reflect on what they could have done better.

You know, what are the changes in the process? What are the changes in terms of people? What are the changes in terms of strategy? So we do take a step back every three months, and that’s a great refresher to then revitalize the team in the next few months.

I mean, when you’re a bigger company, right, you now have a a customer support team. You have a sales team and account management team. You have customers that are not yet sold on your product today that need to understand the roadmap to be sold on your product tomorrow. And so you need to have a bit more of a longer term focus or a longer term goal and plan to make sure that you can address those needs. At that stage, you have a a bigger marketing team, and that marketing team needs ammunition to have very strong market moments.

And those moments can’t be like one feature here, one feature there, etcetera. They need to be an aggregation of features and value propositions to then go in the market and tell a differentiated story. That’s where you basically just need to like arm them with, hey, here’s our plan over the next, call it, you know, six months, and here’s how we can tell a story within this product roadmap that is anchored on these like large market moments so that you can actually go live and you can train, you know, the press team on how to tell the story to the press, video content and case studies and landing pages and conferences, whatever that is.

And so that’s now more valuable. You couldn’t afford to do that earlier on. You just have to to have an existential crisis and ship as as quickly as you can. So that’s really the value of of why we plan a bit a bit longer term.

We we have a culture at Ramp where even if you’re not in the team, you can advise and leave comments and suggestions to other teams. And we build in the open. What I mean by that is like, if you’re a salesperson, you can go into my product spec and leave a comment on my product spec with your opinion. That is welcome. And same same thing if a product marketer is designing a great landing page. You can have an engineer comment on that landing page and be like, this value prop doesn’t make sense to me.

What that does is it gives everyone visibility on what everyone is working on. So there’s trust because oftentimes trust decreases when you don’t know what the other person is doing. It also just lets people be empowered in terms of giving feedback and that slows some things down or it’s like a bit harder to manage. The long term, I think it like leads to like much better craft. And so, yeah, the engineers understand end to end how to launch the product as well as the product marketer.

Product marketers have full access to all the decisions we’re making on the product. They sit down with us in terms of user research, and that’s important so that they can actually craft the go to market motion. So there’s always gonna be attention, but that tension is, like, greatly mitigated if you have shared goals. Like, we want this product to be successful in the market and trust within the teams through visibility.

You can you empower the decision maker. So I actually think that, like, more data does not slow you down. I’m inundated with data. I’ll I’ll tell you, we have Slack channels with every single negative feedback we get from customers. Every time we lose a deal, there’s a Slack or, like, why did we lose a deal? Who did we lose it to? And why you know, was it a product feature? Was it a timing feature? Was it a pricing feature? Whatever it is. There’s so much data that’s happening, and in specs, there’s so many comments.

I think that that makes you better at making the decision. I think what you need to do though is you need to empower the person to make the decision. And when the decision is made, you need to commit even if you disagree, and you need to align on the outcomes. So if a PM gets 16, you know, thousand different, like, comments on the doc, you read all of them, you say, I’m still going with this decision, then you commit. You hold that PM accountable to that outcome.

If the outcome works, you can reflect back on those comments, and you can change your mind. Or if the outcome didn’t work, the PM should reflect back on the feedback that were given and we’ll have a postmortem on it. So I don’t think more data slows you down. The culture can’t be like, I just wanna share my opinion because I care about my opinion. The culture should be, I wanna share my opinion because I care about the outcome.

So when you’re pre product market fit, you know, it’s very easy to try to build systems that have extremely long shelf life. And I think you should only do that if they are very high confidence, meaning like you know that this system is gonna be alive for a very long time and very high risk, meaning if the system doesn’t work, we’re screwed. The rest, I think you should just understand that the shelf life is probably twelve to to eighteen months and be okay with it. Once you find that product market fit, then your goal is basically scaling that as well as adding new products.

And so as you go multi product, you just need to ask yourself, what can I reuse from the first product in terms of the second product? Because you should typically go after a second product that has, you know, economies of scale in terms of systems you’ve already built. So an example for that for us was our first product was cards. Our second product was expense management. It was a reimbursement. Now, when you think about a reimbursement, it’s fairly simple. There’s an employee identity, which we already have.

There is a form and a request flow, which we already have. There’s an approval system, which we already had. And there’s a money movement system. We had a money movement system between the customer and Ramp when they paid us back for the card. We just had to switch that money missed system from the customer to their employees. And so that that was reusability. So then we went back to all those systems and we thought, okay, like how do we leverage those systems or rebuild them in a multi tenant or multi use case fashion?

And then the important part there is like just thinking slightly ahead. Okay, like, but what comes next after that? Like, oh, well, comes next after that? Probably like b to b payments. And so we rebuild those systems after the first product to sustain the next product and potentially the product after that.

So I think that for the majority of the company, you need to be, like, single product oriented for a very long time until you get to a really good market share. But as a tech team, you actually need to have an R and D department that is constantly shipping new features and new products. And so I know there’s a disconnect there, but like here’s what I mean by that. I think that tech after you find product market fit, the the equation really is go to market.

The equation really is like marketing, your brand, your distribution, your sales engine, your monetization engine, etcetera. That is a lot less on the the tech team than it is on the good market team. So when you’re spinning up a new product after that first product, do not distract the good market team until you find product market fit. That’s like really important. Like, what you don’t wanna do is like ask for a bunch of marketing resources and sales resources. When you don’t even have product market fit on your second product, keep that good market team extremely focused.

Keep a small small team in the tech organizations building the next product. Once growth kinda slows down a little bit on your first product and the entire executive team’s like, my god, what’s gonna be our next horizon? You have it right there. You have it in your back pocket saying, boom, this product is actually ready to go to market and it’ll help us continue that exponential function.

What we typically do is we start at the bottom of the market with product led growth on those products. And so there is actually no, like, sales and very little marketing. Use that to prove the business case to the sales team, and we continue iterating on the product until we can get to, like, more mid market sales driven segments. And then at that point, we can go to the sales team and say, here’s the positioning that worked, and we we leverage product marketing as well. Here’s the positioning that worked.

Here is the actual use case. Here’s the ICP and use of potential revenue. We basically train a smaller team within the go to market team, a smaller sales team and account management team to try to cross sell those products or try to sell those products, and then we scale from there. So that’s a little bit of how we’ve done it.

Yeah. I don’t think it matters. For larger companies, when you’re doing a product release, it’s a lot more about, like, marketing to existing customers and marketing to the market. But at Ramp, even with 15,000 customers, our marketing is actually geared towards the market, and the market doesn’t even know what our product is. I think it’s actually important to separate these two things out. When you go live with a new product, just go as loud as you can in the market, and by the time that they get to, okay, I actually wanna use Ramp, I’m sold and I activate, the product will actually be much better than the actual product that we built and market to your customers differently than to the market.

That your customers should already be probably on a beta before you even announce it to the market. So that’s I think the advantage here is you have a huge TAM and you can separate your your marketing strategy that way.

Yeah. So OKRA is just a way to measure performance. Right? And this is objective and then and then key result. The the reason why I I don’t like the framework is that it doesn’t actually talk about strategy. It just gives a goal and then it just tells the team like go hit this goal, but there’s no thinking on the exec level around like how we can actually achieve that goal and why that goal is important. And you spend a lot more time like debating what’s the right metric.

Is this like achievable? Is this not? And then you have teams trying to, you know, sand back some of the metrics so that they can look good to the rest of the organization. It becomes like a very political game when in fact what you should be talking about on a quarterly planning perspective, what truly matters for our business, how do we actually achieve that thing, which is the strategy. And so I’ll give an example. Like, it’ll be very easy for me to tell the product team, like, hit x dollars of revenue in this segment.

Then And we can debate, oh my gosh. Should it be should be x? Should it be y? But, like, we don’t know. There’s so many things we don’t know, and we’re we’re so immature as a business still, you know, even with a ton of revenue. And so instead, I say, well, okay. The strategy is is cash flow conversion. And so we wanna build, we wanna ship a product that solves that problem in three months and get 10 customers. And that’s much more specific, and that’s actually a a delineation of product strategy, and that should be the goal.

And at that point, it’s much more clear what we need to get done, and there’s a lot less debate around the goals themselves.

So there’s I think there’s like leading and lagging metrics. Right? You wanna win on your lagging metric, but you really wanna focus on that leading metric. I think setting goals on lagging metrics like revenue, market share, NPS, that is not gonna be clear to a team on how to actually change those metrics. I actually much rather focus on the leading metrics, which is like how many customers did we get on this new product? How many features did we ship in this specific segment? Those are much more leading rather than the the lagging ones, which is which is revenue.

The question really is around metric setting is, like, can I, as a team in a two week sprint, move this metric? And if I can, it’s a great metric. If I can’t, it shouldn’t be part of really our goals. And so oftentimes, you have such a lagging indicator. It’s like the the S and P 500 stock price. It’s like you’re you’re not gonna move that in a quarter. Quarterly earning calls of publicly traded companies, that’s the outcome of, like, the work that happened a year ago.

And so you’re not gonna goal the team on that because they’re they’re gonna work super hard. Gonna see the stock price change, and they’re gonna be like, oh my god. Like, the work I’m doing is not valuable. But, no, that was the work you did twelve months ago. And so I agree with you in terms of value based metrics, but I actually care a lot more about the actual correlation with what I’m doing today and the metric that I’m holding my team accountable for.

Each team should probably have one, maybe two goals. And then as as a tech organization or as a as a pride team, we try to synthesize those and aggregate those into, like, three, maybe four. A good goal is it’s clear, it’s achievable, it’s motivational. Mean, everyone everyone kinda knows this. The the perfect example is, like, you know, putting a man on the moon by by this date. That’s that’s a great goal to have. There’s an outcome, it’s measurable, it’s motivational.

make mistakes with goals? If you see yourself repeating the same goal for, like, many quarters at a time, it’s not motivating. And so something that’s more like a vision or mission statement should not be a goal.

So our our hypothesis from the start was that finance teams were equipped with tools that did not work for them and then incentivized them to spend much more time and spend too much money. And so our hypothesis was how do we give a product and a solution to finance teams that help them spend much less time managing expenses and made the right decisions for their business in terms of spending less. That hypothesis was kind of a positioning statement around, like, the card that helps companies spend less, which was a great anti positioning against the the status quo.

Do you think startups get hypotheses right? I think oftentimes PM are enamored with their solution, and they’re not actually good at defining the hypothesis that led them to that solution. They just ship this product and the product doesn’t work, and then they have to go back and say, like, why didn’t it work? And then, you know, they’ll have a bunch of excuses. The design isn’t good. The marketing isn’t good. The sales team isn’t selling it. The engineering team cuts scope, whatever it is. But a lot of times, the reason why the product didn’t work is because your hypothesis was wrong.

And it’s hard to actually reflect if you didn’t write down that hypothesis ahead of time. What is your belief about the customer, the problem, the solution that will make this successful? And if you write that out, then you can actually reflect back and and learn a lot more. And you can also just be hypothesis driven in the sense of like, I’m not a bad PM because I had the wrong hypothesis. I had the hypothesis I learned and I tested. You’re a bad PM if you don’t learn from your failures and you blame others.

So take responsibility for the hypothesis that you made and then make sure that you’re winning more often than not.

A lot of documentation. Blame, like, no blame. I think it’s actually, like, you need to have curiosity. You need to engage with with questions. You need to have a a fairly cross functional team that everyone that’s affected be present so that you build trust with those teams oftentimes. You know, when you screw up, it’s not the engineering team that is affected. It’s the customer service team. It’s the the account manager that had to apologize to this to the customer. Bring those teams together, share the data, be upfront with the facts, then open up discussions around, like, what could we do better?

What are some of the ideas or hypotheses for what we could do better? And then take action items that are very clear and timely to address those things so that the postmortem doesn’t happen again. I think that’s the most important thing is, like, screwing up once, it will happen. We will screw up all over the place, and we have. Screwing up twice on the same problem cannot happen. Product reviews, remote versus in person, how do they differ? Oftentimes, trust is eroded if you don’t actually meet in person.

So we do have a strong culture of flying people into the New York office and and making sure people have time together. And so if you have that, then, like, there’s largely no difference between remote work and in person jam sessions. But if you actually haven’t seen the second half of someone’s body, it’s harder to actually trust them, and it’s harder to to engage with a ton of trust.

The reality is that it’s very hard for large companies to actually innovate. And you even see this with, like, when you’re launching a second product to your in your company. It’s it’s it’s hard. And you’re just you’re a small company, and it’s still hard. I mean, think about, like, if you have a huge company and a huge go to market engine and you’re trying to launch a new product, like, it becomes exponentially harder. And why is that? You have board expectations, which are very short term focused.

You have a go to market team, which is incentivized with one business model. You have an understanding of one specific customer profile, and then you have, like, one core DNA of of engineers that are all, like, incentivized to build organizations under them. And so it’s hard to just, like, break all that. You need to break sometimes the actual business model. You need to break the go to market motion and focus on a new customer. You need to break an engineering and product and design org structure to create new teams, and that’s really, really hard.

And so you’ve seen that. How has Amazon actually been able to launch financial products? It’s been hard. How has Salesforce actually been able to make their acquisitions super successful? It’s hard because they do seed based incentives. Whether it’s Stripe trying to actually go from, like, developers and SME to finance teams in the enterprise.

There isn’t a incumbent b to b spend management company that is actually even close to, like, a Microsoft level of, like, innovation and and velocity. So I’m not really scared of the incumbents at all. And, like, Amex is, like, it does not know how to build software. It is an incredible company with an incredible brand and an incredible card and merchant product, but they’re a far cry away from from being a SaaS company. I would say new entry and specifically folks that are going after, again, like a very pointed solution and find a new entry in the finance space.

And so we, one, like, keep a very close eye on new players. We invest in new players. We acquire great talent, and we actually use that as a testing bet to figure out, like, what’s working, and we include that in our product strategy.

So at Ramp, we’ve we’ve shipped a lot of things, and I don’t think we’ve been, like, particularly good at, like, taking things down. And the framework that I have around, you know, do you actually, like, sunset the feature or the product or do you keep it? Is one of, like, what is the cost of keeping that up. If you get to a place where you’re cluttering your application or you’re adding a lot of complexity and that like reduces the stability, then you should really think about like sunsetting these features.

And so for me, I would much rather have a lot of features that we can turn on and off based on the segment and based on the needs and continue testing rather than than deprecating. I think in terms of like doubling down, we should be very clear around how confident are we that the next hypothesis that we have will pan out and how much effort will it be to test that new hypothesis? And oftentimes, you know, the first hypothesis was your main one, and you might not have a second one that’s as strong.

And as if that’s the case, then, like, don’t double down.

One of the hypothesis we had was that we can embed, like, a financial product directly in our invoicing products, it’ll just, like, have massive take up. And the hypothesis there was that the person paying the bill had the authority to take a loan, to pay the bill. And that was the wrong hypothesis in the sense that the person paying the bill, oftentimes, it’s a clerk. It’s an agent that just is more of an operator than necessarily, like, a big decision maker in terms of, like, your financial decisions.

And so you actually need approval from more of a CFO, a strategic finance person to understand, like, should I pay an interest rate to actually extend that payment? And so we had the wrong hypothesis in terms of, like, the actual target segment, which then made our product we had to essentially shift our product to increase the voluteptake of that.

I have a standard scientific process for product development that I’ve, like, tried to apply across the entire teams. And yet, like, different teams perform in very different ways. And so that kinda shows you that, like, it is more art than science. And I think art is a big part of what we do at Ramp. Our biggest advantage is actually it is velocity, but it’s also the design experience of our product and how delightful it is to to finally work in a solution that is much more consumer y in terms of of its design than typical b to b SaaS.

And that takes a lot of creativity, and so I would say, you know, I spend a lot more time on the art part of product, which is almost like painting on a canvas in terms of prototypes and designs and flows. And I think that’s how you build great products is really spending a lot of time with an empowered design team, testing and iterating with our with the customers.

Have a b to c, and startups have no data. So when you’re a startup, a b to b startup, like, you should hire people with strong intuition or at the very least, like, strong ideas that they can very quickly invalidate with more qualitative data than quantitative data. Oftentimes, you have PMs from the Facebooks and and and Googles of the world that are actually just good at testing and moving metrics, but their intuition oftentimes isn’t actually locked into customer research and actual customers. Hire people who are able to listen, who have a strong sense of what’s a good product.

Like, they’re actually, like, snobs when it comes to like their the applications they use on their phones or they’re constantly complaining about a software product. Lean into that because you’re not gonna have data for a very long time. Only recently do we have enough data to actually, you know, run maybe test. Only recently do we have enough data to say to hold teams accountable to more of a lagging metric than a leading one. It takes a very long time.

I definitely agree with that. I mean, when you think about a lot of the SaaS products out there, it’s like reports, it’s tables, it’s forms, it’s drop downs, it’s buttons, all of which are meant to like help you achieve the goal that you have. But like realistically, like you can list out the actual jobs to be done of your customers pretty cleanly and there’s not that many of them. And then you can definitely use AI to do that. And so an example of on ramp was like we had like a huge table of like all of your card transactions and you would go in and you would just approve the transactions that were in policy.

You can leverage AI, and now we do, where we can just flag magically, like the things that are actually out of policy or actually fraudulent, and we could actually have much more of a conversation based approach to what the customer is doing. So a 100%, I think the the software is gonna look a lot less like tables, graphs, and drop downs, and a lot more like a conversation where I’ve released a UI that is extremely dynamic that abstracts the data that you actually would need to see and just gives you the actual raw intelligence.

And I think, hopefully, we spend a lot less time in more tactical work and much more time

Yeah. I I listened to that. I love that. I don’t agree, and again, this is with Shopify, you know, obviously, Toby is, like, very involved in in their product surface area. At Ramp, I think we have a slightly different approach. I think that our founder Eric is very focused on our vision, very focused on our brand, very focused on our marketing and our story and our positioning in the market, and has a a very strong sense of what we want to be as a company. How we get there, I don’t think that it’s necessarily super important for the founder to have the strongest opinion.

I think that they need to shepherd the culture to get there. They need to hold the teams accountable for high velocity. They need to be able to opine on what looks good and what it doesn’t. What is a good decision and bad decision? But you need to have an empowered product team and tech team that actually calls the shots in terms of the sequencing. So I would say, you know, we’ve done well with kind of our CTO Karim wearing more of that product product hat, and I think it’s worked well for us so far.

Yeah. How do you hire people that have a strong sense of velocity? So look, the first one is like, look, what’s their motivation? So I ask them like, you know, why are you interested in joining Ramp? And I think that the answers I look for is like, I wanted to move faster. The company was too big. Things were moving too slowly. I like Ramp’s velocity philosophy and I wanna know what it feels like. I like building and shipping things. Like, those are all like strong signals.

Then the second thing is like, do they actually have that experience? Like, have they actually try to push something through? So you go deep in their profile. Like, how have you had impact at your previous company? And then you go deep, like, what was something that was getting your way? And you see them react, like, did did you confront that? Did you address that? Did you influence that? And then finally, hire people who have sometimes a chip on their shoulder, like people who were ex founders that might not have succeeded or early engineers that have been coding for a long time that just wanna build great things.

And I think you find that DNA that really helps. That those are some of the things that we look at.

We do cases that basically are like lateral things about Ramp. So they’re about something that we would never do, so that we never really like steal people’s work, but something that is like somewhat relevant to Ramp so that the person can actually start thinking about Ramp and oftentimes they get excited about the problem they’re and like, my god, I really wanna work at this company. And so it helps them just start understanding a little bit of our space. But typically, it’s about, you know, a new product that is working or not working and what they would do about it.

What I look for there is just like, did the person put in the work? Are they super clear? And are they able to like influence a team? Because largely what product team really does with the engineering design team is like, they’re the ones advocating for something and influencing teams. And so if you can’t influence me that this is a good idea, you’re not gonna be able to influence the team.

So the the the final round was there’s like product engineering and and design interviews. And half of it is like fit and half of it is case. And we basically just throw a ton of different cases at them. Whether it’s a case around like a system failed, what do you do? Or customers complaining, what do you do? Or a product shipped and the metric moved this way, what do you do? And you just started addressing basically one, like are they framework oriented? Like do they have a strong framework for how they think?

Two, are they able to ask the right questions and engage with you to get to the right outcome? And three, are they actually able to get to the root problem or cause very quickly that helps them just get to, like, eighty twenty in terms of the solution?

Sounds good.

It’s long and hard. You have to do, like, short distance as you go to this long distance. So two week sprints for a marathon. It’s very metrics oriented. So, you know, you know how you’re pacing and you know how you’re doing. Honestly, it takes repetition. You won’t get the first product right. You won’t get your first run right. But if you put in the work every day, you’ll get the great outcomes and these things compound.

Slow down slightly and and also just I think aim for like near more near term goals. When you’re tired, just reduce the goal that you have. So your legs might like feel tired if you’re thinking about like, I have 15 more miles, but how do you feel if it’s just like, okay, just get over this hill and just get to that tree. And I think if you do that, if you break down, you know, it’s it’s hard to think about like how does Ramp become a $100,000,000,000 company?

It’s much easier to say, how can we crush this day? How can we crush this quarter?

You gotta spike at one thing. Either you deeply understand technology, so you’re an x coder, you know how to code. Either you deeply understand business equations, you’re an x VC, or you just read, like, 10 k’s for fun, or you’re just a a deep snob when it comes to product design. Pick your poison, ideally all three, but you need to spike in one thing so that you can come in and you can build a lot of trust with that team.

They don’t let go in terms of the how, and they’re not clear enough in terms of the what.

I think the moment that they join, be very clear with them, like for the first month, I’m gonna micromanage you, then you’re gonna shadow me for everything that I do. And then the moment that you know that they got it, you need to step away and empower them and let them make mistakes. Oftentimes, they either, like, give everything and then but they don’t let go, and so the person’s super disempowered, or the person actually doesn’t have any of the context to make the decisions. So be a super micromanager the first month, and then signpost that with the dear hire, and then step off and step out and be very clear on the outcomes you’re trying to drive.

I would say the founders are probably very anxious, so overcommunicate. Overcommunicate. Overcommunicate. When I first joined as the the first product person at Ramp, I was giving weekly updates on here’s exactly what we’ve done. Here are the decisions that I’ve made. Here are the trade offs that I’ve made. Here are the key things I need your opinions on, and I over communicate it constantly to the leadership team, and that builds a lot of trust. Make sure that you’re sharing what’s in your mind with them in a way that is very actionable for them to opine on.

I have. Yeah. Monday morning, the first thing everyone on my team tells me, what did they get done last week? What are they gonna get done this week? What are the key decisions that they’re going to make? And what do they need my help on? And it’s public, and so everyone on my team can read each other’s goals and outcomes. Would you like to be a CEO in the future? I don’t think so. I have very little patience with fundraising, no offense, and I’m not a very strong marketer.

I’m a builder. I’m an operator. Maybe if I find people who can compensate for that, but I think where I shine and what what I love doing is building great products, and I think that CEOs oftentimes get you know, the majority of their time is spent on telling the story, being great at the press and and great with investors, and I would get fairly stretched and and not super happy. But I’m glad that we have people like that that I can work with so that I can just focus on the shit that

Maybe surprising for me to say, but I think Apple continues to crush it from a product strategy perspective. And what I mean by that is, you know, they have a level of craftsmanship, a level of delight and brand that just has incredible loyalty to their customers. And they’ve also just had this compounding effect of the ecosystem that they’ve been building that continues to just drive so much revenue. I mean, when you think about like the iOS ecosystem and the monetization applications, when you think about Apple Pay and the Apple Card and the Apple Wallet, it just continues to compound and you see that in the public market.

So I’m super impressed with that company and their ability to continue to innovate even at that scale. And honestly, they they’ve rarely missed and they they’re still absolutely winning the market today. And so I hope that Ramp continues to have that level of of brand loyalty and that compounding effects of the ecosystem that that we’re building today.