Geoff Charles on Velocity, First Principles, and How Ramp Builds Product

Geoff Charles on Velocity, First Principles, and How Ramp Builds Product

transcriptproductrampvelocityengineeringfintech

Geoff Charles on Velocity, First Principles, and How Ramp Builds Product

Source: Lenny’s Podcast Speaker: Geoff Charles Link: Episode

Overview

Geoff Charles, VP of Product at Ramp (fastest-growing SaaS and FinTech business in history to $200M ARR), gives a detailed account of how Ramp’s product organisation actually operates. The episode is a practitioner’s anatomy of velocity: what single-threaded teams look like, how quality controls coexist with fast shipping, how planning was redesigned away from OKRs and toward a biannual one-pager, and why support reports into product. The second half covers writing as a thinking tool, PM hiring philosophy, and what separates an A-plus engineering culture from the average.

Key ideas

  • Velocity as the organising principle. Small single-threaded teams — one goal, one thread, shielded from the rest of the organisation — with lofty goals anchored to market comparables (Amex, Expensify, Bill.com) and design Looms. Ramp reached $100M ARR with fewer than 50 R&D staff. The AP team that built a Bill.com competitor was three engineers, one designer, and one PM over three months; that product now moves billions of dollars a year.
  • Context over control. The correct order of alignment is goal → hypothesis → data → solution. Most leadership debates focus on solutions when they should focus on interpreting data and debating hypotheses. When things went wrong at Ramp, it was when Geoff was prescriptive about the solution without aligning upstream. The PM’s contract with leadership is the strategy and roadmap; execution authority flows downward. A PM’s job is largely to repeat context: what they know from meetings and forums the team isn’t in.
  • First-principles thinking over pattern-matching. Ramp is simultaneously a credit card company, a payments company, and a software company — no comparable exists. Importing experience without decomposing assumptions is an anti-pattern (“I’ve seen this before” is the signal). Primary example: support reports into product, because “every support ticket is a failure of our product.” Result: 400,000+ users served by fewer than 30 support agents.
  • Velocity mechanics. No status meetings — statuses are async, in the systems. No bug backlog — every bug is fixed almost immediately. Product operators absorb documentation, escalations, release management, and customer research so PMs don’t touch them. PMs don’t write tickets; engineers own work breakdown. Planning shifted from quarterly OKRs (consuming 33% of the year) to a biannual one-pager on company priorities. Quality is measured by CSAT, NPS, operational overhead (support tickets per user normalised), and “confused customer” ticket rate — breach those and you stop shipping features.
  • Writing as thinking. The best way to work through hard, first-time problems: shut the laptop, take paper, write the question at the top, and answer it before reading anything. Writing clearly is a proxy for thinking clearly. Geoff used this for every major scaling problem at Ramp — how to scale decision-making, incentivise teamwork, allocate headcount, avoid politics as the company grew.