| 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
