Lenny's Podcast: Product | Growth | Career: Velocity over everything: How Ramp became the fastest-growing SaaS startup of all time | Geoff Charles (VP of Product)

So when I joined, we were about 10-ish folks, about eight engineers, and in three months

we built a competitor to MX. Six months after that, we built a competitor to Expensify both

public and strategic companies. We hit 100 million in annual revenue. I think we're under

at that 50 total in the R&D department, less than four engineers and three PMs. And then

we started expanding into a Calc Pable. It was three engineers, one designer, one PM,

three months, and they hit out of the park, and that product is moving and billions of

dollars a year. And I think the recipe for all this is.

Welcome to Lenny's podcast, where I interview world-class product leaders and growth experts

to learn from their hard-won experiences building and growing today's most successful products.

Today my guest is Jeff Charles, who is VP of Product at Ramp. This episode is a unique

glimpse into a startup and an approach to product that optimizes for moving quickly,

thinking from first principles, and empowering individual team members. If you're not familiar

with Ramp, they are the fastest growing SaaS business in history, getting to over 100 million

dollars in annual run rate in two years, which is just wild. And as you'll hear in this

episode, they did this with 50 people. In our conversation, Jeff shares how they operationalize

a culture of velocity, how they do a lot with a few people, how they organize planning,

how they define strategy, how they interview product managers and keep a very high bar

for talent, plus also avoid burnout in a very fast-moving culture. And so much more,

my advice is to seriously study how Ramp operates, because there's a lot to learn from their

success and their approach to product. Enjoy this episode with Jeff Charles after a short

word from our sponsors. This episode is brought to you by ASRA, the

leading full-body cancer screening company. I actually used ASRA earlier this year, unrelated

to this podcast, completely on my own dime, because my wife did one and loved it, and

I was super curious to see if there's anything that I should be paying attention to in my

body as I get older. The way it works is you book an appointment, you come in, you put

on some very cool silky pajamas that they give you that you get to keep afterwards, you

go into an MRI machine for 30 to 45 minutes, and then about a week later you get this detailed

report sharing what they found in your body. Luckily, I had what they called an unremarkable

screening, which means they didn't find anything cancerous, but they did find some issues in

my back, which I'm getting checked out at a physical next month, probably because I

spend so much time sitting in front of a computer. Half of all men will have cancer at some

point in their lives, as will one-third of women. Half of all of them will detect it

late. According to the American Cancer Society, early cancer detection has an 80% survival

rate compared to less than 20% for late-stage cancer. The ASRA team has helped 13% of their

customers identify potential cancer early, and 50% of them identify other clinically

significant issues such as aneurysms, disc herniations, which maybe is what I have, or

fatty liver disease.

ASRA scans for cancer and 500 other conditions in 13 organs using a full-body MRI powered

by AI, and just launched the world's only 30-minute full-body scan, which is also their

most affordable. Their scans are non-invasive and radiation-free, and ASRA is offering listeners

$150 off their first scan with code LENI150. Book your scan at esra.com slash LENI. That's

E-Z-R-A dot com slash LENI.

This episode is brought to you by CODA. You've heard me talk about how CODA is the doc that

brings it all together, and how it can help your team run smoother and be more efficient.

I know this firsthand because CODA does that for me. I use CODA every day to wrangle my

newsletter content calendar, my interview notes for podcasts, and to coordinate my sponsors.

More recently, I actually wrote a whole post on how CODA's product team operates, and

within that post they shared a dozen templates that they use internally to run their product

team, including managing the roadmap, their OKR process, getting internal feedback, and

essentially their whole product development process is done within CODA.

If your team's work is spread out across different documents and spreadsheets and a

stack of workflow tools, that's why you need CODA.

CODA puts data in one centralized location, regardless of format, eliminating roadblocks

that can slow your team down. CODA allows your team to operate on the same information

and collaborate in one place. Take advantage of this special limited time offer just for

startups.

Sign up today at CODA.IO slash LENI, and get a thousand dollar startup credit on your first

payment. That's CODA.IO slash LENI to sign up and get a startup credit of $1,000. CODA.IO

slash LENI.

Jeff, thank you so much for being here. Welcome to the podcast.

Thanks, Lenni. It's great to be here.

So you are our head of product at RAM. For people not familiar with RAM, could you just

give us a brief overview of what it is that RAM does?

RAM is a finance automation platform and corporate card solution for small and medium-sized businesses.

So we help businesses essentially automate most things across expense management, card

payments, bill payments, and accounting. We've helped 15,000 of such businesses automate

a lot of their back office to focus on what really matters, which is growing their company

and providing value to their customers.

Okay. So what you did mention is some of the most interesting stats about RAM and the business

and the growth kind of story of RAM. So could you just also share some stats about just

the success of RAM and a sense of just like how rare the story of RAM has been?

Yeah. I mean, we were one of the fastest growing fintech and maybe SaaS companies of all time.

I think we've hit $100 million in your revenue for the first two years. And we've continued

to grow significantly since then. I think every day about 1,000 users join our platform.

And this year, we've grown to hit $600 million in savings, $8.5 million an hour save for

our customers by controlling spend and automating a lot of the manual tasks. So we continue

to grow fast and in terms of just raw transaction volume, we have crossed $10 billion in internalized

spending on the platform and just getting started.

You glossed over that stat of just RAM is essentially known as the fastest growing SaaS

business in history and also fintech business. Like in two categories, the fastest RAM to

$200 million in run rate.

Okay. So for that reason and many other reasons, there's a lot of interest in just how RAM operates

and how you all approach product. And we actually previously collaborated on a newsletter post

on how RAM builds product. And that newsletter post is now the eighth most popular post on

my newsletter across hundreds of posts that I've written and even more than how Figma

builds product and how Snowflake builds product and all these other incredible companies.

And so clearly there's a lot of interest in how you operate. So I'm really excited to get

into the meat of how you all work. And if anyone read this post and has any sense of just how

you all operate, there's one word that immediately comes to mind when people think of how RAM operates

and that word is velocity. So I want to start there. Can you just talk about how important

velocity is to how you work and where that came from and how that actually looks day to day at

working at RAM? Absolutely. So you mentioned it. You know that velocity is everything at RAM. It's

how we design our product development process. It's how we incentivize teams. It's who we want

to hire. It's who we want to promote and it's everything around how we make decisions and how

we organize the organization. I think, you know, it came from the fact that during the pandemic,

we started with a very small team and there was a huge market opportunity ahead of us.

And it wasn't so much, you know, which path we wanted to pick, but rather how fast we were able

to execute on that path. And so velocity was kind of in grade from the early days on just

building, shipping and iterating. And I think it's a decent metric for how companies and teams

perform. You know, you might say, well, you know, what's the impact of that velocity? But

realistically, teams that have high velocity are able to actually get to that impact over time by

iterating. It's also a great way to have positive selection in terms of like talent,

because talent wants to join companies that ship fast. A lot of people who join RAMP ask them,

you know, why are you interested in joining the company? They often say, well, it's because

you guys are actually building things and shipping things. And I want to know what that feels like.

And it's also a great way to just de-risk decisions and decision making. If the cost of

that decision is really low, then you're able to essentially simplify a lot of decisions.

To build on that, there's a lot of companies that say they move fast, that talk about moving fast,

