builder-operating-model skill

---
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*