Peter Thiel's framing in Zero to One is useful but incomplete. He tells you what the destination looks like: a monopoly built on a secret others have not yet discovered. He does not give you the pre-flight checklist for getting there.
Most founding teams skip zero-to-one readiness entirely. They move from idea to sprint planning in weeks. The result is a product that works technically but fails commercially, because it was built before the team had earned the right to build.
These six conditions are the checklist that separates teams who are ready to build from teams who are not.
Thiel's core question: what important truth do very few people agree with you on? If your competitive analysis begins and ends with "our UX is better," you do not have a secret. You have a bet on execution quality. That is a venture, not a monopoly.
A real secret is a belief about the world that is not yet consensus but will be. It could be a behavioral insight, a regulatory opening, a technology timing thesis, or an underserved segment that incumbents dismiss. It must be specific enough to be falsifiable. "People want better productivity tools" is not a secret. "SME finance teams abandon 70% of expense workflows because approval chains break at the CFO layer, and no tool currently fixes that specific handoff" is a secret.
Your ideal customer profile should be specific enough that you could find 50 of them on LinkedIn this afternoon. Not "enterprise HR teams" but "HR directors at US-based logistics companies with 500 to 2,000 employees who report to the COO, not the CEO." Specificity here is not a constraint on growth. It is what makes early traction possible.
The reachability test matters as much as the definition. If you cannot describe how you will get in front of your first 20 customers at low cost, you do not have a distribution strategy. You have a product strategy with a distribution assumption hiding inside it.
The problem your product solves needs to be painful enough that people either pay to address it today (with an inferior solution), or that you can document its cost in time, money, or risk. Talking to users who "would use" a hypothetical product is not evidence. Finding 10 users who already do something clunky and expensive to address the same need is.
Willingness to pay in the current state is the strongest signal available before you have built anything. If nobody is paying anyone for anything related to your problem today, spend more time validating that the problem is real before writing a requirements doc.
Distribution kills more startups than product quality. Most teams know this and plan to think about it later. By the time they think about it, they have built something nobody can find.
Before building, identify one channel where you have an unfair advantage or genuine insight. That means a network, a content surface, a partnership, or a community access that most competitors do not have. Paid acquisition is not a channel at the zero-to-one stage. It is a scaling mechanism for a channel that already works.
For a technology startup, the minimum viable team covers three functions: someone who can build the product, someone who can sell it, and someone who understands the domain deeply enough to make design decisions. These do not need to be three different people, but all three functions need a human owner.
The coverage gap that kills most early teams is not technical. It is commercial. A team of three engineers building a sales tool without a former salesperson is not hedging their bets. They are flying blind in the highest-risk part of the business.
The zero-to-one phase is fundamentally a research operation. The job is not to build a product. The job is to learn whether a product of this type can find a market. That means having a hypothesis that is specific, time-bounded, and testable.
"We believe that HR directors at logistics companies will pay 200 USD per month for automated approval routing in expense workflows, and we will prove or disprove this in 90 days by running 5 paid pilots" is a falsifiable hypothesis. "We are building an AI-powered expense management platform" is a roadmap item, not a learning agenda.
Score each condition on a 0-2 scale. Zero means you have no evidence or definition in this area. One means you have a hypothesis but no external validation. Two means you have external validation from at least 5 real conversations or data points.
A score of 10 or above out of 12 means you are ready to move to the build phase. Below 10, identify the two lowest-scoring conditions and spend the next 30 days closing those gaps before writing a single line of code.
The zero-to-one check is also available as an interactive tool at duku.xyz/tools/zero-to-one.
Common failure mode: Teams score themselves generously on condition 1 (having a secret) and condition 6 (having a hypothesis) because both are easy to articulate without external validation. Force yourself to score these based on what you have shown to outsiders, not what you believe internally.
Duku runs zero-to-one strategy sessions for founding teams who want an outside perspective on whether they are ready to build. If you want a structured readiness review before your next funding conversation or product sprint, reach out.