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

Episode overview

Geoff Charles explains how Ramp made velocity central to its product-development system while scaling to $100 million in annual revenue with a relatively small R&D organization. He describes single-threaded teams, ambitious goals, protective operational layers, and alignment on goals, hypotheses, and data as the foundations of empowered execution. The conversation also covers lightweight planning, first-principles thinking, quality controls, deep work, product-management responsibilities, hiring, and sustainable high performance.

Key ideas

  • Ramp optimizes hiring, promotion, team design, decision-making, and product development around velocity.
  • Small, single-threaded teams move faster when leaders give them ambitious goals, tight timelines, necessary resources, and protection from organizational distractions.
  • Empowerment requires alignment on goals, hypotheses, and evidence; teams closest to the work should determine solutions.
  • High velocity needs quality controls such as voice-of-customer feedback, NPS, CSAT, support-ticket burden, and immediate bug ownership.
  • Planning accuracy should be purchased only where coordination stakes are high; autonomous teams can tolerate local uncertainty and change.
  • Strategy connects goals to hypotheses, a company’s right to win, metrics, initiatives, risks, and long-term outcomes rather than merely listing a roadmap.
  • Writing and protected deep-work time help leaders reason from first principles, clarify difficult questions, and preserve mental capacity for processing rather than memory.
  • Ramp hires for hunger, demonstrated impact, deep thinking, and talented engineers and designers who proactively challenge product decisions.

Transcript available · source text is retained privately and is not published

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 →

People & resources mentioned

Attributed to the moment in the episode. Timestamps are approximate.

People · 9

  • Lenny RachitskyMentionstoday we've got another very special compilation episode something I've been pulling on more and more with the podcast and the newsletter

    “welcome to Lenny's podcast where I interview world-class product leaders and growth experts”

    ▶ Watch at ~0:30approx.
  • Geoff CharlesMentionstoday my guest is Jeff Charles who is VPR product at Ram

    “today my guest is Jeff Charles who is VPR product at Ram”

    ▶ Watch at ~0:30approx.
  • Brian CheskyMentionsBrian chesky at Airbnb there was a whole article where we unpacked this moment in their product development cycle

    “Brian I was uh famous for going to meetings where people present their goals and their plans”

    ▶ Watch at ~13:00approx.
  • Nicole ForsgrenMentionsNicole is the developer productivity expert having written the award-winning book accelerate

    “I just had a chat with Nicole forsgren whose World expert on developer productivity and developer experience”

    ▶ Watch at ~21:00approx.
  • Sheryl SandbergMentionsI was at a fireside chat with Cheryl Sandberg once at Airbnb

    “I was at a fireside chat with Cheryl Sandberg once at Airbnb”

    ▶ Watch at ~35:00approx.
  • David AllenCoinedmentioned

    “have you read getting things done by David Allen”

    ▶ Watch at ~56:30approx.
  • Karim AtiyehMentionsEric and Kareem the co-founders of rap were previous founders of another company

    “Kareem our CTO was only focused on that it was hiring the best talents”

    ▶ Watch at ~1:09:30approx.
  • Geoff Charles's fatherMentionsmy dad owned a restaurant

    “my dad owned a restaurant so I got a little bit into that”

    ▶ Watch at ~1:11:00approx.
  • Diego de JodarMentionsour head of design uh Diego has changed basically having designers spend more time creating more Visionary prototypes

    “our head of design uh Diego has changed basically having designers spend more time creating more Visionary prototypes”

    ▶ Watch at ~1:13:30approx.

