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