culture-as-product-os skill

---
name: Culture-as-Product Operating System
description: Treat company culture as a product you build for employees. Iterate on it using feedback loops (NPS), identify bugs, and evolve it—don't try to preserve a static version.
---

# Culture-as-Product Operating System

> "Every company builds two products: one is the product they build for their customers, and the other is a product they build for their team. That's what culture is." — Dharmesh Shah

## What It Is

Treat company culture as the **"product" you build for employees** (your customers). Just as you wouldn't freeze code on a product, you shouldn't freeze culture.

## When To Use

- **Scaling beyond** the founding team
- When **employee sentiment** begins to drift
- Culture feels like **"HR fluff"** or posters on walls
- Need to **evolve culture** while preserving core values

## The Operating System

```
┌─────────────────────────────────────────────────────┐
│              CULTURE-AS-PRODUCT OS                  │
├─────────────────────────────────────────────────────┤
│  INPUT: Employee Feedback (NPS surveys)             │
│     ↓                                               │
│  TRIAGE: Identify "bugs" in the culture             │
│     ↓                                               │
│  DECISION: Fix or mark "Works as Designed"          │
│     ↓                                               │
│  OUTPUT: Updated cultural practices                 │
├─────────────────────────────────────────────────────┤
│  FEDERAL LAWS: Non-negotiable core values           │
│  STATE LAWS: Team-specific adaptations              │
└─────────────────────────────────────────────────────┘
```

## Core Principles

### 1. Run Employee NPS
Measure satisfaction quantitatively (0-10) and qualitatively (Why?).

### 2. Identify Bugs
Treat cultural complaints as "bugs" in the product. Acknowledge them publicly.

### 3. Fix or "Won't Fix"
Commit to fixing valid bugs, OR explicitly state "It works as designed" (e.g., "Yes, transparency is uncomfortable, but it's a feature, not a bug").

### 4. Federal vs. State Laws
- **Federal Laws**: Non-negotiable core values (e.g., transparency)
- **State Laws**: Team-level adaptations (e.g., Sales floor noise vs. Engineering quiet)

## How To Apply

```
STEP 1: Measure Regularly
└── Quarterly eNPS surveys
└── Anonymous feedback channels

STEP 2: Triage at All-Hands
└── "Here are the bugs you reported..."
└── Public acknowledgment builds trust

STEP 3: Categorize Each Bug
└── Will Fix: Prioritize and timeline
└── Won't Fix: Explain why it's intentional
└── Feature Request: Add to backlog

STEP 4: Ship Updates
└── Announce culture changes like product releases
└── Measure impact in next survey
```

## Common Mistakes

❌ Thinking the job is to **preserve** culture (it's to **evolve** it)

❌ Ignoring feedback because "culture can't be changed"

❌ Making everything a "Federal Law" (no team autonomy)

## Real-World Example

HubSpot's transparency policy (making everyone an "insider") was a Federal Law, but seating arrangements evolved from lottery-based to team-based as the company scaled.

---
*Source: Dharmesh Shah, Lenny's Podcast*