Jeremy Henrickson on Velocity at Scale, the Compound Startup Model, and Why MVPs Can Be Harmful

Literature notes on the Lenny’s Podcast conversation (recorded ~2023). Jeremy Henrickson is SVP of Product at Rippling; previously CPO at Coinbase through 2017, when usage grew ~40× and the product/engineering organisation ~10×. The conversation is about keeping decision velocity high as an organisation scales, and why a company building on a shared platform should design for the hardest case first rather than ship an MVP.

Four questions [Adler frame]

Q1 — What is the whole about? How to maintain — even accelerate — velocity at scale, and the structural choices that make it possible: small teams with clear missions, heavy platform investment, leaders going all the way to ground, and designing for the most complex use case rather than the minimum viable one. The case study is Rippling’s compound startup — many businesses on one system of record.

Q2 — How is it argued? From two contrasting operating environments. Coinbase taught reacting fast under radical uncertainty (debate, decide, commit, move); Rippling teaches building durable differentiation under known demand. Each principle is illustrated with a Rippling launch (time-and-attendance, global payroll) or a Coinbase memory, and tied to a written leadership principle (“go and see,” “right a lot”).

Q3 — Is it true? Coherent and concrete; the global-payroll example (80% shared platform, 20% country-specific, configured by compliance/legal rather than engineers) substantiates the central architectural claim. The strongest claim — MVPs bake in architectural assumptions that are extremely difficult to unwind — is argued by mechanism and is plausibly right for a compound product, though [?] it is asserted from Rippling’s context, where market validation already exists; Henrickson explicitly concedes MVPs are right when product–market fit is unknown.

Q4 — What of it? A model for building multiple products fast on shared infrastructure, a contrarian “design for the complex case first” instruction, and a set of velocity practices (small founder-led teams, platform-as-leverage, go-and-see depth, firm quarterly dates, “imperatives”) that transfer beyond HR software.

Glossary

Compound startup: a company that is several businesses (payroll, benefits, IT, device management, time-and-attendance) built on one system of record — a single database of every employee attribute — so each product inherits always-current data no competitor can replicate. High activation energy to build; durable advantage once built [§ Compound startup]. See Compound Startup Model.
System of record: the single source of truth for employee data that every Rippling product reads from, so any product can instantly answer “who is this person’s manager?” without an integration or a stale export [§ Compound startup].
Design for the most complex use case first: build the architecture that could handle the hardest case (10,000 employees, mission-critical, global) before deciding which cases V1 will actually support — the opposite of the MVP wedge [§ Anti-MVP].
Go and see: a Rippling leadership principle — the leader making a decision walks “all the way to ground,” to the engineer writing the code or the actual tax statute, rather than relying on summaries [§ Go and see].
Imperatives: a force-ranked list (~10) of cross-cutting priorities every product/engineering team must fold into its own plan — defined as much by what is not on the list [§ Velocity practices].
Right a lot: a leadership principle (shared with Amazon) — the rare, hard-to-test ability to call the right direction from ambiguous, incomplete information, because product decisions multiply across the whole org [§ Right a lot].

Coinbase: focus under 40× [§ Coinbase]

Through 2017 Coinbase saw ~40× growth in usage as crypto entered public consciousness — “both a dream and a nightmare,” with edges of the system breaking on Saturday mornings (when people trade). Keeping a team focused: don’t talk about people getting rich — frame everything as the customer’s money, and make security the non-negotiable number-one. Philip Barton, the security leader, could place fast decisions in context — “these are the kinds of decisions we can make and still be secure no matter how fast we move.” The hardest part was the radical uncertainty (was Ethereum going to be a thing? no one knew), which demands real debate that nonetheless resolves into one company point of view you go full speed toward “until you decide to go full speed toward a different answer.” The intense crucible accelerated personal learning; the value of a hard period is best seen 3–5 years later.

Velocity at scale [§ Velocity practices]

Henrickson’s most-requested advice. There is no single answer (it is business-specific), but a near-universal truth: small teams with clear missions. With 300 people on one thing, Dunbar’s number and horizontal-communication cost make speed impossible; break the always-large problem into bits small groups can attack wholeheartedly, minimising horizontal communication. Other levers:

