Solve Before Scale
Run in a distinct 'solve' mode before you ever switch to 'scale' mode
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 94%
Zero-to-one work demands a different posture than scaling. In solve mode you tolerate wide lurches in direction and refuse to commit to grown-up metrics too early. Only once a problem is genuinely solved (roughly post product-market-fit) do you switch to the metrics-driven discipline of scaling. Deciding a metric prematurely is false precision that locks you onto the wrong hill.
Origin
Aparna Chennapragada's operating principle for her teams, drawn from building Google Lens and other zero-to-one products.
Core principles
- 01'Scale before solve' is the default temptation — resist it
- 02Solve mode and scale mode require different postures and tolerances
- 03Premature metrics are false precision (CTR/retention across a thousand users mean nothing)
- 04In solve mode, qualitative signal beats quantitative metrics
How to run it
- 1
Name which mode you are in
Explicitly decide: are you solving a problem, or scaling something already roughly at product-market-fit? The two are not the same job.
Pro tip Make the mode an explicit team declaration so people know which behaviors are expected.
Watch out Companies climb a premature local hill in scale mode and three years later can't figure out how to get off it.
- 2
In solve mode, embrace the chaos
Expect wide lurches — day one you're building plant detection, day fifteen the tech is better at translating foreign text. Have an appetite for that, not just tolerance of it.
Pro tip Treat a directional pivot as evidence you're finding the real intersection, not as failure.
Watch out Prematurely fixing on one local hill is the thing you most want to avoid in solve mode.
- 3
Refuse grown-up metrics too early
Don't anchor on CTR or retention when you have a thousand users — the precision is false. Watch qualitative signal instead: the sound of the click, what people actually reach for.
Pro tip Find the one or two things the product is genuinely great at before claiming it can do anything.
Watch out Deciding on a metric too prematurely gives false precision and steers the whole effort wrong.
- 4
Switch to scale mode only after solving
Once the problem is genuinely solved, adopt the input/output metrics and disciplined iteration that scaling requires.
In the wild
The team started aimed at plant detection and discovered the tech was really strong for translating foreign language — a day-1-to-day-15 shift that looked like chaos from outside.
→ By staying in solve mode they found the right intersection instead of prematurely committing to the wrong use case.
Alexa, Siri and Google Assistant had a broad 'say anything' interface but were really only good at a couple of things — set a timer, play music, play trivia.
→ Nailing those few things first is the recipe; promising 'you can do anything' before that is not.
Common mistakes
Scaling before solving
Rushing to scale a product whose core problem isn't actually solved yet — the underpants-gnomes trap.
Worshipping early metrics
Treating CTR or retention on tiny samples as meaningful and optimizing against noise.
Is it for you?
Best for
Product leaders and founders running a new zero-to-one product or feature who feel pressure to show metrics early
Not ideal for
Mature products past product-market-fit where rigorous input/output metrics are exactly what's needed
From the transcript
“there's a temptation to rush and say uh to go to scale scale before solve. So I've always said uh to my teams solve before…”
“when you look at the solve stage, there are wide lurches”
“if you decide on a metric too prematurely that's false precision first of all”
“you got to nail those things before you say, "Oh, yeah, here you can do anything with it."”
From the episode
Microsoft CPO: If you aren’t prototyping with AI, you’re doing it wrong
Aparna Chennapragada