that say we're like, velocity is really important, moving fast is really important to us.

But I feel like RAMP is very different from that, where it's actually incredibly,

incredibly fast. And it's actually something you come back to again and again, this idea of

how do we move faster? Can you just share an example too of what velocity actually looks like

at RAMP and what the reality of that is? Yeah. So when I joined, we were about,

10-ish folks, about eight engineers. In three months, we built a competitor to Mx.

Six months after that, we built a competitor to, to expensify, you know, both public and

traded companies. We hit 100 million in annual revenue. I think we were under, at that point,

50 total in the R&D department, less than 40 engineers and three PMs. And then we started

expanding into accounts payable. We basically gave a team, you know, goal of building a

competitor to build.com. It was three engineers, one designer, one PM, three months. And they hit

it out of the park and that product is moving in billions of dollars a year. And I think, you

know, the recipe for all this is constantly, you know, small teams have a single threaded

focus. Give them the resources they need to execute big lofty goals, very tight timelines,

and then like shield them from the chaos that is the rest of the organization. So basically,

don't bother them and don't even tell the rest of the company that you're doing these things

until they find product market fit, until they actually find that early traction and then they

can bring in more resources. So it's sort of like gravity, right? And you need like gravitational

pull to this thing. Okay, I want to double click on some of these points you just made. So what you

find is important to help teams and people move fast within ramp is you talked about single

threaded teams, shielding them from other people trying to pull them in different directions,

lofty goals. There's a couple more things. Let's talk about the single threaded piece a little

bit. What is that? What does actually mean? What does that look like? There are very few people

who are able to execute extremely well more than one thing. And it's especially true for

individual contributors. And so what I mean by single threaded is like, there's only one goal,

one threat that they're they're waking up in the morning to focus on. And in order to remove

that, you basically need to remove anything else that they're being asked to do to just focus on

that thing, whether it's, you know, any type of research, any type of production engineering or

any type of process that's outside of that single goal. And you know, it almost goes as far as like

you just like saving a room in the office just for them. And they are just in that room all day,

every day, just working on that one thing. What's an example that either some maybe someone's working

on an hour in the past, that's like a good example of a single threaded goal or team?

Yeah, so for example, we we launched a flex product over the last summer, that was a single

threaded team, we're just focused on e-commerce companies and their needs with more cash flow

conversion and cash flow smoothing. And so we kept that team, again, just purely focused on

just shipping that product and hitting that goal. If they were ever distracted by something else,

I don't think we would have hit it. How do you as a leader avoid distracting them knowing there's

so many things you need to do? And there's constantly this like, oh, if we just fix this one bug,

this one customer is going to be so happy. And okay, if I just ask this 1pm to work on this for

a day, I know there's not going to be like, here's the rule step 123. But how do you actually approach

shielding teams from from things that just are constantly on fire?

So we have, for example, on bugs or issues like that, we have, we have individuals that are protecting

those teams from those issues. So, you know, we have rotational program on production engineering,

for example, where our engineers are protecting the core team from escalations, from bugs, from

issues, we have product operators that are protecting the PM from the chaos that is,

you know, documentation and escalations and release management and and enablement customer

requests. So we have layers of protective tissue to core teams. But I would say like for any of

these like big bets, you basically have to pull folks from different teams and reorganize a sub a

sub team. And that team typically doesn't have responsibility on any existing product, because

these are all fairly new products. I think it gets more challenging when you go from one to two,

rather than zero to one. You also mentioned this idea of lofty goals. And that's something I've

seen a lot at Airbnb. There's a very known for lofty goals. Brian was famous for going to meetings

where people present their goals and their plans. And he's like, how do we 10x that? What do you

need in order to 10x that goal? And then that ends up being your goal. And often worked shockingly,

sometimes burnt a lot of people out. How do you think about just finding that balance? And I don't

know, is there an example of just like here's a really ambitious goal? And or maybe the question

just how do you find the balance of ambitious, but not just like impossible? Yes, the first thing is,

you know, we have market comparables, which is very exciting for us. So when you look at

you know, bill.com, right, they're a publicly traded company, expensified,

but we can trade it or concur or Koopa. These are all like large players that are actually very

motivating and largely de-risk some of the business decisions you're making. That's existing markets.

We've also been able to create markets. Spend management was an actual market before we

and other competitors kind of jumped into it. So that's what that's motivating. Go attack that

market and go go drive that revenue is very motivating. We also use designs as a way to

motivate teams. So we spend a lot of time with designers crafting out what the future of this

thing could look like. And that's also extremely motivating. So we constantly go back to these

cornerstone loom walkthroughs of Figma prototypes that that designer spent a lot of time talking

through. And I think that's a big part of the motivation. And so both of those things combined,

I think helps us stay motivated. I think there's a constant pushback to like, okay, what can we

actually achieve? But you're going to move super, super fast if you have those two things in mind,

the market and the revenue goal, because we're very revenue driven as a company. And the designs

that that can really keep you anchored on on what this could look like.

I know another important ingredient to how you operate is you really like to empower

product teams and give them a lot of control over how they operate and what they build and how they

set goals and things like that versus micro managing them. I think you have this concept

of context over control. I'm curious how you actually operationalize that a lot of people

love the idea of empowering their teams. And then they do that. And then the team, they just do,

they do the wrong thing, or they take too long, or they set the wrong goals. So how do you actually

make that work and create empowerment within your teams? Yeah, it was it was one of the biggest

cultural differences, I think in ramp versus other companies that were as a part of where

my boss, the CTO Kareem was extremely hands off in terms of the actual pride decisions

because we were extremely aligned on the goals themselves. And so that's where you really just

start alignment is what is the goal that you're going after? What is the hypothesis that you

have to reach that goal? What is the data by which you're coming up with that hypothesis?

And then what is the potential solution to test that hypothesis? And oftentimes,

more junior leaders, and I was certainly in that camp earlier on, kept focusing on the solutions

and debating the right solution. When in fact, you should really be debating upstream of that,

you should be debating the interpretation of data, you should be interpreting debating the

hypotheses and the different ideas that you have there as to what's really going on,

or you should be debating the goals themselves. And so whenever things went wrong at ramp,

it was when I was being prescriptive with regards to the solution without actually explaining

and aligning upstream on the goal, the hypothesis and the data. And if you do that, you realize that

the solutions actually can come much better from teams that are much closer to the ground.

I think that's the biggest goal that I have now in my role is to continue giving context so that

teams focus on the right goals, come up with the right hypotheses and focus on the right data

points. And I spend most of my time just repeating myself, most of my time just sharing the context

that I think they might be missing, especially given that I'm in certain meetings or certain

groups and certain forums that they're not a part of and my responsibilities to represent them

and then share back the context for them to do better, make better decisions over time.

That touches on a phrase that's come up a couple of times on this podcast that a leader's job

is essentially the repeater in chief, reminding people of strategy, vision, things like that.

It feels like to move fast, you need to do what you're talking about, which is empower your teams

to just move. Otherwise, it's not scalable. And I'm curious just to make it even more real,

either is there an aversion of something you did at your previous work versus at ramp that just

shows what that looks like when you're empowering your team and not in the weeds? What's like most

different there is that the product reviews, you're not as involved in design iterations like