Platform as leverage. The more you bake into a clear platform with a clean interface, the less decision-complexity each domain team carries. Platforms are iterative, not write-once, and need people who can do systems and product thinking simultaneously.
Dive deep (see go and see).
Right distribution of experience. A team great at zero-to-one may neither enjoy nor be good at scaling the same product two years later; continually recalibrate so people do what they love and the right skills are present.

Done together, velocity can accelerate over time, because more baked into the platform lets engineers do more with less. Two further cultural enablers: firm quarterly-planning dates — “that date passed; you don’t get to retroactively make everyone react to the fact that you didn’t operate quickly enough” (not hostile, just reinforced by its own gravity) — and the expectation that a PM owns the whole product, not a feature, so answers come off the top of the head or after 30 minutes, not three days later. Decision-speed is modelled top-down by founder Parker Conrad, who deliberately built a company that decides fast; the management structure exists but “does not interfere with the ability of anyone anywhere to look at what’s actually happening.” The newest velocity tool is imperatives — a force-ranked ~10-item list of cross-team priorities, valuable as much for what it excludes.

The founder-led-team launch model [§ Launch model]

Rippling’s repeatable way to start a new product line, run “a dozen times”:

A one-page view of what to build (usually a known industry category — time-and-attendance, payroll — to be built in a differentiated way).
Find a single, highly entrepreneurial engineer (recruited internally or externally) who operates at tempo and decides with low information. Have them spend a few months first working on an existing team — learning the platform, what is easy/hard, talking to others who founded products there.
Pair them with one designer (“design partner”) fluent in Rippling’s component library and UX.
They recruit 2–4 more zero-to-one engineers and build; over ~6–9 months a blank sheet becomes something launched or dogfooded internally.
A founder/DRI (Parker or Henrickson) meets them every couple of weeks to pressure-test designs (“if I were an admin at a large company, how would I feel?”).
Team size grows only as needed — sometimes five or six people run a product indefinitely; sometimes it jumps from 4 to 15 near production.

The time-and-attendance case: one talented systems engineer (Sachit), a few people, ~9 months, “monomaniacally focused on this one thing,” integrating only where necessary with payroll/benefits/IT. Speed came mostly from being small and focused, not just from CEO unblocking — which is why the pattern replicates without depending on Parker.

Anti-MVP: design for the complex case first [§ Anti-MVP]

Henrickson is not anti-MVP in general — they are right for a true zero-to-one company without market validation. But for Rippling an MVP would disserve both customers and the building team, because designing a minimum viable product optimises for speed and in doing so minimises the deeper product thinking about what fully differentiates the product — and, worse, leads to building the wrong thing technically. If you only model the simple case (a two-person company) and no one pushes “what about the 10,000-person global org, the mission-critical hospital case?”, you make different architectural assumptions, build on them for months, accumulate hundreds of dependent decisions, and “it’s extremely difficult to unwind those once you’ve built them in.” So: understand the simple cases and decide what V1 will support, but build so you are not prevented from reaching the hard case later. It costs a little more now and saves time in the long run.

Global payroll is the worked example: rather than copy the US system per country, the team designed for six very different countries at once (different HRIS, employer-of-record, contractor, payroll requirements). Result: ~80% lives in a shared global-payroll platform; the ~20% country-specific part is configured by compliance/legal, not changed by expensive engineers. Adding a country is now far easier than stamping out and maintaining disconnected replicas. The instruction to teams — design for the most complex use case first — is deeply counter-cultural for people trained on the wedge-and-grow approach, which is why new founders spend months absorbing the culture and why early products are kept high-touch.

The compound startup [§ Compound startup]

Rippling is “a lot of businesses that all work together” — payroll, benefits, IT, device/identity management, time-and-attendance, each a multi-billion-dollar industry on its own. Parker Conrad’s pre-founding insight: when you run all these, data gets replicated and copied and is impossible to keep in sync; the right answer is a single system of record — one database holding every employee attribute — so every downstream product has the right data at the right time, and you can build shared workflow, reporting, analytics, and permissioning on top. The differentiator is that one decision: most products cannot answer “who is this person’s manager?” without an integration and an immediately-stale exported spreadsheet; Rippling always can, “because we are the system of record.” The activation energy was enormous (the founders built the first versions of every product — “a minor miracle”), but once the platform existed, new verticals could be built on top. “Our ability to differentiate boils down to that one fundamental decision, which just allows us to do things that are literally impossible for any other company to do.” This connects design-for-the-complex-case-first to strategy: the hardest architectural choice is the moat. See Compound Startup Model.