Resources · 28

  • Lenny's PodcastMentionspodcast · Lenny Rachitsky

    “welcome to Lenny's podcast where I interview world-class product leaders and growth experts”

    ▶ Watch at ~0:30approx.
  • EzraUsescompany

    “I actually used Ezra earlier this year unrelated to this podcast completely on my own dime”

    ▶ Watch at ~1:30approx.
  • American Cancer SocietyMentionscompany

    “according to the American Cancer Society early cancer detection has an 80 survival rate”

    ▶ Watch at ~2:30approx.
  • CodaUsessoftware · Coda

    “I use Coda every day to Wrangle my newsletter content calendar my interview notes for podcasts and to coordinate my sponsors”

    ▶ Watch at ~3:30approx.
  • RampMentionscompany · Eric Glyman and Karim Atiyeh

    “ramp is a finance automation platform and corporate card solution for small media sized businesses”

    ▶ Watch at ~5:00approx.
  • SnowflakeMentionscompany · Snowflake Inc.

    “how figma builds product and how snowflake builds product and all these other incredible companies”

    ▶ Watch at ~6:30approx.
  • ExpensifyMentionscompany

    “six months after that we built a competitor to to expensify”

    ▶ Watch at ~9:00approx.
  • MXMentionscompany

    “in three months we built a competitor to MX”

    ▶ Watch at ~9:00approx.
  • Bill.comMentionscompany

    “we basically gave a team you know goal of building a competitive build.com”

    ▶ Watch at ~9:30approx.
  • AirbnbMentionscompany · Brian Chesky, Joe Gebbia, and Nathan Blecharczyk

    “that's something I've seen a lot at Airbnb”

    ▶ Watch at ~13:00approx.
  • CoupaMentionssoftware

    “expensify public and traded or concur or Koopa these are all like large players”

    ▶ Watch at ~13:30approx.
  • ConcurMentionssoftware

    “expensify public and traded or concur or Koopa these are all like large players”

    ▶ Watch at ~13:30approx.
  • LoomUsessoftware · Loom

    “Cornerstone Loom walkthroughs of figma prototypes”

    ▶ Watch at ~14:30approx.
  • FigmaUsessoftware · Figma

    “Cornerstone Loom walkthroughs of figma prototypes”

    ▶ Watch at ~14:30approx.
  • LinkedInMentionswebsite · LinkedIn

    “someone on LinkedIn a product manager posted half jokingly”

    ▶ Watch at ~24:00approx.
  • AttioMentionssoftware · Attio

    “this episode is brought to you by atio a new type of CRM that's powerful flexible and built around your data”

    ▶ Watch at ~36:30approx.
  • Google CalendarUsessoftware · Google

    “it was a Google it was in the calendar it was like the calendar invite”

    ▶ Watch at ~54:00approx.
  • SlackUsessoftware · Slack Technologies

    “I slack them what they owe me that but a reminder on slack”

    ▶ Watch at ~55:30approx.
  • Google WorkspaceUsessoftware · Google

    “in the Google space you can pull up any document and and search a bunch of documents very very quickly”

    ▶ Watch at ~56:00approx.
  • Getting Things DoneMentionsbook · David Allen

    “have you read getting things done by David Allen”

    ▶ Watch at ~56:30approx.
  • LinearUsessoftware · Linear

    “we don't spend much time in in you know linear which is uh our ticket management system”

    ▶ Watch at ~59:30approx.
  • When Breath Becomes AirRecommendsbook · Paul Kalanithi

    “when breath becomes air is a really good one that that I often recommend”

    ▶ Watch at ~1:10:30approx.
  • The BearMentionstv show · Christopher Storer

    “we started watching the bear a few weeks ago”

    ▶ Watch at ~1:11:00approx.
  • WHOOPUsesproduct · WHOOP

    “my partner bought me this whoop uh recently wearing it wearing it now”

    ▶ Watch at ~1:12:00approx.
  • Microsoft ExcelUsessoftware · Microsoft

    “we just got really good at like Excel and Excel shortcuts and it was a big part of our training”

    ▶ Watch at ~1:14:30approx.
  • XUseswebsite · X Corp.

    “you can find me on Twitter and Linkedin Twitter is Jeff in Tech”

    ▶ Watch at ~1:15:30approx.
  • Apple PodcastsMentionssoftware · Apple Inc.

    “you can subscribe to the show on Apple podcast Spotify or your favorite podcast app”

    ▶ Watch at ~1:16:30approx.
  • SpotifyMentionssoftware · Spotify

    “you can subscribe to the show on Apple podcast Spotify or your favorite podcast app”

    ▶ Watch at ~1:16:30approx.

Spot an error or want something removed? Request a correction or removal.

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