where do you come in to actually get feedback? How does that actually look like working at a ramp

versus another company? I think that the contract between me and the team is really their strategy

and their roadmap. And as long as we are aligned on the strategy and we can get into that

and aligned on the roadmap and the timing, that's their contract. And so then at that point,

my goal is to continue to give them context to execute on that and to coach them through that

by getting firsthand data on how things are going that they might be missing.

And their role is to highlight risks and highlight one-way decisions that they need my input on.

And again, it didn't used to start that way. I mean, when we first started, it was just me

and another PM, I was fairly micromanaging in some areas. I think you build trust over time

and you start having these contracts. And so I suppose getting more senior,

they're basically polishing out the API by which they interact with me. And we basically

align on what's most important on each one-on-one. So I basically have teams, all my directs,

post their goals every week. First thing Monday, the goal there is to also have them review each

other's goals. I have a one-on-one template that I basically use to keep track of how progress is

being made. But I certainly don't spend the time in the one-on-one going into that. I spend the

one-on-one just focusing on what they need from me. And then on a bi-weekly basis, I have a team-wide

meeting where I share context that everyone is missing. And we go deep on the most important

topics of the day. What about the product experience itself? Is there a design review that

happens? How do you stay on top of just like, I'm proud of this product that we're shipping as a

team? I'd say we're iterating. I think when the first couple of years, it was more asynchronous

and ad hoc process. And once you hit 10, 15 p.m. and 20 or 30 different mini pods, shipping

constantly, I think you need a bit more of a process by which you have high-risk decisions

that are being surfaced. So we're iterating. I think what we're landing now is any large rock

that we have on the roadmap needs to be brought into the product review process,

where myself and the head of design are present and giving feedback. But it needs to be structured

in a way where you're asking specifically for what type of feedback you need, and you're highlighting

the key risks and trade-offs that you're making implicitly in that review. So that's one way

we're able to scale. But I would say largely people ship. And it's the difference between a

beta and the GA that's where we really get plugged in. When we make the decision to go live

to the rest of the customer base and asking sales to start selling, that's where I'll really come

in and stress test the hypotheses and the decisions. It's further downstream, so it's

more risky. But because we move so fast, you don't waste that much time if you have to pull it back.

Yeah, that came up actually. I just had a chat with Nicole Forsgren, who's

world expert on developer productivity and developer experience. And they've done all this

research on quality and speed of engineering and the engineering team.

And they find that quality goes up as your product velocity goes up. You think it'd be the

opposite the faster you move, the lower quality ends up being. But exactly to your point, because

you can fix things really quickly, and you can get things out the door. And there's not this

like huge chunk you have to wait for people to review and release and break things ends up being

higher quality. So it's very much aligned with our experience. Yeah. And you have to create a system

by which those folks are getting that feedback, right? And so we really focused on what are the

control mechanisms that ensure that your high velocity doesn't tank the business. And so examples

of that is, we have a voice of customer processes where every single negative review that is shared

on to our products is shared back to the tech lead, the PM and the designer on a monthly basis.

We report back and PS and CSAT, we report back operational overhead, meaning the percentage

of tickets that come from your product area, normalized by the number of users that are

using that product. And that's a core contract that the team has to maintain a lower part of

operational burden. We also have bugs and issues being directly assigned to the engineer that's

on call. So they feel that pain, and then they can continue to your point, leveraging velocity

to solve those problems. Velocity is just a magnitude. It's not necessarily a specific direction.

With these bugs that are coming in and quality issues versus a team's goal and

their KPIs that they're trying to hit, how do you recommend teams balance those two things?

We don't have a bug backlog. We fix every bug once they're surfaced.

So it's part of the production engineer's job, really, just to fix those things. I think where

we get to nuance is user experience improvements. The metric there that I really look at is how many

support tickets come in that were due to a customer being confused. So we track that. And

if that number is slightly elevated, we're basically saying you can't ship any new features,

you need to fix these things. And so yeah, there's just these types of controls, but basically

trying to standardize across the teams. This is your percentage of operational burden. This is

your CSAT. This is your NPS. And this is the number of customers that are confused. As long as you

maintain those metrics, you do whatever you want. But the moment that these things are in the red,

you can't ship new features and you need to revert back to them.

Something funny that happened after our post on how Ramp Build's product came out,

someone on LinkedIn, a product manager, posted half jokingly that her CEO came to her and every

PM CEO came to them after that post and they're just like, how do we prioritize velocity? How do

we move faster? Look at this, this culture of velocity that Ramp's got. Why don't we have that?

What do we need to create this culture of velocity? And I worried a little bit because it creates

this additional pressure on product managers that already have a really hard job with already

a lot of pressure. So I was like, oh man, we're creating this like new pressure that this one

company is doing things really well and that everyone has to do it this way. So I guess my

question is just, what's your advice to product managers who are getting this push from leaders

to move faster as a result of how you guys operate? Yeah, well, one, I'm sorry. It goes without

saying like PMs, we can't do anything by ourselves. We're very useless. We're a forced multiplier.

So that the one thing that I'll highlight is like behind Ramp's velocity is a lot less like the

culture that I try to amplify, but a lot more the quality of the engineering and design talent

candidly. And so I'm just standing really on their shoulders here. And so like advice number one is

ensure that from the top down, there's an investment in R&D as a first class citizen that

you're paying up market that you're hiring the best that you're focusing on your engineering

and tech brand that you're bringing people who want to work there because they want to be

empowered and then you have a culture of empowerment. And what that means is and it's hard,

it's hard to get right. What that means is the CEO has less say in the product that is built

and the engineers have a lot more say into it. And so it's something that I've seen done really,

really well at Ramp where the CEO sets the vision, but is much less opinionated about the specific

sequence by which we get there and trusts a tech organization that is rapidly empowered.

The second thing that like, you know, I would say is the biggest waste of time is meetings

and status updates. And I think that oftentimes CEOs would say or leaders would say,

Hey, we've got to increase velocity. Therefore, let's just add these status meetings and let's

add this all this process and all these documents and all these ways to hold teams accountable.

And that's just a huge way to demotivate people. And so, you know, I've never had a status meeting.

I've never scheduled a status meeting. Statuses are done async. They are done in the systems by

which they operate and largely they should be in real time. And meetings should be all about

collaboration, ideation, decision making, etc. So just look at your calendar and just kill as many

things as possible and kill on an important process. And the last thing that I would say is

oftentimes, you know, leaders say, I want to move super, super fast, but they'll say I want

everything under the sun. I want this and that and that. An example of that at Ramp is always like

the debate between adding more products to one segment or going to a different segment, right?

SME versus a market of residential price. And you ask the CEO, Hey, which one should we do?

And they would say all of it, because they think that the more goals you have,

the faster you'll be able to execute. And I think there's just a limitation to that. So the thing

I would amplify is be very clear with the tradeoffs that you need to make and present those tradeoffs

back to your leadership team. So here's what we're doing. And here's what we're not doing and why

and which one would you pick? Give them a menu of items. And you'll see that you're able to execute

much, much faster on four things rather than eight at the same time. That's your job. Your job is to

basically communicate those tradeoffs that oftentimes are not well communicated to executives

out of fear of looking like you're pushing back. You're actually not pushing back, you're

