Fast-Thinking / Slow-Thinking Org Split
Split product org into a weekly-shipping AI group and a deliberate-infrastructure group so both speeds coexist.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 95%
Instead of organizing product teams around feature surface areas (which produces only incremental improvement), split the org into two complementary halves: a 'fast thinking' group that ships jaw-dropping AI capabilities on a near-weekly cadence, and a 'slow thinking' group that makes deliberate, premeditated infrastructure bets that take longer than a week. The fast group generates top-of-funnel excitement and new use cases; the slow group builds the durable data/scale foundations that let that adoption sprout into large deployments.
Origin
Howie Liu's naming borrows directly from Daniel Kahneman's 'Thinking, Fast and Slow' (System 1 / System 2), which Liu references on the show. The org-design application to an AI-era product team is Liu's own, developed after several Airtable reorgs over ~4 years.
Core principles
- 01Feature-area teams think incrementally by definition; mission/outcome teams can coordinate dramatic changes across surfaces.
- 02You need both fast and slow thinking to operate sanely — neither mode is 'better.'
- 03Fast execution creates the top-of-funnel excitement; slow thinking turns adoption seeds into durable, expanding deployments.
- 04Benchmark your fast group against AI-native companies (cursor, Windsurf): are you shipping as fast and taking advantage of everything they are?
How to run it
- 1
Diagnose why you move slowly
Audit your current structure. If teams are each responsible for a feature or surface area (search, mobile, etc.), recognize that their remit is incremental improvement by definition — nobody is chartered to make step-function, cross-surface bets.
Pro tip Ask: 'Are we executing as fast as an AI-native company like cursor or Windsurf, and taking advantage of all the new stuff as well as them?'
Watch out Business-unit reorgs (enterprise vs teams vs AI pillars) are more holistic than feature teams but can still fragment into separate roadmaps that prevent moving as one cohesive product.
- 2
Carve out a fast-thinking group
Create a group (Liu calls it 'AI platform') whose mandate is to ship genuinely new capabilities on a near-weekly basis, each one delivering 'drop your jaw' value. This group prototypes, experiments, and iterates rather than following deterministic timelines.
Pro tip Set the quality bar explicitly: every shipped capability should make a user's jaw drop at how awesome it is, not just 'work.'
Watch out Don't measure this group by 8-week timelines and headcount plans — that deterministic resourcing mindset is exactly what kills weekly shipping.
- 3
Carve out a slow-thinking group
Create a parallel group for deliberate bets that require premeditation — infrastructure with real data complexity that cannot be shipped as a hacky one-week prototype (e.g. a data store handling hundred-million-record datasets).
Pro tip Frame it as a different mode, not a lesser one: 'you need fast and slow thinking and the common sense to operate, like a human.'
Watch out Trying to force infrastructure bets through the fast group produces bugs, data and security issues, and context collapse.
- 4
Engineer the handoff between them
Design the two groups to complement each other: the fast group's AI launches create top-of-funnel excitement and new use cases; the slow group's infrastructure lets those initial adoption seeds retain and expand into much larger deployments.
Pro tip Watch for the classic AI-native failure mode — a wide top-of-funnel of 'AI tourist' traffic that never converts to durable growth. The slow group is your answer to it.
In the wild
After feature-area teams and then business-unit pillars both failed to let Airtable 'aggressively and quickly move as an AI native company would,' Liu reorganized into the AI-platform (fast) group shipping capabilities near-weekly and a slow group building infrastructure like hyperdb, a data store now handling hundred-million-record datasets.
→ Roughly half of Airtable's product/engineering org now works on AI capabilities shipping quickly, while the slow group's infrastructure converts wide AI adoption into larger, more durable enterprise deployments.
Common mistakes
Treating the two groups as a hierarchy
If leaders signal the fast group is 'the real work' and the slow group is second-class, the infrastructure that converts tourist traffic into durable revenue gets starved. Liu is emphatic the split is about mode, not merit.
Forcing infrastructure through the fast lane
Shipping data-complex infrastructure as a hacky one-week prototype produces bugs, data and security problems, and context collapse. Deliberate bets need the slow group's premeditation.
Is it for you?
Best for
A CEO or head of product at a scaled, pre-AI SaaS company that ships too slowly on AI and whose teams are siloed by feature surface area.
Not ideal for
Early-stage startups with one small team still finding product-market fit — they don't yet have enough surface area or people to split, and premature structure will slow them down.
From the transcript
“the what I call like the fast thinking uh group which officially is called AI platform uh but it really means like we want to…”
“then separately we have the slow thinking group that's not me meant to be like better or worse like it's it's literally like you need…”
“the slow thinking basically allows those initial seeds of adoption to sprout and grow into much larger deployments”
From the episode
How we restructured Airtable’s entire org for AI
Howie Liu (co-founder and CEO)