How to build innovative product teams: lessons from Stripe and Retool

Executive overview

Most teams default to incremental work — not from lack of ambition, but because fear of failure, operational debt, and no protected time to think crowd out bold ideas. Eeke de Milliano, head of product at Retool and former early PM at Stripe, shares how both companies created the conditions for sustained innovation.

The levers are structural: normalise failure publicly, protect thinking time deliberately, run new products like internal startups, and build complementary talent rather than cloning yourself.

The best product cultures don't just tolerate big thinking — they schedule it.

Why teams stop being innovative

• Fear of failure: leaders want the upside of innovation but resist the cost — failed swings
• Normalize failure by shining light on it: retrospectives over postmortems, public write-ups of learnings, "biggest failure" awards
• Give teams more at-bats: small teams, early customer feedback, low resource stakes per bet
• Operational debt kills creative capacity — diagnose and clear it before expecting bigger thinking
• Thinking big takes protected time; without explicit permission it won't happen

Creating permission to think bigger

• Retool's team charters include a "Think Bigger" section: what would you do with 20% more time?
• "Crazy Ideas" doc: sent org-wide at start of year, prompts for ideas with 90% chance of being wrong but 10x upside if right
• Consistently 3–8 ideas from the doc ship each year; at least two of Retool's three 2022 product launches originated there
• Hackathons create similar moments; planning processes should ask "if you doubled the team today, what would you do?"
• Leave the Think Bigger section unstructured — less template means less intimidation

What made Stripe's culture work

• Think rigorously: first-principles questioning was cultural, not performative — "best practice" was never an acceptable answer
• Strong writing culture: Stripe ran on written memos, strategy docs, and business reviews; clear writing forced clear thinking
• Quick decision-making balanced rigor: the trapdoor decision (one-door vs two-door) framework distinguished decisions requiring long deliberation from those that didn't
• Pricing is rarely a trapdoor decision; titles are — Stripe was deliberately slow on titles
• Operating principles ("move with urgency and focus", "users first", "micro-pessimists, macro-optimists") came from the founders and trickled through hiring

Launching three products in one year

• Retool launched Workflows, Mobile, and Database in 2022 — each started with one or two people for six months
• Teams got more resources only after proving customer signal — Retool acted as VC, teams proved ROI
• New product teams were kept deliberately separate from the core org to preserve speed and independent thinking
• Retool Mobile discovered a materially different target customer mid-project; separation made that realisation possible
• In hindsight: sequencing launches would have reduced org cognitive load, but the approach worked

Process as variance reduction

• Minimum viable process (MVP): introduce only what's needed; always offer escape hatches
• Process reduces variance — it lifts the floor but lowers the ceiling, dragging down high performers who don't need it
• Templates should say: "if this doesn't work for what you're explaining, don't use it"
• Three documents every team needs at every stage: charter (mission, vision, strategy), goals (success metrics), roadmap (what ships)
• Time horizon shifts with maturity: early-stage charter looks 3 months out; established company charter looks a decade out

Product building frameworks

• Build for your best user, not your worst: don't warp the product around edge cases and abuse scenarios — they're a fraction of users
• Build the scooter, not the axle: MVP means a complete, working smaller thing — not a partial component of a future bigger thing
• 70-20-10 investment split: 70% core product (including tech debt), 20% strategic non-core initiatives, 10% bets
• Time horizon for charters should match company maturity; teams naturally plan bottom-up (roadmap → charter) but should work top-down

Getting close to customers

• Retool PMs frequently came from customer-facing roles (sales, success) — builds visceral understanding of value
• All PMs have CS degrees or engineering backgrounds given the technical product
• Hundreds of Slack channels with customers provide direct feedback loops during new product testing
• Retool uses Retool internally — product roadmap, feature flags, internal tooling all run in Retool apps

The product talent portfolio

• Resist building a team in your own image — you'll over-index on skills you can already assess
• Balance homegrown PMs (deep product knowledge, culture carriers) with external hires (broader PM craft, outside perspectives)
• Balance execution-oriented PMs with visionary PMs across pillars
• Personal exercise every six months: map the team's strengths and weaknesses, then hire specifically for the gaps
• Managers are the unlock: they must detect high performers who don't need process and give them air cover — "are you willing to break the org for this person?"