increasing velocity. What I'm hearing from kind of a meta point you're making is use that ask as

leverage to change the way things are operating. Is that right? 100%. You can't ask for velocity

and not have empowerment and not trust and not eliminate process and not increase the focus.

And that requires some serious tradeoffs that oftentimes leaders, especially those coming

from more traditional industries, are not comfortable with. And it was the biggest breath

of fresh air when I joined Ramp was how committed the team was. The last thing I'll say is

there's nothing more motivating than like a leader just commenting like this is awesome on a random

project channel at a random design crit. I know that our founders are just like

reading the projects that they actually care a lot about and the engineers know that.

And so there's just a general like excitement on just building great cool shit. And engineers

just feel that and they're also like highly motivated by that. So that's another piece of

advice is just like being able to stay plugged in to give engineers the opportunity to present

to those leaders, present in the all hands. That's also a great way to amplify the culture.

It's a good segue to this idea of burnout, hearing a team operate incredibly fast and

velocity, velocity, velocity makes you think about are people burning out? Are they enjoying

their work? How are they sustainably going to last at Ramp? I'm curious just what that's like

and how you think about avoiding burnout for folks that are just constantly shipping, shipping,

shipping. I think the debate around working hard and burnout kind of misses a key point,

which is all about how much impact and how good you feel about the work that you're doing.

And I think that for me, when I felt burnout, it was actually at the time where I had the

lowest amount of velocity. It was when I felt like I was putting a lot of effort into things that

weren't actually moving. And so I actually think velocity is a way to potentially avoid burnout.

I'm not asking people to work unless hours a week. I'm asking people to get out of their

own way and to focus on what truly matters, which is building great products for our customers.

And I think you do that if you get into a flow state, if you get into a cadence where everything

becomes easier, where work can really become thrilling. And I think sometimes organizations,

especially as they grow, make that really hard. They make it really hard to just be in that flow

state with a ton of distractions, a ton of meetings, a ton of cross-functional teams that are all

asking for your attention and grabbing for attention. And another parallel of this is

running. The best runners are the ones that love running and they feel like running is in the

chore, work is in the chore. And I think as a runner, I try to try to emulate that whenever

we're doing something hard, that's challenging, that's exhausting. If you love what you do,

you feel much better about the amount of effort you're putting into it and work doesn't feel like

work. I find the same thing. I find that when I think back to the times that had the best

experience, the most fulfilling work that I've done, it's often I was working insane hours.

It was just like this very long, stressful project. But looking back, you're always like,

wow, that was so much. That was so cool. I learned so much. We shipped so much interesting stuff,

made so much impact. I think the key is what you said is that you have to actually be proud of it

and it has to be something that's meaningful to you because you could work long hours on something

that you have no interest in and that does not help and that does lead to burnout. So that's the key.

And you said something there, which is like meaningful to you, right? So not meaningful to

your boss or your boss's boss, but meaningful to you. And I think that that's the role of

management is to make everyone on your team feel like it's their goal. And the way to do that is

to, again, align on that goal and give it to them and to problems to solve. If everyone feels like

it's their team, it's their company, their mini company, then they will radically avoid burnout.

But if they feel like the work is being pushed onto them, they feel like they're not aligned on the

goal or they don't feel empowered with the solution, then the burnout will absolutely happen.

One of my favorite quotes that you have shared is any second you spend planning is a second you

don't spend doing. And on the one hand, I love that because the more you do, the more things happen,

the more you get done, everything's happening. And the other end also, it also feels a bit chaotic.

And I'm curious how you find that balance between, okay, we're not going to spend all this time

planning, we're just going to go, go, go, go, go. And just how you think about that balance and how

it actually ends up working out at ramp sounds like not spending a ton of time planning.

Yeah, I would say like when, when new joiners come at ramp, I, I, I intro myself and I talk

about our product strategy. And I end in the meeting with, with an apology, I say, you know,

you, you, you sign an implicit contract joining ramp. It's one where we prioritize velocity over

almost everything else. What that means is it'll be somewhat chaotic. We'll ship things that don't

work. We will change our product without necessarily fully enabling you. And you'll have to constantly

be on your toes whenever you load up a demo instance. And I think that it's kind of an expectation.

And people are welcoming of that because they understand that the tradeoff is that we don't

move forward, that we don't, that we don't actually innovate, that we don't continue to,

to provide value for our customers. I think there's, there's certain things that we plan for.

And so the question really is like, because accuracy has cost, make sure that you're only

increasing the accuracy of planning for the things that have high value of that accuracy.

And so the things for us are, you know, large market moments where we have

products, marketing, and sales all coordinating these, these big moments.

And, and those typically happen maybe, you know, once a quarter, once every six months,

basically your marketing calendar, we need a plan for that, for sure. But it's oftentimes a low

percentage of our total R&D focus. And so it's totally fine for each team to be somewhat autonomous,

somewhat chaotic within their pod. They're extremely clear, but for the outside in,

might be very chaotic, but be very accurate on the things that truly, truly matter. The rest

actually doesn't matter. You don't need a lot of, of accuracy and confidence on, on when specifically

certain features will be live. It's much better to, to spend whatever time you would spend trying

to create accuracy and, and creating velocity. I love that you said expectations very clearly up

front. That seems really important to be successful at a company like that. It also just makes me

remember every successful startup is extremely chaotic. As much as it may not feel like that on

the outside, it's insanely chaotic. Things are constantly changing. I was at a fireside chat

with Sheryl Sandberg once at Airbnb, and somebody asked her just like, how do you deal with change?

Things are just, we're reorg-ing every six months. People are leaving and coming and teams are

shifting and priorities are always adjusting. And she's just like, this is the problem you want.

You want to be going through this because that means you're growing and you're going through

hypergrowth because the alternative is much worse where you're not growing. And that's much

more painful. So I think it's just a good reminder that if you're working at a place that's chaotic,

it's often a good thing. I would say so. I mean, oftentimes people use that excuse to not have

a very strong strategy. And I think that for us, we've always been from the start,

the spam management platform that helps you spend less. Our strategy, I share an annual newsletter

around what we did and what we're going to do next year. And it's oftentimes pretty spot-on in

terms of the goals. Again, the goals and the value and the problem and the vision, that's consistent.

The specifics, the timing, the quarterly scopes, all these things, yes, like it changes. But what

you want to avoid is the thrash of people waking up and feeling like they're working at a different

company or that leaders are constantly changing their minds. We've been extremely consistent

from the start. And I think most of the products that we built, most of the code that we were written,

is in the customer's hands and hasn't been ripped away. And I think that speaks a lot

to velocity, too. Awesome. That was a good addition. And I mean, to say, if your place is chaotic,

it's no problem. It's that side effect of growth and hyper growth is things are going to be pretty

chaotic. This episode is brought to you by Atio, a new type of CRM that's powerful, flexible, and

built around your data. Traditional CRMs were built for a different era with totally different speed,

scale, and data demands. Atio is different. It allows you to quickly build a CRM that matches

your unique workflows and data structures. Within minutes of connecting your email and calendar,

you'll have a CRM that's already set up, complete with customer profiles, and automatic data

enrichment. You'll also have real time dynamic reporting at your fingertips. No more slow deployments,

