0:00
So when I joined, we were about 10-ish folks, about eight engineers, and in three months, we built a competitor to Amex.
Search this video
0:04
Six months after that, we built a competitor to Expensify, both publicly traded companies.
0:09
We hit a hundred million in annual revenue.
0:09
I think we were under at that point, 50 total in the R&D department, less than four engineers and three PMs.
0:17
And then we started expanding into accounts payable.
0:17
It was three engineers, one designer, one PM three months, and they hit out of the park.
0:21
And that product is moving in billions of dollars a year.
0:26
I think the recipe for all this is ...
0:31
Welcome to Lenny's Podcast, where I interview world-class product leaders and growth experts to learn from their hard one experiences building and growing today's most successful products.
0:37
Today, my guest is Geoff Charles, who is VP of Product at Ramp.
0:41
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.
0:50
If you're not familiar with Ramp, they're the fastest growing SaaS business in history, getting to over $100 million in annual run rate in two years, which is just wild.
1:01
And as you'll hear in this episode, they did this with 50 people.
1:06
In our conversation, Geoff shares how they operationalize a culture of velocity, how they do a lot with 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.
1:22
My advice is to seriously study how Ramp operates because there's a lot to learn from their success and their approach to product.
1:32
Enjoy this episode with Geoff Charles after a short word from our sponsors.
1:38
This episode is brought to you by Ezra, the leading full-body cancer screening company.
1:38
I actually used Ezra earlier this year unrelated to this podcast, completely on my own dime because my wife did one and loved it.
1:50
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.
1:55
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.
2:00
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.
2:11
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.
2:26
Half of all men will have cancer at some point in their lives, as will one-third of women.
2:31
Half of all of them will detect it late.
2:31
According to the American Cancer Society, early cancer detection has an 80% survival rate compared to less than 20% for late stage cancer.
2:43
The Ezra 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 may be is what I have, or fatty liver disease.
2:54
Ezra 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.
3:07
Their scans are non-invasive and radiation free.
3:12
And Ezra is offering listeners $150 off their first scan with code Lenny150. Book your scan at ezra. com/lenny. That's E-Z-R-A. com/lenny.
3:30
This episode is brought to you by Coda.
3:30
You've heard me talk about how Coda is the doc that brings it together and how can help your team run smoother and be more efficient.
3:35
I know this firsthand because Coda does that for me.
3:40
I use Coda every day to wrangle my newsletter content calendar, my interview notes for podcasts, and to coordinate my sponsors.
3:45
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.
4:05
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.
4:14
Coda puts data in one centralized location regardless of format, eliminating roadblocks that can slow your team down.
4:20
Coda allows your team to operate on the same information and collaborate in one place.
4:24
Take advantage of this special limited-time offer just for startups. Sign up today at coda.
4:30
io/lenny and get a thousand dollars startup credit on your first statement. That's C-O-D-A.
4:36
io/lenny to sign up and get a startup credit of $1,000, coda. io/lenny.
4:45
Geoff, thank you so much for being here. Welcome to the podcast.
4:53
Thanks, Lenny, it's great to be here.
4:53
So you are head of product at Ramp.
4:53
For people not familiar with Ramp, could you just give us a brief overview of what it is that Ramp does?
5:04
Yeah, Ramp is a finance automation platform and corporate card solution for small and medium-sized businesses.
5:09
So we help businesses essentially automate most things across expense management, card payments, bill payments, and accounting.
5:13
And we've helped 15,000 of such businesses automate a lot of their back office to focus on what truly matters, which is growing their company and providing value to their customers. Okay.
5:24
So what you didn't mention is some of the most interesting stats about Ramp and the business and the growth story of Ramp.
5:33
So could you just also share some stats about just the success of Ramp and a sense of just how rare the story of Ramp has been? Yeah.
5:39
I mean, we were one of the fastest growing FinTech and B2B SaaS companies of all time.
5:44
I think we've hit a hundred million in annual revenue for the first two years and we've continued to grow significantly since then.
5:53
I think every day, about a thousand users join our platform.
5:53
And this year, we've grown and hit 600 million in savings, 8.
5:58
5 million in hours saved for our customers by controlling spend and automating a lot of the manual tasks.
6:04
So we're continuing to grow fast, and in terms of just raw transaction volume, we have crossed 10 billion in [inaudible] spending on the platform and just getting started.
6:17
You've glossed over that stat of just Ramp is essentially known as the fastest growing SaaS business in history and also FinTech business.
6:26
In two categories, the fastest Ramp to $200 million in run rate. Yeah. Okay.
6:33
So for that reason and many other reasons, there's a lot of interest in just how Ramp operates and how you all approach product and we actually previously collaborated on a newsletter post on how Ramp builds product.
6:45
And that newsletter post is now the eighth most popular post on my newsletter across hundreds of posts that are ever written and even more than how Figma builds product and how Snowflake builds product and all these other incredible companies.
6:55
And so, clearly, there's a lot of interest in how you operate.
7:00
So I'm really excited to get into the meat of how you all work.
7:04
And if anyone read this post and has any sense of just how you all operate, there's this one word that immediately comes to mind when people think of how Ramp operates and that word is velocity.
7:16
So I want to start there.
7:16
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 working at Ramp? Yeah, absolutely.
7:24
So you mentioned it, you nailed it.
7:29
Velocity is everything at Ramp.
7:29
It's how we design our product development process.
7:33
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.
7:43
I think 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 which path we wanted to pick, but rather how fast we were able to execute on that path.
7:55
And so velocity was ingrained from the early days on just building, shipping, and iterating.
8:00
And I think it's a decent metric for how companies and teams perform.
8:06
You might say, "Well, what's the impact of that velocity?"
8:06
But realistically, teams that have high velocity are able to actually get to that impact over time by iterating.
8:17
It's also a great way to have positive selection in terms of talent because talent wants to join companies that ship fast.
8:23
And a lot of people who join Ramp, I ask them, "Why are you interested in joining the company?"
8:28
And 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."
8:31
And it's also a great way just de-risk decisions and decision making.
8:35
If the cost of that decision is really low, then you're able to essentially simplify a lot of decisions.
8:44
To build on that, there's a lot of companies that say they move fast, that talk about moving fast, that say 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?
9:01
Can you just share an example or two of what velocity actually looks like at Ramp and what the reality of that is? Yeah.
9:11
So when I joined, we were about 10-ish folks, about eight engineers, and in three months, we built a competitor to Amex.
9:16
Six months after that, we built a competitor to Expensify, both publicly traded companies.
9:23
We hit a hundred million in annual revenue.
9:23
I think we were under at that point 50 total in the R&D department, less than four engineers and three PMs.
9:28
And then we started expanding into accounts payable.
9:34
We basically gave a team goal of building a competitor, Bill. com.
9:39
It was three engineers, one designer, one PM three months, and they hit out of the park.
9:44
And that product is moving in billions of dollars a year.
9:49
And I think the recipe for all this is constantly small teams have a single-threaded focus, give them the resources they need to execute big lofty goals, very tight timelines, and then shield them from the chaos that is the rest of the organization.
10:03
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.
10:19
So it's like gravity and you need gravitational pull to this thing. Okay.
10:24
I want to double click on some of these points you just made.
10:24
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.
10:41
There's a couple more things.
10:41
Let's talk about the single-threaded piece a little bit. What does actually mean?
10:45
What does that look like?
10:45
There are very few people who are able to execute extremely well in more than one thing, and it's especially true for individual contributors.
10:50
And so what I mean by single threaded is there's only one goal, one thread, that they're waking up in the morning to focus on.
11:01
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 any type of research or any type of production engineering or any type of process that's outside of that single goal.
11:18
And it almost goes as far as just 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.
11:29
What's an example of that?
11:29
Either maybe someone's working on it now or in the past that's a good example of a single-threaded goal or team. Yeah.
11:34
So, for example, we launched a flex product over the last summer, that was a single-threaded team just focused on eCommerce companies and their needs with more cash flow conversion and cash flow smoothing.
11:47
And so we kept that team again just purely focused on just shipping that product and hitting that goal.
11:53
And if they were ever distracted by something else, I don't think we would've hit it.
12:02
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 one PM to work on this for a day?"
12:13
I know there's not going to be like, "Here's the rule of step one, two, three, but how do you actually approach shielding teams from things that just are constantly on fire?
12:25
So, for example, on bugs or issues like that, we have individuals that are protecting those teams from those issues.
12:29
So we have a rotational program on production engineering, for example, where engineers are protecting the core team from escalations, from bugs, from issues.
12:39
We have product operators that are protecting the PM from the chaos that is documentation and escalations and release management and enablement customer requests.
12:53
So we have layers of protective tissue to core teams, but I would say for any of these big bets, you basically have to pull folks from different teams and reorganize a sub-team.
12:59
And that team typically doesn't have responsibility on any existing product because these are all fairly new products.
13:09
I think it gets more challenging when you go from one to two rather than zero to one.
13:14
You also mentioned this idea of lofty goals and that's something I've seen a lot.
13:14
At Airbnb, there was a ...
13:19
It is very known for lofty goals.
13:19
Brian was famous for going to meetings where people present their goals and their plans and he's like, "How do we 10X that?
13:23
What do you need in order to 10X that goal?"
13:28
And then that ends up being your goal and often works shockingly, sometimes burnt a lot of people out.
13:34
How do you think about for just finding that balance and, I don't know, is there an example of just like, "Here's a really ambitious goal?"
13:42
Or maybe the question is just, how do you find the balance of ambitious but not just impossible? Yeah.
13:46
So the first thing is we have market comparables, which is very exciting for us.
13:46
So when you look at Bill.
13:54
com, they're a publicly traded company, Expensify, publicly traded, or Concur or Coupa, these are all large players that are actually very motivating and largely de-risk some of the business decisions you're making. That's existing markets.
14:10
We've also been able to create markets.
14:10
Spend management was an actual market before we and other competitors jump into it. So that's motivating.
14:15
Go attack that market and go drive that revenue is very motivating.
14:21
We also use designs as a way to motivate teams.
14:21
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.
14:37
So we constantly go back to these cornerstone, Loom walkthroughs of Figma prototypes that the design spend a lot of time talking through and I think that's a big part of the motivation.
14:48
And so both of those things combined, I think, helps us stay motivated.
14:48
I think there's a constant pushback to like, "Okay, what can we actually achieve?"
14:53
But you're able to move super, super fast if you have those two things in mind, the market and the revenue goal, because very revenue driven as a company and the designs that can really keep you anchored on what this could look like.
15:09
I know another important ingredient to how you all 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 micromanaging them.
15:22
I think you have this concept of context over control.
15:27
I'm curious how you actually operationalize that.
15:27
A lot of people love the idea of empowering their teams and then they do that and then they do the wrong thing or they take too long or they set the wrong goals.
15:37
So how do you actually make that work and create empowerment within your teams?
15:42
Yeah, 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, Karim, was extremely hands-off in terms of the actual pride decisions because we were extremely aligned on the goals themselves.
15:53
And so that's where you really just start alignment is, what is the goal that you're going after?
16:05
What is the hypothesis that you have to reach that goal?
16:05
What is the data by which you're coming up with that hypothesis?
16:09
And then what is the potential solution to test that hypothesis?
16:15
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.
16:25
You should be debating the interpretation of data, you should be 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.
16:37
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.
16:46
And if you do that, you realize that the solutions actually can come much better from teams that are much closer to the ground.
16:53
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.
17:04
And I spent 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 in certain forms that they're not a part of and my responsibility to represent them and then share back the context for them to make better decisions over time.
17:23
That touches on a phrase that's come up a couple times on this podcast that a leader's job, you're essentially the repeater in chief, reminding people of strategy, vision, things like that.
17:33
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.
17:46
And I'm curious just to make it even more real. Either ...
17:46
Is there an version 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?
17:57
What's most different there?
17:57
Is it the product reviews, you're not as involved in design iterations?
18:01
Where do you come in to actually give feedback?
18:06
How does that actually look like working at a Ramp versus another company?
18:11
I think that the contract between me and the team is really their strategy and their roadmap.
18:20
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.
18:24
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.
18:36
And their role is to highlight risks and highlight one-way decisions that they need my input on.
18:43
And, again, it didn't use to start that way.
18:49
I mean, when we first started, it was just me and another PM.
18:49
I was fairly micromanaging in some areas.
18:54
I think you build trust over time and you start having these contracts.
18:59
And so as, I suppose, good more senior, they're basically publishing out the API by which they interact with me and we basically align on what's most important on each one on one.
19:09
So I basically have teams ...
19:09
All my directs post their goals every week first thing Monday.
19:16
The goal there is to also have them review each other's goals.
19:21
I have a one-on-one template that I basically use to keep on track of how progress is being made, but I certainly don't spend the time in the one on one going into that.
19:26
I spend the one on one just focusing on what they need from me.
19:30
And then on a biweekly 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.
19:44
What about the product experience itself?
19:44
Is there design review that happens?
19:44
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.
19:52
I think when the first couple of years, it was more asynchronous and ad hoc process.
19:57
And once you hit 10, 15 PMs 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.
20:11
I think we're relating 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 are asking specifically for what type of feedback you need and you're highlighting the key risks and tradeoffs that you're making implicitly in that review.
20:37
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.
20:43
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.
20:53
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.
21:05
Yeah, that came up actually.
21:05
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.
21:21
And they find that quality goes up as your product velocity goes up.
21:26
You'd think it'd be the opposite.
21:26
The faster you move, the lower quality ends up being.
21:26
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 huge chunk you have to wait for people to review and release and break things, ends up being higher quality.
21:40
So it's very much aligned with our experience. Yeah.
21:44
And you have to create a system by which those folks are getting that feedback.
21:44
And so we've really focused on what are the control mechanisms that ensure that your high velocity doesn't tank the business.
21:57
And so examples of that is we have a voice of customer processes where every single negative review that is shared to our products is shared back to the tech lead, the PM and the designer on a monthly basis.
22:13
We report back NPS and CSAT.
22:13
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.
22:25
And that's a core contract that the team has to maintain a low or lower part of operational burden.
22:30
We also have bugs and issues being directly assigned to the engineer that's on call.
22:37
So they feel that pain and then they can continue, to your point, leveraging velocity to solve those problems.
22:50
Velocity is just a magnitude, it's not necessarily a specific direction.
22:55
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?
23:06
We don't have a bug backlog.
23:06
We fix every bug once they're surfaced almost. Okay.
23:12
So it's part of the production engineer's job really just to fix those things.
23:15
I think where we get to nuances, like 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.
23:34
And if that number is slightly elevated, we're basically saying, "You can't ship any new features, you need to fix these things."
23:40
And so, yeah, there's just these types of controls, but basically trying to standardize across the teams.
23:45
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.
23:49
As long as you maintain those metrics, you can do whatever you want.
23:55
But the moment that these things are under the red, you can't ship new features and you need to revert back to the [inaudible].
24:03
Something funny that happened after our post on how Ramp builds 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.
24:14
And they're just like, "How do we prioritize velocity? How do we move faster?
24:19
Look at this, this culture of velocity that Ramp's got, why don't we have that?
24:19
What do we need to create this culture of velocity?"
24:23
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.
24:34
So I was like, "Oh, man, we're creating this new pressure that this one company is doing things really well and now everyone has to do it this way."
24:38
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.
24:53
PMs, we can't do anything by ourselves. We're very useless. We're force multiplier.
24:58
So the one thing that I'll highlight is behind Ramp's velocity is a lot less the culture that I try to amplify, but a lot more the quality of the engineering and design talent candidly.
25:11
And so I'm just standing really on their shoulders here.
25:11
And so advice number one is ensure that from the top down there's an investment in R7D as a first-class citizen that you're paying upmarket, 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.
25:34
And then you have a culture of empowerment.
25:34
And what that means is ...
25:34
And it's hard to get right.
25:37
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.
25:45
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 radically empowered.
26:05
The second thing that I would say is the biggest waste of time is meetings and status updates.
26:05
And I think that oftentimes CEOs would say, or leaders would say, "Hey, we've got increased velocity, therefore let's just add these status meetings and let's add all this process and all these documents and all these ways to hold teams accountable."
26:24
And that's just a huge way to demotivate people.
26:24
And so I've never had a status meeting.
26:31
I've never scheduled a status meeting. Statuses are done async.
26:36
They are done in the systems by which they operate and largely they should be in real time.
26:42
And meetings should be all about collaboration, ideation, decision-making, et cetera.
26:42
So just look at your calendar and just kill as many things as possible and kill just unimportant process.
26:56
And the last thing that I would say is oftentimes leaders say, "I want to move super fast," but they'll say, "I want everything under the sun.
27:02
I want this and that and that."
27:02
An example of that at Ramp is always like the debate between adding more products to one segment or going to a different segment, SME versus mid-market versus enterprise.
27:11
And you ask the CEO, "Hey, which one should we do?"
27:18
And they would say, "All of it," because they think that the more goals you have, the faster you'll be able to execute.
27:22
And I think there's just a limitation to that.
27:28
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.
27:33
So here's what we're doing and here's what we're not doing and why and which one would you pick?
27:37
Give them a menu of items.
27:42
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.
27:47
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.
27:57
You're actually not pushing back, you're increasing velocity.
28:01
What I'm hearing from a meta point you're making is use that ask as leverage to change the way things are operating. Is that right? 100%.
28:07
You can't ask for velocity and not have empowerment and not trust and not eliminate process and not increase the focus.
28:13
And that requires some serious tradeoffs that oftentimes leaders, especially those coming from more traditional industries, are not comfortable with.
28:24
And it was the biggest breath of fresh air when I joined Ramp was how committed the team was.
28:30
The last thing I'll say is there's nothing more motivating than a leader just commenting, "This is awesome," on a random project channel at a random design crit.
28:42
I know that our founders are just reading the projects that they actually care a lot about and the engineers know that.
28:49
And so there's just a general excitement on just building great cool shit.
28:56
And engineers just feel that and they're also highly motivated by that.
28:56
So that's another piece of advice is just being able to stay plugged in to give engineers the opportunity to present to those leaders present in the all hands.
29:10
That's also a great way to amplify the culture.
29:17
It's a good segue to this idea of burnout.
29:17
Hearing a team operate incredibly fast and velocity, velocity, velocity makes you think about, are people burning out?
29:24
Are they enjoying their work?
29:29
How are they sustainably going to last at Ramp?
29:29
I'm curious just what that's like and how you think about avoiding burnout for folks that are just constantly shipping, shipping, shipping.
29:38
I think the debate around working hard and burnout misses a key point, which is all about how much impact and how good you feel about the work that you're doing.
29:46
And I think that for me, when I felt burnout, it was actually at the time where I had the lowest amount of velocity.
29:53
But it was when I felt like I was putting a lot of effort into things that weren't actually moving.
30:03
And so I actually think velocity is a way to potentially avoid burnout.
30:03
I'm not asking people to work endless hours a week.
30:07
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.
30:13
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.
30:26
And I think sometimes organizations, especially as they grow, make that really hard.
30:31
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.
30:41
Another parallel of this is running.
30:48
The best runners are the ones that love running and they feel like running isn't a chore, work isn't a chore.
30:53
And I think as a runner, I try to evaluate that whenever we're doing something hard, that's challenging, that's exhausting.
30:59
If you love what you do, you feel much better about the amount of effort you're putting into it.
31:04
And work doesn't feel like work. I find the same thing.
31:08
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.
31:13
It was just like this very long stressful project but ends up ...
31:18
Looking back, you're always like, "Wow, that was so much, that was so cool. I learned so much.
31:23
We shipped so much interesting stuff, made so much impact."
31:26
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.
31:39
And you said something there, which is meaningful to you.
31:45
So not meaningful to your boss or your boss's boss's boss, but meaningful to you.
31:50
And I think that that's the role of management is to make everyone on your team feel like it's their goal.
31:57
And the way to do that is to, again, align on that goal and give it to them and to problems to solve.
32:04
If everyone feels like it's their team, it's their company, their mini company, then they will radically avoid burnout.
32:10
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.
32:19
One of my favorite quotes that you have shared is, any second you spend planning is a second you don't spend doing.
32:28
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.
32:35
On the other hand, 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."
32:44
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.
32:53
I would say when new joiners come at Ramp, I intro myself and I talk about our product strategy.
33:00
And in the meeting with an apology, I say, "You signed an implicit contract joining Ramp.
33:07
It's one where we prioritize velocity over almost everything else.
33:07
What that means is it'll be somewhat chaotic.
33:12
We'll ship things that don't work.
33:12
We will change our products without necessarily fully enabling you and you'll have to constantly be on your toes whenever you load up a demo instance."
33:23
And I think that it's 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 actually innovate, that we don't continue to provide value for our customers.
33:41
I think there's certain things that we plan for.
33:41
And so the question really is 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.
33:56
And so those things for us are large market moments where we have products, marketing, and sales all coordinating these big moments.
34:03
And those typically happen maybe once a quarter, once every six months.
34:11
It's basically your marketing calendar.
34:11
We need a plan for that, for sure, but it's oftentimes a low percentage of our total R&D focus.
34:15
And so it's totally fine for each team to be somewhat autonomous, somewhat chaotic within their pod.
34:26
They're extremely clear, but for the outside in, it might be very chaotic.
34:26
But be very accurate on the things that truly, truly matter.
34:32
The rest actually doesn't matter.
34:32
You don't need a lot of accuracy and confidence on when specifically certain features will be live.
34:36
It's much better to spend whatever time you would spend trying to create accuracy and creating velocity.
34:48
I love that you set expectations very clearly upfront.
34:48
That seems really important to be successful at a company like that.
34:52
It also just makes me remember every successful startup is extremely chaotic.
34:59
As much as it may not feel like that on the outside, it's insanely chaotic.
34:59
Things are constantly changing.
35:05
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 ...
35:11
We're reorging every six months.
35:15
People are leaving and coming and teams are shifting and priorities are always adjusting."
35:19
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."
35:28
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.
35:36
I mean, oftentimes, people use that excuse to not have a very strong strategy.
35:44
And I think that for us, we've always been, from the start, the spend management platform that helps you spend less. Our strategy ...
35:51
I share an annual newsletter around what we did and what we're going to do next year.
35:57
And it's oftentimes pretty spot on in terms of the goals.
36:01
Again, the goals and the value and the problem and the vision, that's consistent.
36:07
The specifics, the timing, the quarterly scopes, all these things, yes, 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.
36:18
We've been extremely consistent from the start and I think most of the products that we build, most of the code that we written, is in the customer's hands and hasn't been ripped away.
36:28
And I think that speaks a lot to velocity, too. Awesome.
36:33
That was a good addition.
36:33
I didn't mean to say if your place is chaotic, it's no problem.
36:38
It's that side effect of growth and hypergrowth as things are going to be pretty chaotic.
36:44
This episode is brought to you by Attio, a new type of CRM that's powerful, flexible, and built around your data.
36:51
Traditional CRMs were built for a different era with totally different speed, scale, and data demands. Attio is different.
36:57
It allows you to quickly build a CRM that matches your unique workflows and data structures.
37:03
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.
37:13
You'll also have real-time dynamic reporting at your fingertips.
37:13
No more slow deployments, outdated user experiences or tedious manual data input.
37:18
With Attio, you can build and adapt your CRM on the fly no matter your business model or company stage.
37:28
Attio is the CRM for fast-growing startups.
37:28
Get started today and get 15% off your first year at attio. com/lenny. That's A-T-T-I-O. com/lenny.
37:34
So you've talked about strategy a couple of times and I want to dig into that a little bit.
37:44
So there's maybe a couple directions we can go.
37:48
One is you talked about this contract you create with teams of a strategy.
37:48
So maybe let's just go there.
37:53
What does that actually look like?
37:53
What's part of this contract?
37:53
And is there a document you put together to lay this out?
37:56
Strategy means a lot of different things.
37:56
In my mind, strategy is about how do we get to our goals?
38:01
And it's not a roadmap and it's not a vision, it's something right in between that.
38:07
So the first thing you need to do is align on what are the goals, what do you want to see in the world?
38:11
Then the hypothesis, why do you think this will work?
38:16
Figure out why we're uniquely positioned as a company to get after that goal.
38:23
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.
38:31
So these are the bullet points of the contract essentially of a strategy document? Correct.
38:35
And now every pod basically spends time writing that doc for themselves.
38:35
So the pods are basically organized against outcomes, so they should be very clear on their goals and they publish these things out.
38:47
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 into.
39:05
But that's a little bit of how you also create a culture of empowerment where each team is thinking about these things thinking like you.
39:15
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.
39:25
How long does planning roughly take and how often do you do this strategy rethink?
39:30
We've gone through iterations, good and bad, I think.
39:30
For a period of time at Ramp, we created OKRs with financial goals and quotas to some extent for different teams.
39:36
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.
39:49
And it became very political, very annoying.
39:49
And largely, our entire R&D team was like, "Look, we're just going to execute on the roadmap, screw the OKRs."
40:00
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 are the company priorities and it's much more smooth and much faster.
40:18
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.
40:32
Oftentimes it's marketing and sales.
40:32
For anything that's product led, it's product. So that's one contract.
40:38
And then we have our roadmap, that's the second contract.
40:43
One of the bullet points you mentioned is this idea of being, what are we uniquely positioned to do?
40:46
Can you talk a bit more about that and maybe what's an example of something you worked on, how you described why you're uniquely positioned to win at that?
40:55
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.
41:02
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.
41:17
And an expense was an invoice to the employee.
41:17
And so there was a lot of parallels between these two things.
41:21
It was all about having a liability.
41:21
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.
41:38
So we believed that we were uniquely positioned to get after that space because we already had money movement.
41:45
We already had some type of liability.
41:45
We already integrated with accounting systems and we had a pretty strong risk process that can govern all that.
41:51
And the employees that were requesting to pay these bills were already on the platform.
41:56
So that's an example of a right to win.
42:01
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.
42:12
It's not something you really see in teams' docs of just why we have the right to win this.
42:18
So I think that's a really interesting element.
42:18
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.
42:26
So folks are trying to write down notes of all these little bullet points.
42:30
We'll link to a doc that has all these things.
42:34
What do you think of OKRs and how do you approach OKRs as a part of this planning?
42:39
I largely stay away from OKRs from a product perspective. Go on.
42:43
I think that, again, strategy, financial plan, roadmap.
42:47
I think where we landed on with OKRs were really around more cross-functional things in nature.
42:53
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.
43:04
But, again, an OKR is just a method to measure an objective with metrics and you can use them at various levels of granularity.
43:13
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, but they're pretty strong at more of the cross-functional side of things as well as the financial side of things.
43:29
I don't even know what separates an OKR from not an OKR.
43:29
I feel like OKRs are just a goal with some high-level statements of things we're trying to accomplish.
43:37
I don't even understand when people say they use OKRs or don't, what that even means anymore.
43:41
There's a recurring point on this podcast and other posts of just people are weary of just being obsessed with, "Here's the metric that we're going to hit and that's all that matters."
43:50
And there's a fear they lose sight of the bigger picture, what they're trying to accomplish.
43:54
But I think in the end, it's just like, "Here's what we're trying to do.
43:57
Here's some goals, we're going to hit it," because I don't know care, I don't know. I think that's right. I think that's right.
44:00
And at the end of the day, again, the contract is your product roadmap and that's the contract you have, the sales organization.
44:10
Marketing can take that product roadmap and create market moments.
44:13
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.
44:25
And so you essentially need to point back to the leader in that regard.
44:30
But I can't ask every team to try to manipulate OKRs to fit their roadmaps.
44:37
That's just completely exhausting.
44:37
We've aligned on what we need to do, let's get it done.
44:40
Something that comes across pretty clearly in the way you think and the way Ramp operates is this idea of thinking from first principles.
44:45
And it's a cliche term, 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.
44:53
And so I am curious just where that emerged for you or for Ramp.
44:59
And is there an example of something that emerged within Ramp, a new product or an idea, that was very clearly from first principles?
45:11
The most important thing to talk about here is that Ramp is a very unique business.
45:11
I mean, we're a credit card company, which is all about risk management and underwriting.
45:17
We're also a payments company because we move money between businesses.
45:25
We're also a software company because we deal with spend management and expense management, accounting. We're building for SMEs.
45:30
So we have PLG, but we're also building for enterprise.
45:36
So we are sales driven, we're everything.
45:40
And so it's really important when you're dealing with something that hasn't been done before to think from first principles.
45:45
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.
45:56
And that means you need to hire people who can think from first principles and be okay putting aside their experience.
46:04
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 X, Y, Z and I know what's best."
46:15
And they come in and they get a reality check about the complexity of our business.
46:19
And how also you can't influence teams by saying, "I've seen this before."
46:24
That's just like an anti-pattern.
46:24
You can't say, "My past company, X, Y, Z."
46:30
No one wants to hear that.
46:30
No one wants to hear that.
46:30
And surely, I thought I was coming into Ramp and I was going to apply the best product [inaudible] 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 ...
46:45
I had to go back to first principles around how products should be developed and built.
46:48
So, again, all the advice I'm sharing here, don't just take it and map it and copy paste.
46:54
Start from the first principles that we're sharing.
47:00
An example of that is our support team.
47:00
So support reports into me.
47:00
And the first principle there was saying, "Well, every support ticket is a failure of our product."
47:07
We literally have that as a quote just posted on all those channels. It's a failure.
47:13
And if the product works perfectly, no one should ever have to contact our support team.
47:20
And what better way of holding the product team accountable for support other than having support report into product.
47:29
And the second piece was that we believe that a lot of our value to our customers were because it was going to come from deeply understanding them, deeply listening to them, and moving on that feedback.
47:43
And so instead of hiring people who were focused just on resolving the ticket, we incentivized people to actually decrease number of tickets over time and decrease deflection or increase deflection.
47:56
And that required hiring a different breed of people that then became leaders in different parts of the organization as well.
48:02
So, again, we could have easily just pattern matched, look at comparables, hired people who've scaled large support teams, and just used benchmarks in the industry, but we've started from first principles.
48:11
And the outcome of that is we have an extremely low contact rate.
48:16
We have over 400,000 users on our platform and a team of agents that's under 30.
48:23
And it's a pretty crazy ratio to think about. That's wild. I missed this nuance.
48:30
So the support team reports into you and the product team? Yes.
48:37
Wow, I've never heard of that. That's cool. Okay.
48:41
So I'm going to change course a little bit and I'm going to talk about writing.
48:47
So we worked on this post together on how Ramp operates.
48:47
And I was just incredibly impressed with your attention to detail, your ability to articulate, your approach to product.
48:54
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.
49:06
And that's how this whole newsletter started.
49:06
It was just trying to crystallize what I remembered and did so that I can remember it and share with people.
49:13
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 approach of writing, helping them think.
49:25
Throughout the years at Ramp, I was often faced with a problem or a question that I couldn't answer off the bat, and I had to go back to first principles.
49:32
And the best way of doing that is to shut down your laptop, 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.
49:50
And there were a ton of questions over time.
49:50
For example, how do we ...
49:50
And it was all scalability problems that few companies have actually done successfully.
49:57
And so you have to start with your own thinking, how do we scale decision making?
50:03
How do we incentivize teams to work together?
50:03
How do we do headcount planning?
50:09
How do we allocate headcount in a fair way?
50:09
How do we avoid politics as firsthand data goes away?
50:16
How do we make decisions on doubling down versus pivoting?
50:24
All these things are really tough. And I found myself ...
50:24
You could read things and that's helpful, but I don't think that reading makes you necessarily think better.
50:31
It makes you more wise, but the best way to increase your capacity to think is to actually do the thinking.
50:45
And so that's where I see writing.
50:45
If you're able to write things clearly, you're able to think through things clearly.
50:49
It was also a way for me to effectively communicate, especially during COVID, where 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 my brand and Ramp's brand in terms of the space that then led us to hire better people over time.
51:06
So all these things worked 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.
51:22
After you thought through it, then go out and read and you'll fine-tune your thinking and you'll identify new questions to ask yourself afterwards. I love this advice.
51:34
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 build code all day and design.
51:46
This is the advantage you have as a PM.
51:52
I always think that PMs often don't really have any special unique skills.
51:56
They just have the time to do the things that nobody else wants to do or doesn't have the time to do or doesn't want to do.
52:02
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.
52:12
That ends up being incredibly important.
52:12
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.
52:21
I think that's a really good approach.
52:25
I want to ask how you actually do that.
52:25
How do you actually create these blocks of time?
52:25
There's this concept of deep work and how valuable that is to creative work and knowledge work.
52:35
How do you do that for yourself?
52:35
How do you block out time and not get bugged all day?
52:39
Because we're really anti-meeting at Ramp, I had time in my calendar.
52:39
And so what I would basically do is the Friday before I clocked out, I would look at the next week, I would look at the top questions that I needed to spend time thinking about, and I would block out that time.
52:56
I also work on one day of the weekend in terms of deep work.
53:04
I find that hanging out outside and doodling on my piece of paper, some thoughts is actually really refreshing because it doesn't feel like work.
53:17
It feels like just me just philosophizing about something.
53:17
And so, yeah, blocking out that time, finding a space where things are less busy, where you're not in a critical path either early mornings or later afternoons or a day on the weekend is the best path for it.
53:34
What do you do if someone wants to actually schedule a meeting with you or reach out or put someone on your calendar?
53:37
Do you have a policy there to protect that time?
53:41
I think that I should never really be in the critical path of anything.
53:41
So largely, I'm not available, but if they really need to get to me, they have my phone number. Cool.
53:53
The thing that I found really valuable is just on Wednesday mornings and Friday mornings, I just have this huge block called deep work time.
53:58
If you book a time during this time, I'll slap you.
54:02
And I don't know if I'm allowed to put that into meeting calendar invites anymore, but that actually worked really well.
54:07
Nobody really booked meetings in that slot.
54:11
I didn't know Zoom had a slot feature that's coming handy.
54:15
It was a Google, it was in the calendar.
54:15
It was like the calendar invite.
54:15
And I also worked usually at least one day a week and 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 have great success.
54:29
One other question along these lines around just optimizing for processing and getting stuff done and deep work time, do you have any other best practices for just being organized and staying on top of stuff, knowing there's just stuff coming at you all day every day?
54:45
If you're a manager and, like me, you're in back-to-back meetings from 10:00 to 6:00, it's very easy to be completely overwhelmed with a sheer amount of stuff you need to do.
54:52
And so I've invested over time in just a very robust but fairly simple 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 to as clearly as possible, not some vague thing, but a very clear thing and just when I need to get this done by.
55:15
I don't spend time just grooming.
55:22
So at the end of the day, I use notes.
55:22
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.
55:31
And then I spend time grooming, which is basically just trying to group things together in logical chunks, grouping the tactical versus the strategic, the important versus the less important.
55:38
I group also what other people owe me and I Slack them what they owe me and I put a reminder on Slack for when they owe it to me by.
55:48
And that way, it's just out of sight, out of mind.
55:48
I think that the high-level theme is I try to create or free up headspace for processing, not memory.
55:52
And so I just basically spend very little time memorizing anything and I write everything down.
56:00
That 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.
56:10
In the Google Space, you can pull up any document and search a bunch of documents very, very quickly.
56:15
So that's what 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.
56:40
I feel like you and I are very aligned on a lot of things.
56:40
That's exactly how I approach priorities.
56:43
Have you read Getting Things Done by David Allen?
56:47
I don't read a lot of nonfiction actually.
56:47
Okay, because what you're describing is very aligned with this approach to processing and taking to-dos, and it's what I built my approach on.
56:56
And so you naturally merged out of your head. I love it.
57:03
Let's move on to talking a little bit about your team and hiring and things like that.
57:03
And there's just going to be a grab bag set of questions.
57:08
What is your current PM team look like, either number wise or just ratio and just a PM wise?
57:13
We have about 13 PMs at Ramp and probably over a hundred engineers.
57:21
So I try to keep basically one to eight to one to 15 depending on the team.
57:28
Obviously, B2B is slightly more complex because you're dealing with pretty strong marketing team and pretty strong sales team and pretty demanding customers that you have relationships with.
57:32
So I've seen ratios be a bit lower than the B2C space.
57:37
But, yeah, that's a little bit of the team today.
57:42
And they're organized by those teams, by those customer pain points.
57:47
And I have this note from before, you said that you reached a hundred million ARR, and that's a run rate, not recurring revenue at that point, I imagine, right? Yep.
57:56
With 50 people, which is incredible.
57:57
And so just on that point, how do you do so much with so few PMs, especially?
58:02
Do you have anything that you figured out that ends up being really important there?
58:06
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.
58:19
When I say product, often 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.
58:31
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 think through it deeply and come back with some great questions that the PM hasn't thought through. So that's one thing.
58:57
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.
59:17
They basically are tasked with a lot of the work that needs to get done to continue shipping products and scaling product development.
59:29
And then lastly, just cutting as much of the low-leverage work that PMs often get sucked into.
59:34
So, for example, we never write a ticket.
59:34
We don't spend much time in linear, which is our ticket management system.
59:43
Basically, our contract is the vision and the priority and a very high-level spec and everything else is pushed on the engineering teams.
59:49
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.
1:00:09
That makes a ton of sense.
1:00:09
Basically, you distribute the PM job that other companies put on the PM across other team members.
1:00:15
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.
1:00:27
What else plays into that, just bullet point wise?
1:00:27
A few things that come to mind. Team building.
1:00:31
So building a culture within the pod because oftentimes your managers are no longer in your team, right?
1:00:38
Engineers might report to different people, designers might report to different people.
1:00:44
PMs might report to different people.
1:00:44
So actually building a team culture within the pod is really, really important.
1:00:48
And oftentimes it falls on the PM to create those offsites or to create those ideation sessions or to find ways to have fun as a team.
1:00:57
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.
1:01:19
So protecting that core team from that chaos and then being 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.
1:01:29
So those are the different things that is also really important to mention.
1:01:34
Coming 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 assuming that the team is A plus, the engineers are A plus, the designers A plus.
1:01:45
For somebody listening to this that may be wondering, "Are my engineers A plus or not?"
1:01:49
, what comes to mind as 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.
1:02:05
Yeah, it's very hard to identify. A few things.
1:02:05
One is, does the engineer want to win in the market?
1:02:09
Does the engineer really care about winning against competitors, winning the hearts and minds of the customer?
1:02:26
Do they understand the business context in which they operate by which they need to do that?
1:02:31
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?
1:02:35
They're asking you questions about the business outside of just the engineering domains.
1:02:48
Are they able to execute on what they said they were going to execute without your help or do you actually feel like you need to be behind them?
1:02:54
Are they the one actually setting the pace, asking you to 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?
1:03:13
Are they being proactive in different channels where you think it's actually your job, but actually they'll jump in anyways?
1:03:18
For example, we have different Slack channels with a bunch of people sometimes asking questions or raising issues or having blockers.
1:03:24
And you have engineers who are just jumping in and explaining how a feature works, getting the feedback and fixing a bug proactively.
1:03:36
And you may think, "Well, that's not the priority.
1:03:36
I need to control what the engineers are doing."
1:03:40
That's not your job actually, that's not your job.
1:03:40
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.
1:03:48
And if they're taking on something that puts the things that they committed to at risk, they'll communicate that.
1:03:57
So, again, that proactiveness, that desire to help, that desire to improve that accountability on their product.
1:04:02
If their product isn't performing, if their product has feedback, are they doing it themselves or they need you to push them?
1:04:10
So those are all mentality and culture aspects.
1:04:10
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.
1:04:18
That's not really my role.
1:04:22
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.
1:04:25
And it's just a big part of the culture shift and the culture that we've been able to build.
1:04:35
That was an awesome answer.
1:04:35
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 there's just like, "Oh, no.
1:04:45
Okay, here's what I think we should actually do," but engineers have all these opinions.
1:04:45
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.
1:04:55
And so it's like a catchment to you a little bit, but I think that's a really unique culture and approach.
1:05:00
And so that's an awesome answer.
1:05:05
And, look, there's drawbacks to that culture where you get to 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.
1:05:25
And it is 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 is 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.
1:05:41
And I'll grow as a manager much faster because of that. I love it.
1:05:46
Two final questions, one around hiring.
1:05:46
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?
1:05:55
What do you look for that you think is unique that helps you hire this A-plus team?
1:05:59
We look for people who have a very strong desire to have impact.
1:06:08
And the best way to assess that is the impact that they've had or the reason why they are switching jobs.
1:06:17
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.
1:06:28
And the best signal that is, I'm leaving because things got too slow, things got too bureaucratic.
1:06:34
I missed the old days where we were just building and shipping and launching.
1:06:39
I look for people who can think deeply, so I'll go super deep into a decision, a tradeoff that they had to make.
1:06:46
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.
1:06:57
And in general, we tend to overemphasize those two skills rather than necessarily experience because experience ...
1:07:05
Again, to the point around Ramp is a unique business, it matters a lot less.
1:07:13
You can have a lot less impact than your ability to be hungry and your ability to think deeply. Final question.
1:07:20
A lot of people listening to this want to get into product management. What's your advice?
1:07:24
I'm sure you get asked this a lot.
1:07:24
How do you break into product management? What do you tell people? Yeah.
1:07:27
So for me, I went from college to consulting to my four into tech was really into more like solutions analyst, I think that was my title.
1:07:40
I was basically trying to implement a large B2B software in national banks.
1:07:40
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.
1:07:58
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.
1:08:09
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.
1:08:21
So, for example, product operations is a good one.
1:08:27
Business operations is a good one.
1:08:27
More consulting sales engineering or solution engineering is a good one.
1:08:32
There are designers and engineers that can become PMs as well.
1:08:32
Typically, it's folks that can do the job as well as the PM.
1:08:39
And what we typically do is we give those PMs a shot or those folks a shot.
1:08:48
So we'd give them like six months to go into a new area and try it out.
1:08:55
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.
1:09:05
Is there anything else you want to share before we get to our very exciting lightning round? Yeah.
1:09:09
I mean, first, think from first principles, don't take everything I'm saying at face value.
1:09:13
And second is back to talent, that a huge part of our success was the early team that Karim built on the tech side.
1:09:23
And so I can write blogs all day on how we increased 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 Ramp was so successful and it's something that requires a ton of focus.
1:09:43
I mean, early on for the first year at Ramp, Karim, our CTO, was only focused on that.
1:09:50
It was hiring the best talent.
1:09:50
He was a lot less interested or focused on our product strategy, our product market fit, or even our revenue.
1:09:57
It was all about bringing in the best engineers and the best designers and that has had compounding effects on the company and the team.
1:10:08
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 got to look at that."
1:10:18
So there's an early compounding effect, too, that happens. Exactly.
1:10:23
Well, with that, we've reached our very exciting lightning round.
1:10:26
I've got six questions for you. Are you ready? Yes.
1:10:32
What are two or three books you've recommended most to other people?