There’s a phrase that gets thrown around in product and design circles: “0 to 1.” But in practice, most 0 to 1 teams are hard to distinguish from teams who have been iterating on an existing product for years. These teams treat 0 to 1 like any other design challenge, and that’s where things go sideways.
In this context, “0 to 1” has come to mean more than just building something new. It’s starting the design process before you have the research, the validated assumptions, or even a clear problem definition that would normally guide you. All you have is a whole lot of decisions to make that will inevitably be harder to undo than they seem.
The most common mistake I see is teams defaulting to the same process they use for everything else. They schedule discovery workshops, start assembling component libraries, and spend weeks getting the UI just right for a product that has not yet proven it should even exist. They go deep into their original process as if the product has already proven its existence. The effort is genuine and all these steps are valuable. But not now. The prioritization is off.
At this stage, there’s really only 1 question worth designing toward: does this thing actually work? Not “does it look good?” Not “will it scale?” Not “is the onboarding optimized?” Those are real questions, but they belong to a later stage. The most valuable thing you can do at this point is get something, anything, in front of real users as fast as possible. Getting into the details too early is how teams end up with a beautifully designed product built on assumptions nobody ever tested.
The designers I have known who do this well share a quality that sounds simple but is genuinely hard for many designers to develop: they don’t get attached to their work. One way to keep yourself from getting too attached is to intentionally timebox your work. Give yourself 3 days to design something, share it, and be willing to throw it away. Just remember that most of what you build in this phase won’t survive contact with real users, and you must be okay with that. That willingness to be wrong quickly is actually the whole mechanism by which 0 to 1 design works.
If your team is running a full production process on an early-stage product, it might be worth stepping back and asking an uncomfortable question: Are you optimizing for the product, or for the comfort of working within your normal process?
I’m curious what others have run into here. What does 0 to 1 design actually look like on your team?