outdated user experiences, or tedious manual data input. With Atio, you can build and adapt your

CRM on the fly, no matter your business model or company stage. Atio is the CRM for fast-growing

startups. Get started today and get 15% off your first year at atio.com slash Lenny. That's

attio.com slash Lenny. So you've talked about strategy a couple of times, and I want to dig

into that a little bit. So there's kind of maybe a couple of directions we can go. One is you talked

about this contract you create with teams of strategy. So maybe let's just go there. What

does that actually look like with it's part of this contract? And is there like a document you

put together to leave this out? Strategy means a lot of different things. In my mind, strategy is

about how do we get to our goals? And it's not a roadmap and it's not a vision. It's something

right in between that. So the first thing you need to do is align on what are the goals, what do

you want to see in the world? Then the hypothesis is why do you think this will work? Figure out

why we're uniquely positioned as a company to get after that goal, figure out the metrics by

which you would measure whether we reach that goal, and then talk about the initiatives,

talk about the risks, and talk about the long-term outcomes. So these are kind of the bullet points

of the contract essentially of a strategy document. Correct. And now every pod basically spends time

writing that doc for themselves. So the pods are basically organized against outcomes. So

they should be very clear on their goals. And they publish these things out. And then what I

typically do is take all these documents and make sure that they're aligned with our high-level

product strategy, which is a bit more long-term thinking than the individual pods. And that they

are also aligned with our financial strategy, which we can get it to. But that's a little bit

how you also create a culture of empowerment where each team is thinking about these things,

thinking like you. And the more that as a leader, you make teams think like you,

the more leverage you get over time. And the more you can start thinking ahead on

other ways of operating. How long does planning roughly take? And how often do you do this

strategy kind of rethink? We've gone through iterations good and bad, I think.

For a period of time at Ramp, we equated OKRs with financial goals and quotas to some extent

for different teams. And that led to just taking a long time to plan because people were

trying to make sure there was the right metric, trying to make sure that it was achievable.

And it became very political, very annoying. And largely, our entire R&D team was like,

look, we're just going to execute on the roadmap. Screw the OKRs. And so we moved from quarterly

very expensive quarterly planning, which took one month every three months. So basically,

33% of the time was planning to a biannual one pager on these other company priorities.

And it's much more smooth and much faster. Related to that, though, we have a strong financial plan

that we execute on. And each row or lever of that financial plan has an owner. Oftentimes,

it's marketing and sales for anything that's product led. It's product.

So that's one contract. And then we have our roadmap. That's the second contract.

One of the bullet points you mentioned is this idea of being, what are we uniquely positioned

to do? Can you talk a bit more about that? And maybe what's an example of something you worked

on, how you describe why you're uniquely positioned to win at that?

One of the biggest values, I think, of software is how do you reuse the components that you've built

to increase, again, velocity and impact. So why we were interested in bill payments

as an expansion of our corporate card platform was we saw a bill as just an invoice to the company.

And an expense was an invoice to the employee. And so there was a lot of parallels between

these two things. It was all about having a liability. It was all about processing that

liability in terms of the financial event and moving the money. Moving the money either

between the company, between the company and the employee, or between two companies.

So we believed that we were uniquely positioned to get after that space because we already had

money movement. We already had some type of liability. We already integrated with accounting

systems. And we had a pretty strong risk process that can govern all that. And the employees

that were requesting to pay these bills were already on the platform. So that's an example of

like a right to win. And I think that if you continue to focus on where you're uniquely positioned

to win, you'll increase velocity because you already have a lot of the components of the expertise.

I love that. It's not something you really see in teams, docs of just like why we have the right

to win this. So I think that's a really interesting element. By the way, I should mention we'll link

to a template of your planning approach in the show notes, which we also had in the post that

we worked on. So folks are trying to write down notes of all these little bull points. We're

all linked to a doc that has all these things. What do you think of OKRs and how do you approach

OKRs as a part of this planning? I largely stay away from OKRs from a product perspective.

I think that, again, strategy, financial plan, roadmap. I think where we landed on with OKRs

were really around more cross-functional things in nature. So for example, we'll have an OKR

around winning a specific market and we'll have OKRs that are cross-functional across

different teams. But again, an OKR is just a method to measure an objective with metrics.

And you can use them at various levels of granularity. I stay away from them from a product

perspective because, again, I want to focus on velocity, which is just output, which is your

roadmap. They're pretty strong at more of the cross-functional side of things as well as the

financial side of things. I don't even know what separates an OKR from not an OKR. I feel like

OKRs are just a goal with some high-level statements of things we're trying to accomplish.

I don't even understand when people say they use OKRs or don't, what that even means anymore.

There's a recurring point on this podcast and other posts of people are weary of

just being obsessed with, here's the metric that we're going to hit and that's all that matters.

There's a fear they lose sight of the bigger picture what they're trying to accomplish.

But I think in the end, it's just like, here's what we're trying to do, here's some goals we're

going to hit. Because I don't know OKR, I don't know. I think that's right. And at the end of the

day, again, the contract is your product roadmap. And that's the contract you have to the sales

organization. Marketing can take that product roadmap and create market moments.

And ultimately, if your product roadmap doesn't actually hit the goals of the company,

then I'm accountable. Because I've created a system by which I've aligned with each team on

why the roadmap is going to hit the goals. And so you essentially need to point back to the

leader in that regard. But I can't ask every team to try to manipulate OKRs to fit their

roadmaps. That's just completely exhausting. We've aligned on what we need to do. Let's get it

done. Something that comes across pretty clearly in the way you think and the way Ramp operates

is this idea of thinking from first principles. And it's kind of a cliche term. It feels like

everyone's always trying to talk about how they're thinking from first principles and it's

important to their culture to think from first principles. But it feels like you guys actually

do it. And so I am curious just where that emerged for you and or for Ramp. And is there

an example of something that emerged within Ramp and you product or an idea that was very clearly

from first principles? The most important thing to talk about here is that Ramp is a very unique

business. I mean, we're a credit card company, which is all about risk management and underwriting.

We're also a payments company because we move money between businesses. We're also a software

company because we deal with expense management and expense management, accounting, we're building

for SMEs. So we have PLG, but we're also building for enterprise. So we are sales driven or everything.

And so it's really important when you're dealing with something that hasn't been done before to

think from first principles. And what I mean by that is you don't pattern match from your past

experience, but you go back to the fundamentals of what we're trying to do and you think through

them very, very deeply. And that means you need to hire people who can think from first principles

and be okay putting aside their experience. And that's a tough pill to swallow for some folks who

will come in and will say, I'm the subject matter expert on XYZ and I know what's best.

And they come in and they get a reality check about the complexity of our business

and how also you can't influence teams by saying, I've seen this before.

That's just like an anti-pattern, like you can't say my past company, XYZ.

No, no one wants to hear that. And so and surely I thought I was coming into ramp and I was going

to apply the best product development process. And I had to shift that process entirely because

the process was predicated on a B plus engineering team and I was faced with an A plus engineering

team. And so my entire, I had to go back to first principles around how products should be

developed and built. So again, like all the advice I'm sharing here, you know, don't just take it and

map it and copy paste, start from the first principles that we're sharing.

An example of that is our support team. So support reports into me and the first principle there

was saying, well, every support ticket is a failure of our product. We literally have that as, you

