Notes — Sri Batchu on Ramp’s Growth, the Cap Table Strategy, and Failing Conclusively
Four questions [Adler frame]
Q1 — What is this about? A practitioner’s account of how Ramp grew to $100M ARR in two years — including the unconventional early-stage strategy (loading the cap table with influential founders), the growth infrastructure Batchu built at Instacart (the North Star Translation Layer), and a philosophy of experimentation that prioritises conclusive failure over fast failure.
Q2 — How is it argued? Through specific operational details from Ramp, Instacart, and Opendoor. Batchu gives precise numbers (Ramp grew 4× in the year following $100M ARR; the Instacart growth team had 300+ people; Ramp is under 500 employees total). The argument about conclusive failure is supported by observing the recurrence problem: without conclusive failure, the same experiment gets re-run by every new executive who joins.
Q3 — Is it true? The cap table strategy is unusual but logical for B2B where influencer-customers are operators already using analogous tools. The translation layer is a sound operations design; the main risk is that translation coefficients are estimates and drift over time (Batchu acknowledges this with the six-month update cadence). The conclusive vs fast failure distinction is the most conceptually robust claim — it identifies a real failure mode in experimentation culture.
Q4 — What of it? The translation layer is immediately applicable at any company with a large multi-team growth function and a defined North Star. The cap table strategy is most applicable at the very early stage. The conclusive failure principle is broadly applicable to any team running slow, expensive experiments.
Glossary
North Star Translation Layer — The mechanism that converts each team’s local metric into equivalent units of the company North Star, enabling cross-team resource allocation and unified planning. See North Star Translation Layer.
MAO (Monthly Active Orders) — Instacart’s growth North Star metric. An order placed by an existing customer within the calendar month. Chosen because it is (a) clearly linked to business value and (b) intuitive to every team member.
Cap table strategy — Getting influential operators, founders, and advisors onto the company’s cap table at the earliest stage, so that their portfolio companies become the first customer set and brand advocates.
Failing conclusively — Designing an experiment such that failure definitively retires the underlying hypothesis — rather than producing an ambiguous result that the same hypothesis can survive.
Activation (Ramp) — Four specific customer behaviours in the first 30 days, which, if completed, predict sustained engagement with the platform. Ramp’s activation team is goaled entirely on driving customers through these four events.
The cap table strategy in detail
Ramp’s founders populated their early cap table with influential operators and founders. The direct consequence: the portfolio companies of those investors — and the founders themselves — became the initial customer set. This gave Ramp:
- A high-quality, high-intent first customer cohort.
- Organic word-of-mouth within the startup-and-VC community that was difficult for competitors to replicate.
- A reputation among tech founders that persists even as the majority of Ramp’s revenue has shifted to mid-market and enterprise.
The strategy is specific to a product category where operators make the buying decision (corporate spend management) and where the decision-maker’s peers are credible reference customers.
The North Star Translation Layer in detail
Instacart’s growth structure: 300+ people across consumer engineering and growth, working on every part of the acquisition-to-retention funnel. The company North Star was MAO (monthly active orders).
The problem: a team working on checkout conversion could not easily trace their daily work to MAO. The translation layer solved this by providing:
- A per-team coefficient: ‘if checkout conversion improves by 1%, expect X incremental MAO per month.’
- A common planning unit: all project proposals and resource requests could be expressed in expected MAO impact.
- An allocation signal: ‘where is there more MAO per engineering dollar being built?’ directs headcount decisions.
The translation coefficients were updated every six months. Day-to-day teams worked against their local metric; leadership planned and allocated against MAO.
Failing conclusively vs failing fast
The lean/agile orthodoxy emphasises fast failure: run experiments quickly, learn quickly, move on. Batchu’s critique: fast failure that is inconclusive does not actually retire the hypothesis. If the experiment lacked sufficient sample size, treatment effect, or clean isolation, the result is ambiguous — and the next executive who joins with the same intuition will re-run the same experiment.
The conclusive failure requirement: design the experiment to be big enough (or run long enough, or isolated cleanly enough) that a failure definitively answers the question. This matters most for experiments that are slow to run or expensive to set up — the ones where re-running has a real cost.
Batchu’s meta-rule: fail conclusively for expensive experiments; fail fast for cheap ones (website copy, emails, landing page variants).
Growth engine design principles
Batchu’s North Star for building a growth team:
- Set simple North Star metrics (one, at most two): one on volume (MAO, MAU), one on efficiency (cost per activation, payback period).
- Build a culture of data-driven hypothesis generation and fast MVPs — for both product and non-product experiments.
- Celebrate failure as learning; distinguish ‘didn’t hit the number’ (fine) from ‘didn’t learn’ (not fine).
The specific people and functions matter less than whether the team can generate new ideas, evaluate them rigorously, and move quickly.