LLenny's Podcast
← All episodes
Geoff Charles (VP of Product)06 August 2023

Velocity over everything: How Ramp became the fastest-growing SaaS startup of all time

7Frameworks
15Insights

Frameworks in this episode

Leadership4 steps

Context Over Control: Debate Upstream of the Solution

Empower teams by aligning on goal, hypothesis, and data—never by prescribing the solution.

Read →
Productivity4 steps

Processing Over Memory: A Task System for the Overwhelmed Manager

Write everything down at the moment it's owed, groom into logical chunks, and free your head for thinking not remembering.

Read →
Innovation4 steps

The Gravity Model for Zero-to-One Products

Ship new products with tiny shielded teams, then let traction—not headcount—pull in resources.

Read →
Strategy5 steps

The Strategy Contract

A one-page doc sitting between vision and roadmap that every pod writes for itself.

Read →
Communication4 steps

The Trade-Off Menu: Turn a Velocity Demand Into Leverage

When leadership wants everything faster, hand them a menu of what you'll do and what you won't—and make them choose.

Read →
Self-Mastery4 steps

Think From First Principles by Writing

Close the laptop, write the question at the top of a blank page, and answer it before Googling anything.

Read →
Productivity4 steps

Velocity Guardrails: Ship Freely Until the Metrics Go Red

Standardize a few quality metrics per team; below the line they ship anything, above it they fix before they ship.

Read →

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Myth Buster· 1

Myth Buster21:00

Faster Doesn't Mean Lower Quality — It Means Higher

The intuition is that moving faster tanks quality, but research from Nicole Forsgren on developer productivity found the opposite: quality goes up as product velocity goes up. Because you can fix things quickly and ship without waiting on long review-and-release cycles, output ends up higher quality. Geoff adds you must pair velocity with control mechanisms so it doesn't tank the business.

  • Nicole Forsgren's research found quality rises as velocity rises
  • Fast iteration means you can fix problems quickly rather than waiting on big review cycles
  • Velocity is just magnitude, not direction — it needs control mechanisms
  • Controls: every negative review routed to tech lead/PM/designer, monthly NPS/CSAT, operational-overhead metrics

“they find that quality goes up as your engine as your product velocity goes up you think it'd be the opposite the faster you move…”

Lenny Rachitsky · 21:00

“velocity is just is just a magnitude it's not necessarily a specific Direction”

Geoff Charles · 22:30
#velocity#quality#engineering

Hot Take· 4

Hot Take23:00

Ramp Doesn't Have a Bug Backlog

Geoff says Ramp fixes every bug almost as soon as it's surfaced, so there's no bug backlog — it's part of the production engineer's job. Where it gets nuanced is UX improvements, tracked by how many support tickets come in from customer confusion. If that number is elevated, teams are blocked from shipping new features until they fix it.

  • Every bug is fixed once surfaced; there is no bug backlog
  • Fixing bugs is part of the production engineer's job
  • UX improvements are judged by support tickets from confused customers
  • Elevated confusion metrics block a team from shipping new features until fixed

“we don't have a bug backlog we've we fix every bug once they're surfaced almost”

Geoff Charles · 23:00
#quality#engineering#bugs
Hot Take26:00

You Can't Ask for Velocity Without Giving Up Control

Geoff's advice to PMs pressured to 'be more like Ramp': velocity requires empowerment, trust, killing process, and real focus — trade-offs many leaders won't make. He says he has never scheduled a status meeting; statuses are async and real-time, and meetings are only for collaboration and decisions. Use the ask for velocity as leverage to change how the organization operates.

  • Velocity demands empowerment, trust, less process, and more focus
  • Meetings and status updates are the biggest waste of time
  • Statuses should be async and in real time, in the systems teams already use
  • Use the leadership push for velocity as leverage to eliminate process and increase focus

“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…”

Geoff Charles · 26:30

“you can't ask for velocity and not have empowerment and not trust and not eliminate process and not increase the focus”

Geoff Charles · 28:00
#velocity#leadership#meetings#empowerment
Hot Take29:30

Velocity Prevents Burnout, It Doesn't Cause It

Geoff argues the debate about hard work and burnout misses the point: burnout is about impact and how good you feel about your work, not hours. The time he felt most burned out was when his velocity was lowest — putting effort into things that weren't moving. He frames velocity and flow state as a way to avoid burnout, using the analogy that the best runners are the ones who love running.

  • Burnout is about impact and meaning, not raw hours
  • Geoff's worst burnout came during his lowest-velocity period
  • Getting into a flow state and cadence makes hard work feel thrilling
  • The best runners love running; work stops feeling like a chore when you love it

“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…”