know, a quote just posted on all those channels. It's a failure. And if the product works perfectly,

no one should ever have to contact our support team. And what better way of holding the product

team accountable for support other than having support report into product? And the second piece

was that we believe that a lot of our value to our customers, because it was going to come from

deeply understanding them, deeply listening to them and moving on that, on that feedback. And so we,

instead of hiring, you know, people who were focused just on resolving the ticket, we incentivized

people to actually like decrease number of tickets over time and decrease deflection or increase

deflection. And that required hiring a different breed of people that then became, you know, leaders

in different parts of the organization as well. So again, we could have easily just pattern matched,

look at comparables, hired people who've scaled large support teams, and just use like benchmarks

in the industry. But we've started from first principles. And the outcome of that is, you

know, we have an extremely low contact rate. We have, you know, over 400,000 users on our

platform and a team of agents that's under under 30. It's pretty crazy ratio to think about.

That's wild. I missed this nuance. So the support team reports into you and the product team.

Yes. Wow, I've never heard of that. That's cool. Okay. So I'm going to change course a little bit.

And I'm going to talk about writing. So we worked on this post together on how ramp operates. And I

was just incredibly impressed with your attention to detail, your ability to articulate your approach

to product. And as we were working on this, you mentioned that writing is really important to you

as a way of figuring out what you think, and to solve and crystallize problems, which is exactly

how it works for me. And that's how this whole newsletter started. I was just trying to

crystallize what I remembered and did so that I can remember it and share with people. So I'd

love to just hear your insights and take on just what writing does for you. And maybe what you'd

recommend listeners do with this kind of approach of writing, helping them think.

Throughout the years at ramp, I was often faced with a problem or question that

that I couldn't answer off the bat. And I had to go back to

first principles. And the best way of doing that is to shut down your laptop,

you know, take out a piece of paper, write the question as simply as possible at the top of the

paper, and just spend time just thinking about how to answer that question. And there were,

there were a ton of questions over time. For example, you know, how do we, and it was all

scalability problems that few companies have actually done successfully. And so you have to

start with your own thinking. How do we scale decision making? How do we incentivize teams to

work together? How do we do headcount planning? How do we allocate headcount in a fair way?

How do we avoid politics as first hand data goes away? How do we make decisions on doubling down

versus pivoting? All these things are really tough. And I found myself, you know, you could,

you could, you could read things and that's helpful. But I don't think that reading makes you

necessarily think better. It makes you more wise. But the best way to, to increase your capacity to

think is to actually do the thinking. And so that's where I see, I see writing. If you're able to

write things clearly, you're able to think through things clearly. It was also a way for me to

effectively communicate, especially during like a COVID where like, we largely grew up during COVID

where everything was written. And it was also a way for me to get content out there to increase,

you know, my, my brand and, and ramps brand in terms of the, the space that then led us to, to

hire, you know, better people over time. So all these things kind of work out, but it does require

you to block out time and to, again, focus on how you think about problems rather than try to

Google the answer, you know, after you thought through it, then, then go out and, and read.

And you'll, you'll fine tune your thinking and you'll identify new, new questions to ask yourself

afterwards. I love this advice. You mentioned earlier that PMs can't really do much on their own.

But I think this is the thing PMs can do is PMs have the time to think and to plan and think

ahead because they're not required to, you know, build code all day and design. This is the,

this is the advantage you have as a PM. I always think that PMs often don't really have any special,

unique skills. They just have the time to do the things that nobody else

wants to do or can't, or yeah, doesn't have the time to do or doesn't want to do. And

just this really important point of just spending the time to think and not just

constantly try to discuss things in meetings or like you said, just Google around for answers

that ends up being incredibly important. And I just love this framework of just starting a

doc with a little question at the top and just sit there and try to answer the question on your

own before doing anything. I think that's a really good approach. I want to ask how you actually

do that. How do you actually create these blocks of time? There's this, you know, concept of deep

work and how valuable it is to create a work and knowledge work. How do you, how do you do that

for yourself? How do you block out time and not get bugged all day? Because we're like really

anti-meeting at, at ramp, you know, I had time in my calendar. And so what I would basically do is,

you know, the, the Friday before I kind of clocked out, I would look at the next week,

I would look at the, you know, the top questions that I needed to spend time thinking about,

and then I would block out that time. I also, you know, work on one day of the weekend in

terms of deep work. I find that, you know, hanging out outside and, and, and dueling on my piece of

paper, you know, some thoughts is actually really refreshing because it doesn't feel like work. It

feels like just me just philosophizing about, about something. And so yeah, blocking out that time,

finding a space where things are less busy, where you're not in the critical path either early

mornings or, or later afternoons, or, you know, a day on the weekend is, is the best, the best path

for it. What do you do if someone wants to actually schedule a meeting with you or reach out or put

some on your calendar? Is there kind of a policy there to protect that time? I think that I should

never really be in the critical path of, of, of anything. So largely I, I, you know, I'm not

available. But if they really need to get to me, they have my phone number. Cool. The thing that

I found really valuable is just on a morning, Wednesday mornings and Friday mornings, I just

have this huge block called deep work time. If you book a time during this time, I will slap you.

And I don't know if I'm allowed to put that into meeting calendar invites anymore, but that actually

worked really well. Nobody really booked meetings in that slot. And I didn't know Zoom had a slot

feature that bitch. It was a, it was a Google, it was in the calendar. It was like the calendar

invite. And I also work usually at least one day a weekend. I found that to be really effective.

And I know a lot of people don't want to be doing that, but I found that really important to,

to have great success. One other question along these lines around just optimizing

for processing and getting stuff done and deep work time. Do you have any of their

best practices for just being organized and staying on top of stuff, knowing there's just

stuff coming at you all day every day? If you're a manager and like me, you're in back to back meetings

from, you know, 10 to 10 to six, it's very easy to be completely overwhelmed with a sheer amount

of stuff you need to do. And so I, I've invested over time in like just a very robust, but fairly

simple like task management process, which is at the end of every meeting, I would write down

the tasks that I owe and the tasks that someone else owes. And I would write them down like as

clearly as possible, not like some vague thing, but a very clear thing. And just like when I need

to get this done by, I don't spend time just grooming. So at the end of the day, I have, you

know, I use notes, I have just a page long thing of all the things I need to get done, all the

things people need to get done for me. And then I spent time grooming, which is basically just

trying to group things together and like logical chunks, grouping the tactical versus the strategic,

the important versus the less important. I group also what other people owe me and I slack them,

what they owe me and that put a reminder on slack for like, you know, when they, when they owe it to

me by, and that way it's just out of sight out of mind. I think that the high level theme is

I try to create or free up a headspace for processing, not memory. And so I just basically

spend very little time memorizing anything. And I write everything down that, you know, is hard

when you're trying to remember a specific date or remember something that someone said, but you

have a system by which you can pull these things up very, very quickly, you know, in the in the

Google space, you can pull up any document and, and search a bunch of documents very, very quickly.

So that's what I would, I would, I would do is just spend a lot more time on the processing,

be extremely good at just task management, and then grouping things. And then the next day,

creating your calendar aligned to the goals that you've set for yourself the day before in terms

of the tactical, where you group those tactical tasks together, and then the more strategic,

