New Products as Internal Startups
Incubate new products like funded startups: tiny teams, prove ROI before funding, keep them separate
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 90%
To ship multiple new products at once from a modest-sized org, Eeke de Milliano ran each new product like a startup where the company is the VC. Start with one or two people, withhold real funding until there's proven signal, and deliberately keep the team separate from the core org so it can move fast without getting bogged down in the realities of a mature product.
Origin
Eeke de Milliano, Head of Product at Retool; the approach let Retool (~300 people) launch three new products (Workflows, Mobile, Virtual Database) in a single year.
Core principles
- 01The parent company acts as the VC, funding with resources and access to the existing customer base
- 02Funding follows proof, not the other way around
- 03Small teams must prove ROI in engagement or revenue before scaling up
- 04Separation buys speed and independent thinking, at the cost of later integration work
How to run it
- 1
Start with one or two people
Staff each new initiative with just one engineer plus one designer or PM for roughly the first six months. They spend that time with customers, building, and prototyping.
Pro tip Keeping the team tiny keeps the stakes — and the cost of being wrong — low enough to swing boldly.
- 2
Withhold funding until there's a 'there' there
Don't add people or real resources until it's clear something real exists. The team must prove out ROI in engagement or eventually revenue to earn the right to move forward.
Pro tip Treat the parent company as a VC that funds with resources and, crucially, access to the existing customer base to market and promote to.
- 3
Keep the team deliberately separate early on
Run the new team independently — meeting on its own, reporting into just one or two leadership members, and kept apart from the core product — so it can move fast and think independently without core-product baggage.
Pro tip Separation lets the team discover a genuinely different target customer it would have missed if embedded in the core product.
Watch out Separation has a real cost: you end up with distinct products you must later invest in integrating, and it can feel like a lot of headspace for the org.
In the wild
Despite sharing many primitives with the core web-app builder, Retool debated and then chose to build Retool Mobile as a separate team so it could move quickly without getting bogged down in the realities of a PMF product (bugs, etc.). Halfway through, they realized Mobile had a quite different target customer.
→ Eeke de Milliano judged it 'absolutely the right call' — the team moved faster and reached a broader understanding of its distinct customer that would have been impossible inside the core product.
Retool launched Workflows, Mobile, and a Virtual Database in a single year by starting each tiny and funding on proof. In hindsight Eeke de Milliano felt she launched and matured all three at roughly the same time, which took a lot of org headspace even though the teams were small.
→ It worked out, but she concluded sequencing the launches would likely have felt more satisfying and less taxing for the whole organization.
Common mistakes
Funding a new product before there's proof
Pouring resources in before there's a demonstrated 'there' there raises the stakes and wastes headcount on unvalidated bets instead of forcing early customer proof.
Launching several new products in parallel instead of sequencing
Maturing multiple products at once consumes enormous org headspace and feels less satisfying than staggering the launches, even when the teams themselves are small.
Is it for you?
Best for
Product leaders at scaling companies who want to launch multiple net-new products without a huge org
Not ideal for
Companies still finding their single core product, or those unwilling to bear the later cost of integrating separate products
From the transcript
“we started really small with all these initiatives”
“one engineer and one designer or one engineer in one pm and they really didn't get funding until it was clear that there was something…”
“we really treated them like startups where like rituals the VC and like ritual funds with like resources”
“the teams really had to prove out Roi either in engagement or eventually Revenue in order to be able to move forward”
“really deliberate about keeping these teams separate from the rest of the org especially early on”
“we wanted the team to be able to move really really quickly and we didn't want it to get bogged down in what are just…”
From the episode
How to foster innovation and big thinking
Eeke de Milliano (Retool, Stripe)