| name | solve-before-scale |
| description | Use when building zero-to-one products, when the solution shape is undefined, or when teams are applying growth metrics too early |
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
┌─────────────────────────────────────────────────────────────────┐
│ 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
