---

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

Copy┌─────────────────────────────────────────────────────┐
│              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

CopySTEP 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