home / skills / coowoolf / insighthunt-skills / solve-before-scale

solve-before-scale skill

safe

This skill helps you navigate zero-to-one product efforts by solving core problems first through qualitative prototypes before scaling with metrics.

npx playbooks add skill coowoolf/insighthunt-skills --skill solve-before-scale

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.8 KB

---
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*

Overview

This skill teaches a two-phase product development protocol that prioritizes solving a core user problem with qualitative signals before attempting to scale. It emphasizes prototypes and discovery over early optimization and numeric metrics. Use it to avoid premature scaling and to find the true product utility users love.

How this skill works

The protocol separates work into SOLVE and SCALE phases. In SOLVE, teams run wide exploratory experiments, build quick prototypes, and surface qualitative 'magic moments' that reveal core utility. Only after those signals are validated does the team move to SCALE, where standard growth metrics, operationalization, and polish are applied.

When to use it

Building zero-to-one products where the solution shape is unknown
When teams rely on growth metrics too early and get false confidence
Starting a new feature with unclear user value or few real users
Reframing roadmap decisions after several unsuccessful launches
When you need to prioritize discovery over execution speed

Best practices

Treat prototypes as learning artifacts, not final deliverables
Focus interviews and observation on 'magic moments' and user delight
Avoid using CTR/retention as success criteria in early discovery
Allow direction changes and tolerate messy experiments in SOLVE
Define clear criteria to transition from SOLVE to SCALE (qualitative proof of core utility)

Example use cases

A startup validating whether a new search interaction actually saves users time before building full infrastructure
A product team exploring several radically different onboarding flows to see which creates authentic user delight
A feature experiment where prototypes expose the single function users return for, then the team dedicates resources to scale it
A company pivoting after prototypes show a different core utility than originally assumed

FAQ

How long should the SOLVE phase last?

Long enough to surface repeated qualitative signals and clear user behaviors; duration varies but prioritize learning milestones over fixed timelines.

When is it safe to start tracking growth metrics?

Begin tracking standard metrics only after you have validated the core utility with qualitative evidence and initial user repeat behavior.