Why early-stage and enterprise products require fundamentally different design approaches.
The skills that build a product from nothing are largely incompatible with the skills that scale it. Exploration and consolidation require different intuitions, different success metrics, and different tolerances for ambiguity. Understanding which phase you're in, and designing accordingly, is one of the most underrated product skills.
In the early stage, your job is to discover, not to optimise. Consistency is less important than learning. Moving fast matters more than maintaining standards. A design system at this stage is often premature, it locks in patterns before you know if they're right.
The metrics that matter here are qualitative: are users getting value? Are they coming back? Can they articulate what the product does for them? Quantitative optimisation against a leaky hypothesis is expensive and misdirected.
In the zero-to-one phase, the cost of being wrong about a pattern is low, you can change it. The cost of not learning fast enough is high. Optimise for learning rate, not consistency.
Once you know what works, the job changes. Consistency matters. Onboarding new users at scale requires predictability, users can't call you when they're confused. An enterprise customer with a hundred users needs reliability, not novelty. The feature that felt delightfully clever at five hundred users can become confusing noise at fifty thousand.
This is the phase where a design system pays dividends. Where documentation earns its cost. Where the informal decisions of the early stage need to be formalised and made consistent.
Most product failures happen in the transition between phases. Teams keep moving fast when the product needs consolidation. Or they consolidate prematurely, freezing patterns before the product has found its footing.
The signal that you've crossed the threshold: when fixing something breaks more than it helps. When adding a feature creates support tickets. When the onboarding drop-off is about confusion, not value. At that point, the product is telling you it needs system work, not feature work.
Key Takeaways
In zero-to-one, optimise for learning rate, not consistency or polish
The transition to scale requires a deliberate shift in success metrics
Premature consolidation is as dangerous as staying in exploration mode too long
Watch for the signal: when fixing things breaks more than it helps, you need systems work
More from the journal
The hard problem is not showing more profiles. It is deciding who gets seen, how often, and under what fairness rules.
Jun 2026
A practical look at scale, rhythm, hierarchy, responsive type, and the token decisions that make text usable across product surfaces.
Jun 2024
Foundations, surfaces, semantic roles, accessibility, and how to build an 11-stop scale that teams can apply consistently.
Jun 2024