Geoff Charles · 29:30
#burnout#velocity#flow#wellbeing
Hot Take47:00

Every Support Ticket Is a Failure of the Product

At Ramp, the support team reports into product, from a first principle Geoff states bluntly: every support ticket is a failure of the product. If the product worked perfectly, no one would need to contact support. Rather than hiring people to just resolve tickets, they incentivized decreasing ticket volume over time — resulting in over 400,000 users served by a support team of under 30.

  • Support reports into product, not a separate org
  • First principle posted on channels: every support ticket is a failure of the product
  • Incentivize decreasing ticket volume, not just resolving tickets
  • Over 400,000 users are served by a support team of under 30

“every support ticket is a failure of our product we literally have that as you know a quote just posted on on all those channels…”

Geoff Charles · 47:00
#support#first-principles#product#org-design

Explainer· 4

Explainer10:30

What 'Single-Threaded' Teams Actually Mean at Ramp

Geoff explains that very few people can execute more than one thing well, especially individual contributors. A single-threaded team has one goal and one thread each person wakes up focused on, with everything else removed. He gives the example of a Flex product built by a team focused purely on e-commerce cash-flow needs.

  • Few people can execute more than one thing extremely well
  • Single-threaded means one goal, one thread, everything else removed
  • Remove research, production engineering, and outside process from the team
  • Example: the Flex product team stayed purely focused on e-commerce cash-flow smoothing

“there's only one goal one threat that they're they're waking up in the morning uh to focus on and in order to remove that you…”

Geoff Charles · 10:30
#focus#team-structure#execution
Explainer12:00

How Ramp Shields Teams From Bugs, Escalations and Chaos

To keep single-threaded teams from being distracted, Ramp builds 'layers of protective tissue' around them. A rotational production-engineering program shields core engineers from escalations and bugs, and product operators shield PMs from documentation, release management, and customer requests. Geoff notes this gets harder when a team goes from one product to two.

  • A rotational production-engineering program protects core engineers from escalations and bugs
  • Product operators shield PMs from docs, escalations, release management, and enablement
  • Big bets pull people from different teams into a sub-team with no existing product responsibility
  • The challenge grows going from one to two products, not zero to one

“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…”

Geoff Charles · 12:30
#focus#team-structure#operations
Explainer41:00

Ramp's 'Right to Win' — Why Bill Pay Was a Natural Extension

Geoff explains how Ramp decides where it's uniquely positioned to win. Expanding from corporate cards into bill payments made sense because a bill is just an invoice to the company and an expense is an invoice to the employee — the same underlying money movement and liability processing. Because Ramp already had money movement, liability handling, accounting integrations, and risk processes, it could reuse those components to move faster.

  • A bill is an invoice to the company; an expense is an invoice to the employee
  • Both are about processing a liability and moving money
  • Ramp already had money movement, accounting integrations, and risk processes to reuse
  • Focusing on where you're uniquely positioned increases velocity because the components already exist

“we saw a bill as just a an invoice to the company and an expense was an invoice to the employee”

Geoff Charles · 41:00
#strategy#first-principles#product#right-to-win
Explainer58:00

Doing More With Fewer PMs by Making Everyone Think Like One

Ramp runs with about 13 PMs across 100+ engineers by keeping PM teams small and forcing everyone else to think like a PM. Geoff defines 'product' as anyone reporting into the CTO — engineering, design, data science — and empowers them to own specs, scopes, and deep thinking. They also invested early in product operations and cut low-leverage work like ticket-writing, which lets engineers move even faster.

  • About 13 PMs across 100+ engineers, ratios of ~1:8 to 1:15
  • Reducing PM headcount forces others to think like PMs
  • 'Product' includes engineering, design, and data science reporting to the CTO
  • PMs don't write tickets — engineers break down and own the work, increasing trust and speed

“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…”

Geoff Charles · 58:00
#product-management#team-structure#leverage

Story· 1

Story09:00

How Ramp Built Competitors to MX and Expensify in Months

Geoff describes Ramp's early velocity in concrete terms: a tiny team of about eight engineers built a competitor to MX in three months, then a competitor to Expensify six months later. They hit $100M in annual revenue with under 50 people in R&D, and later launched an accounts-payable product (a Bill.com competitor) with three engineers, one designer, and one PM in three months.

  • ~8 engineers built a competitor to MX in three months, then Expensify six months later
  • Hit $100M annual revenue with fewer than 50 people in R&D (~40 engineers, 3 PMs)
  • A Bill.com competitor was built by 3 engineers, 1 designer, 1 PM in three months and now moves billions a year
  • The recipe: small single-threaded teams, lofty goals, tight timelines, shielded from company chaos
  • Don't tell the rest of the company until the team finds product-market fit

