builder-operating-model

name	Builder Operating Model
description	Shift from rigid roles (PM, Designer, Engineer) towards a model where individuals use AI to bridge skill gaps, enabling smaller and flatter teams. Use in early-stage startups or innovation units where speed is critical.

The 'Builder' Operating Model

"We need to dissolve the boundaries of these traditional roles and call ourselves builders." — Julie Zhuo

What It Is

A shift away from rigid titles (PM, Engineer, Designer) towards a model where individuals use AI to bridge skill gaps. This allows for smaller, flatter teams where engineers might define product requirements and designers might prototype code.

When To Use

• Early-stage startups where speed is critical
• Innovation units within large corps
• Teams want to reduce handoff overhead
• When AI tools make cross-functional work accessible

Core Principles

1. Dissolve Boundaries

Don't say "I need a PM for this"; ask "Can I use AI to help me define the requirements?"

2. AI as a Skill Multiplier

Use tools (like ChatGPT/Cursor) to raise your competency in adjacent fields from 0% to 70%.

3. Smaller, Empowered Teams

Remove middle-management layers. A team of two "builders" can now do what a squad of 5 used to do.

4. Investment in Learning

Use AI not just to do the work, but to teach you the why behind the work (customized curriculum).

The Model Shift

TRADITIONAL                    BUILDER MODEL
┌────────────────┐            ┌────────────────┐
│      PM        │            │                │
├────────────────┤            │    BUILDER     │
│   Designer     │  ───────►  │   (uses AI)    │
├────────────────┤            │                │
│   Engineer     │            └────────────────┘
└────────────────┘            
     5 people                     2 people
     3 handoffs                   0 handoffs

How To Apply

STEP 1: Audit Current Handoffs
└── How many people touch a feature before shipping?
└── Where does context get lost?

STEP 2: Identify AI-Bridgeable Gaps
└── Engineer can't write PRD? → AI assists
└── Designer can't code prototype? → AI assists

STEP 3: Restructure Teams
└── Reduce from squad to 2-3 builders
└── Each person owns end-to-end

STEP 4: Invest in AI Fluency
└── Train team to use AI for adjacent skills
└── Celebrate cross-functional contributions

Common Mistakes

❌ Thinking everyone must be an expert at everything (specialists still needed for complexity)

❌ Using AI only for execution, not for learning

❌ Removing specialists prematurely for truly complex domains

Real-World Example

At Sundial, they often don't hire dedicated Product Managers. Engineers are expected to own the "what" and "why" of what they build, using AI to help draft requirements or analyze data if needed.

---

Source: Julie Zhuo, Lenny's Podcast