The Solve Before Scale Protocol
Overview
A phased approach to product development that prioritizes solving a core problem with qualitative signals before attempting to scale with quantitative metrics.
Core principle: Prototypes > PRDs. Build to think; use prototypes to discover what to build.
The Two Phases
code
┌─────────────────────────────────────────────────────────────────┐ │ PHASE 1: SOLVE │ ├─────────────────────────────────────────────────────────────────┤ │ • Embrace chaos and "wide lurches" in direction │ │ • Ignore "grownup metrics" (CTR, retention) │ │ • Focus on qualitative "magic moments" │ │ • Build prototypes to discover what to build │ │ • Find the core utility that users love │ ├─────────────────────────────────────────────────────────────────┤ │ PHASE 2: SCALE │ ├─────────────────────────────────────────────────────────────────┤ │ • Only AFTER core utility is proven │ │ • Operationalize and optimize │ │ • Apply standard growth metrics │ │ • Add polish and expand scope │ └─────────────────────────────────────────────────────────────────┘
Key Principles
| Principle | Description |
|---|---|
| Embrace chaos | Early stage should feel messy |
| Qualitative first | Magic moments > conversion rates |
| Prototype to think | Build to learn, not to ship |
| Delay metrics | Growth metrics come in Scale phase |
Common Mistakes
- •Applying false precision (metrics) too early
- •Fearing the chaos of early "solve" phase
- •Scaling a product that hasn't truly solved core need
Source: Aparna Chennapragada (Microsoft CPO) via Lenny's Podcast