“in three months we built a competitor to MX uh six months after that we built a competitor to to expensify you know both publicly…”

Geoff Charles · 09:00

“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…”

Geoff Charles · 10:00
#velocity#team-structure#startup#product

Q&A· 1

Q&A1:02:00

How to Tell If Your Engineers Can Operate This Way

Asked how a listener can tell whether their team is 'A-plus' enough for Ramp's empowered model, Geoff lists behavioral signals: Do engineers want to win in the market? Are they curious about how the business makes money and what customers love? Can they execute without being pushed, set the pace, and proactively jump into channels to fix things? He explicitly says he's not judging technical rigor — these are mentality and culture signals.

  • Does the engineer want to win in the market and against competitors?
  • Are they curious about how the company makes money and what customers love?
  • Can they execute without being pushed, and set the pace themselves?
  • Do they proactively jump into channels to fix bugs and explain features?
  • These are mentality/culture signals, not technical-rigor judgments

“does the engineer want to win in the market does the engineer really care about winning our against competitors winning the hearts and minds of…”

Geoff Charles · 1:02:00
#hiring#engineering#culture#empowerment

Takeaway· 4

Takeaway16:00

Stop Debating Solutions — Debate the Goal, Hypothesis and Data

Geoff says the biggest mistake junior leaders make is debating the right solution, when they should be debating upstream: the goal, the hypothesis, and the interpretation of the data. Whenever things went wrong at Ramp, it was because he was prescriptive about the solution without aligning upstream first. Get the upstream alignment right and better solutions come from the teams closest to the ground.

  • Alignment starts with the goal, the hypothesis, and the data behind the hypothesis
  • Junior leaders over-focus on debating solutions instead of upstream
  • Things went wrong when leaders were prescriptive about solutions without upstream alignment
  • Better solutions come from teams closest to the ground once the upstream is aligned

“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…”

Geoff Charles · 16:30
#leadership#empowerment#decision-making
Takeaway33:30

Accuracy Has a Cost — Only Plan Precisely Where It Pays

Building on the idea that any second spent planning is a second not spent doing, Geoff says accuracy in planning has a cost, so you should only increase it where the value of that accuracy is high. For Ramp, that means planning tightly for big coordinated market moments (roughly once a quarter or every six months), while individual pods stay somewhat autonomous and chaotic. Don't waste effort creating precise timelines for feature launches that don't need it.

  • Any second spent planning is a second not spent doing
  • Accuracy has a cost — invest it only where accuracy has high value
  • Plan tightly for big market moments coordinating product, marketing, and sales
  • Individual pods can be autonomous and chaotic; precise feature timing usually isn't worth the effort

“because accuracy has cost make sure that you're only increasing the accuracy of planning for the things that have a high value of that accuracy”

Geoff Charles · 33:30
#planning#velocity#prioritization
Takeaway49:30

Shut the Laptop and Write the Question at the Top of the Page

Geoff describes writing as his tool for thinking from first principles. When faced with a hard scalability question he couldn't answer off the bat, he'd shut his laptop, take a piece of paper, write the question as simply as possible at the top, and spend time thinking it through. He argues reading makes you wiser but doesn't make you think better — the way to increase your capacity to think is to actually do the thinking.

  • Shut the laptop, take paper, write the question simply at the top
  • Used for hard scalability problems few companies have solved
  • Reading makes you wiser but doesn't necessarily make you think better
  • Writing clearly forces thinking clearly; read afterward to fine-tune

“the best way of doing that is to shut down your laptop yeah take out a piece of paper write the question as simply as…”

Geoff Charles · 49:30

“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…”

Geoff Charles · 50:30
#writing#thinking#first-principles#productivity
Takeaway53:30

Protect Deep Work by Staying Out of the Critical Path

Geoff protects thinking time by treating himself as someone who should never be in the critical path of anything, so he's largely unavailable (people with real emergencies have his phone number). He plans deep-work blocks the Friday before, works one day of the weekend, and finds thinking outside on paper refreshing. Lenny adds his own tactic: a recurring 'deeper time' calendar block that warned people they'd be slapped for booking it.

  • Aim to never be in the critical path, so you're free to think
  • Plan next week's deep-work questions the Friday before
  • Work one weekend day and think in low-busy times like early mornings
  • Lenny's 'deeper time' block deterred meetings by joking he'd slap bookers

“I think that I should never really be in the critical path of of anything so largely I I I'm not available but if you…”

Geoff Charles · 53:30

“I just had this huge block called deeper time if you book a time during this time I will slap you”

Lenny Rachitsky · 53:30
#deep-work#productivity#time-management