deep thinking, walking out that additional space. I feel like you and I are very aligned on a lot

of things. That's exactly how I approach priorities. Have you read Getting Things Done by David Allen?

I don't read a lot of nonfiction, actually.

Okay, because what you're describing is very aligned with this approach to processing and

taking to do's. And it's kind of what I built my approach on. And so you naturally merged

out of your head. I love it. Let's move on to talking a little bit about your team and hiring

things like that. And there's just going to be kind of a grab back set of questions.

What does your current PM team look like, either number-wise or just ratio and just PM-wise?

We're about 13 PMs at a ramp at probably over 100 engineers. So I try to keep

missed the 1 to 8 to 1 to 15, depending on the team. Obviously, B2B is slightly more complex

because you're dealing with pretty strong marketing team and pretty nice Trump sales team and pretty

demanding customers that you have relationships with. So I've seen ratios be a bit lower than the

BDC space. But yeah, that's a little bit of the team today. And they're organized by those teams,

by those customer pain points. And I have this note from before you said that you reached

100 million ARR, and that's a run rate. I'm not recurring revenue at that point. I imagine rate

with 50 people, which is incredible. And so just kind of on that point,

how do you do so much with so few PMs especially? Do you have anything that you figured out that

ends up being really important there? I think that by eliminating or reducing the size of the team,

we've forced other people in the company to think like PMs. And I think it's been a huge value add

to our culture. When I say product, people think about product management, but I actually think

product is anyone that actually reports into our CTO. And that's product engineering,

product design, product managers, product data scientists. So making everyone feel like a PM

is a great way to get leverage as a PM. And that means basically empowering the designer to think

about the actual specs and priorities and scopes more than you or empower the engineer to take

something that's fairly lightweight in terms of a spec or direction and actually thinking

through it deeply and come back with some great questions that the PM hasn't thought through.

So that's one thing. The second is that we invested early on in product operations, which was

a team that also reports to me that basically focuses on the operational functions of

product that's everything around, whether it's project management or issue management or release

management or enablement and content, beta and customer research, they basically are tasked with

a lot of the work that needs to get done to continue shipping products and scaling product

development. And then lastly, just cutting as much of the low leverage work that PMs often get

sucked into. So for example, we never write a ticket. We don't spend much time in linear,

which is our ticket management system. We basically, our contract is the vision and the

priority and a very high level spec and everything else is pushed on the engineering teams. And I

think that's when engineers actually are also able to move even faster because they can create

whatever tickets they want. They can break down the work that they want. They are accountable for

the projects that they're driving and that increases trust and moves things faster as well.

That makes a ton of sense. Basically, you distribute the PM job that other companies put

on the PM across other team members. So if you had to think about just what is the core

product manager job at RAMP at this point, I imagine from what I've been hearing, it's

strategy, vision, aligning the team, what else kind of plays into that just bullet point wise,

a few things that come to mind. Team building. So building a culture within the pod, because

oftentimes your managers are no longer in your team. Engineers might report to different people,

designers might report to different people, PMs might report to different people. So

actually building a team culture within the pod is really, really important. And oftentimes,

it falls on the PM to create those off-sites or to create those ideation sessions or to find ways

to have fun as a team. The second is making sure that the team is humming in terms of the actual

focus areas and then protecting the team from stakeholders that might want to have an opinion

or want to have an update or want to schedule certain meetings. So protecting that core team

from that chaos and then being at the central point of contact if someone has a question or

needs something and then being able to bring in the right person at the right time. So

those are the different things that is also really important to mention.

Going back to a note that I made earlier, you talked about how a lot of this

advice you're sharing in the approach to product at Ramp is kind of assuming that the team is A+,

the engineers are A+, the designers are A+, somebody listening to this, they may be wondering,

are my engineers A+, or not? What comes to mind is ways that you could get a sense of this is

a team that can operate in this way versus, no, we're never going to work in this way and maybe

we should shift the way we work or I should get work somewhere else.

Great question. It's very hard to identify. A few things. One is, does the engineer want to win

in the market? Does the engineer really care about winning against competitors,

winning the hearts and minds of the customer? Do they understand the business context in which

they operate, by which they need to do that? Are they curious about how the company makes money,

about what customers love and don't love, about what the most important project is and why it's

important? They're asking you questions about the business outside of just the engineering domains.

Are they able to execute on what they said they were going to execute without your help

or do you actually need to feel like you need to be behind them? Are they the one actually setting

the pace, asking you to keep up, keep up with your specs, keep up with your decisions, respond

more quickly to the things that are blocking them, bringing more PMs or more designers to do more

things? Are they being proactive in different channels where you think it's actually your job

but actually don't jump in anyways? For example, we have different Slack channels with a bunch

of people sometimes asking questions or raising issues or having blockers and you have engineers

who are just jumping in and explaining how a feature works, getting the feedback and fixing

a bug proactively. You may think, well, that's not the priority I need to control with engineers

are doing. That's not your job actually. That's not your job. Your job is to make sure that they're

aligned with the long-term vision and that they can deliver what they've committed to

but on top of that, they can do whatever the hell they want and if they're taking on something that

puts the things that they committed to at risk, they'll communicate that. So again,

that proactiveness, that desire to help, that desire to improve, that accountability on their

product, if their product isn't performing, if their product has feedback, are they doing it

themselves or they need you to push them? Those are all like mentality and culture aspects. I'm

not even getting into the technical rigor and the quality of their systems and the velocity of code

because I'm not a good judge of that. That's not really my role. But those are the things

that I would immediately look at that I think is just fundamentally different in the engineering

team that we built at Ramp versus others. It's just a big part of the culture shift

and the culture that we've been able to build. That's an awesome answer. And I think as a PM,

you often don't want your engineers and designers to have such strong opinions and to be so on top

of everything because they're just like, oh, no, okay, here's what I think we should actually do

with engineers of all these opinions. And what you're saying is that's what you want to lean into,

assuming you trust that they know what they're doing and can actually get things done.

And so it's kind of like a catch to a little bit. But I think that's a really unique culture

and approach. And so that's an awesome answer. And look like there's drawbacks to that culture,

right, where you get to like a radically empowered engineering team that thinks that they know the

product better than the designer or the PM, and they push back on the designs or they disagree

with the PM. But I'll take that culture any day compared to a culture where they're just

taking things at face value and not challenging the thinking and not actually

thinking from their own perspectives. And it's sort of like, I'll take someone on my team any day

that challenges what I tell them to do or what I think is important. And it's maybe a bit harder

to manage, but it'll make me think way deeper about what I'm asking them and what I think is

important. And I'll grow as a manager much faster because of that.

I love it. Two final questions. One around hiring. When you're interviewing people,

what do you look for? And what does Ramp look for? That maybe other companies don't value

as much as they should, or maybe overvalue. What do you look for that you think is unique

that helps you hire this A plus team?

We look for people who have a very strong desire to have impact. And the best way to

assess that is the impact that they've had or the reason why they are switching jobs.

So again, it goes back to what I was mentioning earlier in the chat, which was,

velocity leads to people wanting to join because they want to have velocity. And the best signal

of that is I'm leaving because things got too slow. Things got too bureaucratic. I missed the

old days where we were just building and shipping and launching. I look for people who can think

