0→1 work requires a different mindset
Let’s face it, the phrase “zero to one” has been butchered. What Peter Thiel described in 2012 was a philosophy of innovation — vertical progress, creating something genuinely new versus copying and scaling what already exists. What the industry turned it into is a project phase. “We’re in the 0→1 stage” now means “we haven’t shipped yet.”
Those are not the same idea.
Thiel’s original framing was about the kind of thing you’re building, not where you are in building it. A team cloning an existing SaaS product with minor differentiation is doing 1→n work even if it’s pre-launch. A team discovering an entirely new interaction model is doing 0→1 work even after they ship. The distinction was never about timeline. It was about whether you’re creating a new category of value or replicating an existing one.
The industry collapsed that into a lifecycle label. Product blogs now define 0→1 as “the phase between the idea and the MVP.” Job descriptions list “0→1 experience” as a credential — a checkbox that means “I was there when something launched.” Resumes claim it like a badge. None of that is what Thiel was talking about.
Julie Zhuo wrote one of the better practitioner takes — four stages from defining people outcomes through product-market fit. Useful framework. But it’s already operating inside the diluted version: product lifecycle, not innovation philosophy. Even the thoughtful interpretations have drifted from the original.
Here’s what I think actually matters about 0→1 work, and it’s neither Thiel’s macro-philosophy nor the industry’s phase label.
Zero means there is no repeatable proof yet. There may be conviction, prototypes, internal excitement, scattered signals. But the case hasn’t become durable. Nothing you could hand to someone else and say “this is why it should exist” and have them verify it independently.
One means the first credible proof that the thing should exist. Not scale. Not polish. Not a platform. Just enough evidence that the problem, user, wedge, and value-delivery mechanism are real.
That makes 0→1 a proof contract, not a timeline.
And proof contracts are demanding. I’m building a product right now — working, functional, people signing up — and the validation contract is still weaker than the operational momentum around it. Real user and buyer conversations are still missing. The product can move fast and still be somewhere between zero and one on the dimensions that actually matter. Motion is not proof.
An older example makes the complementary point. At Knewton, the team was building one of the first adaptive learning products for classrooms. An early student-invite feature started with rich mechanics — CSV import, saved lists. After pressure-testing with engineering and product, it got cut to manual email entry. Not because the smaller version was glamorous. Because it was reversible, learnable, and put the product into teachers’ hands sooner. That’s a real 0→1 decision: choosing the smallest thing that generates proof, not the most complete thing you can build.
AI makes this worse, not better. It’s much faster to make ideas tangible now. Prototypes, flows, copy, code — all cheap. Which means it’s easier than ever to confuse output with evidence. A team can generate extraordinary momentum before it has generated any truth.
The proof threshold matters more now, not less. And “we’re doing 0→1 work” as a vibe doesn’t help anyone hold that line.
If the team hasn’t named what would have to be true to move from zero to one — specifically, falsifiably — then they’re not doing 0→1 work. They’re just early.