Go and see, and “right a lot” [§ Go and see] [§ Right a lot]

Go and see: the leader making top-level product decisions must be “extremely clear about what the priorities are, and more importantly what they aren’t,” then walk all the way to ground — to the engineer writing the code, or the actual tax statute — because top-level communication is insufficient to reach the detail that matters. Don’t delegate the learning: the product leader gets into the weeds first, then makes the case to hire the specialist (Rippling’s head of payroll read the tax law of each country — Ohio/Pennsylvania local taxes, how a city changes a rate and how you’d know — before the tax expert was hired). Henrickson budgets this at “half your hours” — “what’s the point of writing a document if you don’t know what you’re talking about?” This is why Rippling keeps the product org thin: a single leader is expected to know the full scope, which great, natively-curious product leaders can.

Right a lot: his favourite principle. Product leaders must be right most of the time because their decisions “reflect across the entire org” and spend its time and energy. The valued, hard-to-test skill is going into an ambiguous situation with incomplete information and a complex decision space, listening and reading, and calling the direction with the confidence to be proven right a year later. “Either you’re really, really good at making those kinds of decisions or you’re not.”

Frameworks, hiring, and humility [§ Frameworks and hiring]

Anti-process, not anti-framework. Henrickson likes “just enough process to create a frame so the right decisions can happen, and no more.” The danger at scale is believing that perfect Jira categorisation produces good prioritisation — it doesn’t substitute for deep product thinking. He won’t mandate scrum/kanban; the right process is team- and life-cycle-specific. He unifies on only two things: the quarterly-planning process, and everything must be in Jira (or you can’t reason about what’s getting done). On engineering he is more prescriptive — strongly pro test-driven development.
Coinbase vs Rippling. Same mental model, different results from different domains: Coinbase optimised for reactivity under crypto/regulatory uncertainty; Rippling, under known demand, optimises day-to-day decision velocity (the device-management team isn’t debating whether Mac or Windows will exist).
Hiring PMs. A case study deliberately too large to fully answer, so the interviewer can change one assumption and watch how agile the candidate is (“oh, that has these 400 implications” vs flummoxed). Even more telling: the questions the candidate asks — done before the product discussion — which reveal genuine interest and depth (Kyle Boston, now head of platform product, asked an insight about underlying platform pillars after only weeks of context).
International expansion. Start before you think you need to — it’s harder and more specialised than first-timers expect, and “every country is unique”: you cannot drop a US approach into another country (a stray “color” without a u, a US social-security field in a demo, and “you immediately lose credibility”). Rippling’s thesis: a payroll/benefits/IT company that isn’t global won’t exist in ten years — and COVID pushed even very small companies multi-country, accelerating the timetable.
Career advice — be humble. “Being a product person means by definition you live in a world where no one knows the right answer yet, because if somebody did, they’d have already built it.” Humility (and being in an environment where you can say “I was wrong, let’s move on”) is the biggest differentiator in early-career leaders; the job is discovery every single day.
Working with a strong-opinioned founder. Be adaptable — “a moldable puzzle piece.” Parker is “incredibly strongly opinionated but also incredibly informed,” which makes for great debates; the prerequisite is a founder willing to be challenged, and a deep, mutual foundation of respect built over time.

Lightning round [§ Lightning round]

Books: the Baroque Cycle (Neal Stephenson) and the Culture series (Iain M. Banks).
Show/film: The Last of Us; Tenet (“a compound movie,” Lenny jokes — multi-timeline).
Favourite interview question: “What questions do you have for me?”
Tools: a Corsair H60 CPU cooler; Focal Bathys headphones (he’s an audiophile).
High-impact change: imperatives (above).
Off the clock: a board gamer — finished Pandemic Legacy with his kids, starting Gloomhaven.