deeply. So I'll go super deep into a decision, a trade-off that they had to make. And I'll

really just scratch at that until I get to a deep understanding of how they make decisions

and how deep they think about things. And in general, we tend to overemphasize those two

skills rather than necessarily experience. Because experience, again, to the point around

Ramp is a unique business, it matters a lot less. You can have a lot less impact than your ability

to be hungry and your ability to think deeply. Final question. A lot of people listening to

this want to get into product management. What's your advice? I'm sure you get to ask this a lot.

How do you break into product management? What do you tell people?

Yeah. So for me, I went from college to consulting to my foreign to tech was really into

more like solutions analysts. I think that was my title. I was basically trying to implement

like a large B2B software in national banks. And how I got into product management was really

around understanding deeply the customer and understanding deeply the product

and being able to show impact on the combination of these two things. Typically, the folks that

join product teams are the highest performers outside of product that either understand the

customer really well and can advise product or understand the product very well and can serve

customers. And so my advice is for folks that want to break into that is to find a role that is

adjacent to product that enables you to have those experiences and to prove yourself. So for

example, product operations is a good one. Business operations is a good one. More consulting the

sales engineering or solution engineering is a good one. There are designers and engineers that

can become PMs as well. Typically, it's folks that can do the job as well as the PM. And what we

typically do is we give those PMs a shot or those folks a shot. So we'd give them like six months to

go into a new area and try it out. And then we basically have the engineers they work with and

designers they work with actually make the call as to whether or not they would want this PM versus

another PM on the team. Is there anything else you want to share before we get to our very exciting

lightning round? Yeah, I mean, first thing from First Principles, don't take everything I'm saying

at face value. And second is back to talent that a huge part of our success was the early

team that Kareem built on the tech side. And so I can write blogs all day on how we increase

velocity. But if there's one thing to take away from this is that empowered and talented engineers

and designers are the biggest reason why Ramps was so successful. And it's something that

requires a ton of focus. I mean, early on for the first year at Ramp, Kareem or CTO was only

focused on that. It was hiring the best talent. He was a lot less interested or focused on our

product strategy or product market fit or even our revenue. It was all about bringing in the best

engineers and the best designers. And that has had compounding effects on the company of the team.

And I think an important element there is the initial people you hire end up impacting the

next batch and the next set because they see, wow, this person is working at Ramp. That's

incredible. I gotta look at that. So there's an early compounding effect too that happens.

Exactly. Well, with that, we've reached our very exciting lightning round. I've got six

questions for you. Are you ready? Yes. What are two or three books you've recommended most to other

people? Because I work a lot. I try to read things that are completely outside of work. I don't

think I can get through any fiction or nonfiction book that's often recommended. So anything that

will pull on your heartstrings and try to make you more human. When Breath Becomes Air is a really

good one that I often recommend. Amazing. Love that one. Favorite recent movie or TV show?

I started watching The Bear a few weeks ago. I think it's a great show around leadership,

around how a different industry operates, restaurant industry, my dad owned a restaurant.

So I got a little bit into that. And all about teamwork and quality versus velocity,

of personal and professional stress. So I thought that was a really good learning.

Wow, that move, that show makes me really think of ramp. That makes a lot of sense.

It's just, it feels very, everything is just crazy, moving fast. I'm just so stressed watching

that show. I haven't watched the second season yet. You should come to our office, probably very

similar. Just delicious food sandwiches and their velocity. Favorite interview question you'd like

to ask candidates? Yeah, I asked, what's the hardest thing you've ever done? And I asked that

because working at ramp is hard. I want to understand what hard means for them. I want to

understand why it was hard. I want to understand how they overcame that difficulty, how they worked

with other people to overcome that difficulty, and how much agency they had in overcoming that.

So it's a really good sign around what is difficulty to them and how much work they put

into overcoming that. What is a favorite product you've recently discovered that you really like?

So my partner bought me this Whoop recently, wearing it now. It gives you this real-time stress

signal. That's pretty helpful. But I think it's a great product in terms of just

actionable insights. It's very data-driven. So it'll tell you, you'll be like a daily journal

of all the things you did that day. And it'll correlate what you did that day to your recovery

score and how healthy you are for that day. And so it'll give you insights around how certain

actions you take will have impact on your next day's health, which is all about heart rate

variability. I thought it was just a great way to continue to focus on your health. I think

running a team has a huge impact on your physical health and your mental health. And I think

you are an athlete at a high-growth startup, or even a small business or a large company,

and focusing on the health is really, really important. So any tools like the Whoop to invest

into that is great. That was a really good pitch for the Whoop. I've never wanted one,

but now I do. Okay, next question. What is something relatively minor you've changed

in your product development process that has had a big impact on your team's ability to execute?

It's something I've changed is more something that our head of design Diego has changed.

Basically, having designers spend more time creating more visionary prototypes and then

sharing those out in new videos, it just has just huge impact on how exciting work is and how excited

the team are. And so just providing that clarity is massive. And I think just again,

Figma and Loom and prototypes that actually are interactive so people can actually play around

with it is a huge way to unlock velocity. Final question. I've already asked you about this

a couple times, but I'm curious if there's any other productivity tip or tool that you'd recommend

to listeners that you haven't mentioned yet? Turn off notifications, quit Slack when you're

doing deep work. Check your emails once a day and just like thoroughly go through them like five

minutes. They're oftentimes most of them useless. Check Slack only at the top of the hour. Use Slack

snooze or reminders. I mean, this whole other podcast, we can talk about Slack channels and

how to organize that. But just get really good at the tools you're using. I think the first

year of consulting, we just got really good at Excel and Excel shortcuts. And it was a big

part of our training. And so just train yourself and train your teams on how to use their tools,

how to use your calendar, how to use Slack, how to use email, whatever the tool you've designed

as the right tool for you. Be dogmatic. I mean, what ramp is a tool at the end of the day? And

we're helping finance teams more efficient. So let's let's talk through that and do that with

our own tools. I think we've had just enough velocity in our chat. I think we're going to hit 100

million downloads. I think we built an A plus team here. Jeff, thank you so much for doing this.

Two final questions. Where can folks find you online if they want to ask you any other questions?

And second question, how can listeners be useful to you? You can find me on Twitter and LinkedIn,

Twitter is Jeff in tech. How can they be useful? Honestly, I mean, your your your attention is a

gift. If you're interested in joining us here at ramp, we're obviously hiring incredible people.

So if anything that I shared resonates with you, and if you want to join the team, we're hiring

across product engineering design. But you know, most importantly, you know, be kind to yourself.

I think, you know, I've been a huge listener to this podcast. It's an honor to be here.

I know very little, hopefully, some what I shared was was meaningful to you, but

keep keep the growth mindset, keep keep thinking from first principles, keep,

keep investing in that growth, and be patient. It takes it takes a lot of time.

What a beautiful way to end it. Jeff, thank you again so much for being here.

Thanks a lot. This was a lot of fun. Same. Bye, everyone.

Thank you so much for listening. If you found this valuable, you can subscribe to the show

on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a

rating or leaving a review, as that really helps other listeners find the podcast.

You can find all past episodes or learn more about the show at LenniesPodcast.com.

See you in the next episode.

Machine-generated transcript that may contain inaccuracies.