The Internal Founder Pod
One entrepreneurial engineer, one designer, a platform apprenticeship, and a new product line in 6-9 months.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 8
- Confidence
- 93%
Rippling's repeatable model for launching a new product line inside an existing company. Rather than staffing a new business unit, you find a single extremely entrepreneurial engineer, pair them with one designer, make them apprentice on the existing platform for a few months, let them recruit two to four more zero-to-one engineers, and give them a monomaniacal mandate. Henrickson says Rippling has replicated this roughly a dozen times.
Origin
Jeremy Henrickson describes this as Rippling's standing model for starting new things, developed with CEO Parker Conrad. Henrickson explicitly rejects the theory that it works because the CEO is unblocking things — 'we've now replicated that like you know a dozen times... so it can't just be him unblocking things.'
Core principles
- 01The unit of a new product is a person, not a team plan: find the founder-type first.
- 02The founding engineer must be able to make decisions with low information and operate at tempo — not just write good code.
- 03Apprenticeship on the existing platform precedes building on it; the founder learns what's easy, what's hard, and what previous product founders wish they'd known.
- 04The pod must be shielded from every adjacent product except at explicit integration seams.
- 05Direct, frequent exposure to senior leadership beats routing feedback through the org chart.
- 06Team size is a function of lifecycle stage, not status: some products stay at five or six people forever, others jump from four to fifteen at production.
How to run it
- 1
Write the one-page view of the thing
Establish that you need to build it and articulate it on a single page. In most cases the category already exists in the industry — whole companies do only that — so you are not inventing the category, you are differentiating within it.
- 2
Find one extremely entrepreneurial engineer
Recruit (internally or externally) a single very talented systems engineer who is also capable of product thinking, understands operating at tempo, can make decisions with low information, and can work fast with a designer.
Pro tip Screen for founder temperament as hard as for engineering skill — this person is the CEO of the product.
Watch out A brilliant engineer without product thinking will build the wrong thing very well.
- 3
Assign one design partner
Pair the founding engineer with a single designer who knows the company's products, component library, and interaction and visual design conventions. One designer, not a committee, not an agency.
Watch out Do not confuse 'design partner' with a partner company. This is a person.
- 4
Run a platform apprenticeship for a few months
Before building anything, the founding engineer works on an existing team to learn the platform: what is easy, what is hard, how other products were built on it. They talk to the people who founded those products and learn from their experience, then form an opinion about their own product.
Pro tip This period is also where the founder absorbs the culture — including complex-case-first thinking, which is counter-cultural for most new hires.
Watch out Skipping the apprenticeship produces a product that fights the platform instead of compounding on it.
- 5
Let the founder recruit two to four zero-to-one engineers
During the apprenticeship, the founding engineer recruits their own small team of engineers with the same zero-to-one mentality. They build the crew they will lead.
- 6
Give a monomaniacal mandate and firewall the rest
The pod works on one thing and nothing else. They do not worry about the payroll product, the benefits team, or the IT products, except at explicitly identified points of connectivity to the rest of the suite.
Pro tip Name the integration seams up front so 'ignore everything else' has a defined boundary.
Watch out Horizontal communication load is the velocity killer. Every extra coordination surface you add to the pod costs weeks.
- 7
Pressure-test every couple of weeks with a senior DRI
The pod meets ad hoc — roughly every two weeks — with the CPO or CEO (whoever is the DRI) to review the latest designs and get critique. The reviewer role-plays the customer: 'if I were an admin at a small company, would this interface work for me?'
Pro tip The value is speed of feedback, not authority. Anyone senior can walk directly into the pod without traversing three org layers.
- 8
Right-size the team at launch, not before
As launch approaches, decide whether five or six people can carry the product indefinitely or whether it must scale to fifteen for production operations. Let the product's nature dictate this.
Pro tip Re-check that the zero-to-one people still want the job. Scaling a product to millions is a different job that they may neither love nor be good at.
Watch out Leaving the zero-to-one crew on a scaling product for two or three years produces quiet underperformance and attrition.
In the wild
Around 2020 Rippling saw strong market demand for a time and attendance product it had not built. Rather than standing up a business unit, it picked one very talented systems engineer capable of product thinking (Sasha), had CEO Parker Conrad spend time on it, and let that engineer bring on a few more people. Four people worked on nothing else, ignoring payroll, benefits, and IT except at integration points.
→ A shipped time and attendance product in roughly nine months. The pattern was then replicated about a dozen times across Rippling's product lines, proving it was the small-focused-team structure and not CEO unblocking that produced the speed.
Common mistakes
Attributing the speed to the CEO
Founders assume these pods only work because a powerful executive clears roadblocks. Rippling ran it a dozen times; the CEO cannot be the mechanism. The mechanism is small size, single mission, and direct access to anyone senior.
Letting the pod build before it learns the platform
Skipping the few-month apprenticeship means the founding engineer never learns what the platform makes easy or hard, so they rebuild what exists and fight what doesn't.
Keeping the zero-to-one team on the product forever
The people who are amazing at going from nothing to something are frequently neither happy nor effective scaling that same product to millions of users two years later. Recalibrate the team deliberately.
Is it for you?
Best for
Multi-product companies (or ambitious startups) with a real internal platform, wanting to launch a genuinely new product line without spinning up a bureaucratic business unit.
Not ideal for
Companies with no shared platform to apprentice on, or work that requires deep cross-team coordination from day one rather than a firewalled mandate.
From the transcript
“we find a single engineer who is extremely entrepreneurial understands what it means to operate at Tempo understands what it means to like make decisions…”
“they were they were mono maniacally focused on this one thing and then identifying to places where yes there's connectivity to the rest of the…”
“everyone is exposed to senior leadership like yes we have like a management structure because you have to but that management structure does not interfere…”
From the episode
Moving fast and navigating uncertainty
Jeremy Henrickson (Rippling, Coinbase)