How Ramp built the fastest-growing SaaS company with radical velocity

Executive overview

Most companies say they move fast. Ramp built a competitor to Amex in three months with eight engineers, then hit $100M ARR with 50 people. The gap isn't mindset — it's structure.

Velocity is not a culture poster. It's an operating system: small single-threaded teams, radical empowerment, zero status meetings, and quality talent as the foundation.

What velocity actually looks like

• Three engineers, one PM, one designer built a bill-payments product in three months — now moving billions annually
• Reached $100M ARR with under 40 engineers and three PMs
• No bug backlog: every bug is fixed when surfaced, assigned directly to the on-call engineer
• Teams ship to beta first; leadership stress-tests hypotheses before GA, not before beta
• High velocity correlates with higher quality — fast iteration catches problems sooner

Single-threaded teams

• One goal, one thread per team — no split attention across existing products
• Protective layers (rotational production engineers, product operators) shield core teams from escalations and requests
• New bets are staffed by pulling people from other teams with no existing-product responsibility
• Don't announce the new team to the rest of the company until it finds early traction

Context over control

• Alignment should be on goals, hypotheses, and data — not on solutions
• Prescribing solutions without upstream alignment is where things go wrong
• Leaders act as "repeaters": constantly sharing context teams don't have access to
• PM contract with leadership = strategy + roadmap; execution decisions stay with the team
• Weekly goal posts from all directs; one-on-ones focused on what they need, not status

Planning and strategy

• Moved from quarterly OKRs (consumed one month every quarter) to a biannual one-pager on company priorities
• Strategy document structure: goals → hypothesis → why uniquely positioned → metrics → initiatives → risks → long-term outcomes
• Each pod writes its own strategy doc; leadership checks alignment with company-level strategy and financial plan
• Accuracy has a cost — only plan in detail for things where accuracy has high value (e.g. coordinated marketing moments)
• OKRs reserved for cross-functional outcomes, not individual product teams

Empowering teams to move faster

• Eliminate status meetings entirely; all statuses are async and live in the systems teams already use
• Present leadership with a menu of trade-offs — "here's what we're doing and what we're not doing" — instead of trying to do everything
• CEO sets vision but is less opinionated about sequence; engineering team is radically empowered
• Engineers own their tickets, their breakdowns, their commitments — PMs don't write tickets
• Product operations team (separate from PMs) handles project management, release management, enablement, and customer research

Quality controls at high velocity

• Monthly voice-of-customer reports (negative reviews) sent directly to tech lead, PM, and designer per product area
• NPS, CSAT, and operational burden (tickets per user) tracked per team as a standing contract
• If confusion-driven support tickets spike: no new features until fixed
• Support team reports into product — every ticket is treated as a product failure

The PM role at Ramp

• Core job: strategy, roadmap, protecting the team, and building pod culture
• PMs don't write tickets or manage linear; engineers own that
• Designers own specs and scope more than at most companies; engineers push back on direction
• PM-to-engineer ratio: roughly 1:8 to 1:15
• Product operations absorbs most of the operational PM work

Hiring and what to look for

• Prioritise hunger (desire for impact) and depth of thinking over domain experience
• Go deep on one decision or trade-off in the interview until you reach genuine understanding
• Ask "what's the hardest thing you've ever done" — reveals what difficulty means to them and how much agency they take
• Signal to watch: candidates leaving because things got "too slow" or "too bureaucratic"
• Give internal candidates (ops, sales engineering, design) a six-month trial; let engineers and designers vote on whether they want that PM

Avoiding burnout

• Burnout comes from low velocity, not high velocity — effort without movement is what exhausts people
• Remove distractions (meetings, cross-functional noise) so people can reach flow state
• Ownership is the antidote: if people feel it's their company, their product, they sustain themselves
• Work pushed onto people burns them out; work they've claimed doesn't

First-principles thinking

• Ramp spans credit, payments, software, PLG, and enterprise — pattern-matching from past experience fails
• Support reports into product because "every support ticket is a product failure" — not a support problem
• Result: 400,000+ users served by a support team of under 30 agents
• Hire people willing to put aside their expertise and reason from fundamentals

Writing and deep work

• Writing is how you increase thinking capacity — not a communication tool, a thinking tool
• Start with the question written simply at the top of the page; answer it before Googling
• Block deep work time explicitly (Friday morning blocks, weekend mornings)
• End of each meeting: write down tasks you owe and tasks others owe you; groom and group at end of day
• Free up head space for processing, not memory — externalise everything