What 0-to-1 product creation is and why it's different
0-to-1 product creation is the process of taking a product from idea to first paying customers. It's fundamentally different from iterating on an existing product (1-to-N), because you're operating in maximum uncertainty: you don't know if the problem is real, if your solution is right, if customers will pay, or if you can deliver it. Every assumption is unvalidated. Every decision is a bet.
The mindset shift is critical. In 1-to-N PM, you have data, users, revenue, and organizational structure. In 0-to-1, you have hypotheses, assumptions, and a blank canvas. The skills that make a great 1-to-N PM (data analysis, A/B testing, stakeholder management) are less valuable than the skills needed for 0-to-1: rapid experimentation, comfort with ambiguity, direct customer conversation, and the ability to kill your own ideas when evidence says they're wrong.
The PM's role in 0-to-1 often blurs with founder, researcher, designer, and salesperson. You're not managing a team that builds what you spec — you're doing whatever it takes to learn whether this product should exist. That might mean cold-calling potential customers, building a prototype yourself, running a concierge MVP, or standing outside a store asking people questions.
MVP strategy
MVP Definition Canvas Core Method
Use when: scoping the minimum version of your product that tests your core hypothesis.
An MVP isn't a crappy version of your product — it's the smallest thing you can build that tests your riskiest assumption. Fill out:
- Core hypothesis — what must be true for this product to succeed? (e.g., "Busy professionals will pay $30/month for AI-curated news briefings.").
- Riskiest assumption — which part of the hypothesis are you least sure about? (Is it the willingness to pay? The AI quality? The target audience?).
- Minimum test — what's the smallest thing that tests that specific assumption? (A landing page with a payment form tests willingness to pay. A manually curated email tests whether the content format works.).
- Success criteria — what result convinces you to continue? (e.g., "5% of landing page visitors enter payment details.").
The canvas forces you to separate "what I need to learn" from "what I want to build." The MVP tests the learning; it doesn't have to be a product at all.
Concierge MVP Technique
Use when: you want to validate value delivery before building any technology.
A concierge MVP delivers the product's value manually to a small number of customers. Instead of building an AI recommendation engine, you personally recommend products to 10 users based on their preferences. Instead of building a scheduling tool, you manually coordinate schedules for 5 teams via email. The customer gets the value; you learn what they actually need. The concierge approach reveals: which parts of the value proposition customers care about most, what workflows they expect, what edge cases exist, and whether they'll pay. Only after validating these do you automate.
Fake Door Test Technique
Use when: you want to measure demand before building anything.
A fake door test presents a feature or product to users as if it exists, then measures how many try to use it. Examples: a "Premium" button in your free product that leads to a "Coming soon, join waitlist" page. A landing page for a product that doesn't exist yet, with a signup form. A menu item in your app that leads to an interest survey. Measure click-through rate, signup rate, and waitlist conversion. If nobody clicks the button, there's no demand — you just saved months of development. If 15% click and 3% sign up for the waitlist, you have a signal worth pursuing.
Finding product-market fit
Product-Market Fit Survey (Sean Ellis) Core Method
Use when: you've launched and need to measure whether you've achieved PMF.
Ask users: "How would you feel if you could no longer use [product]?" Options: Very disappointed, Somewhat disappointed, Not disappointed, I no longer use it. If 40%+ answer "Very disappointed," you likely have product-market fit. Below 40%, you need to iterate. Segment the responses: what do the "Very disappointed" users have in common? What use case do they serve? What feature do they value most? Double down on the segment where you have the strongest fit rather than trying to make everyone somewhat satisfied.
Pre-PMF Metrics Framework
Use when: you need leading indicators of PMF before you have enough users for a survey.
Before you have survey-scale users, watch for:
- Organic word-of-mouth — are users telling others without being asked?
- Usage frequency — are users coming back more often than you'd expect?
- Engagement depth — are users exploring beyond the core feature?
- Willingness to pay — do users upgrade, or pay more than the minimum?
- Inbound demand — are people finding you without marketing? None of these individually prove PMF, but the combination creates a signal. If users are returning daily, telling friends, and asking to pay more — you're close.
Pivot vs. Persevere Framework Framework
Use when: results are ambiguous and you're deciding whether to change direction.
Evaluate three signals:
- Learning velocity — are you learning new things about the problem and customers with each experiment, or are you rehashing the same insights? Declining learning velocity suggests you've exhausted this direction.
- Leading indicators — are the metrics moving in the right direction, even if slowly? Flat or declining trends after multiple iterations suggest the approach isn't working.
- Customer enthusiasm — are any customers genuinely excited? Even a small group of passionate users is a stronger signal than lukewarm satisfaction from many. If you have declining learning, flat metrics, and no passionate users — it's time to pivot. If you have at least one strong signal, persevere and focus on the segment where that signal is strongest.
Practical tip
In 0-to-1, talk to customers before you build, while you build, and after you ship. The biggest mistake is building for 6 months in isolation and then "launching" to discover nobody wants it. Talk to 5 potential customers before writing a line of code. If you can't find 5 people willing to have a 30-minute conversation about the problem you're solving, the problem might not be real enough to build a product for.
Early user acquisition
Early Adopter Recruitment Technique
Use when: you need your first 10-100 users and have no marketing budget.
Early adopters aren't random users — they're people who feel the problem acutely enough to try an unfinished solution. Find them in: communities where the problem is discussed (subreddits, Slack groups, forums, Twitter/X threads), at events where practitioners gather (meetups, conferences, workshops), through personal network outreach (who do you know who has this problem?), and on platforms where early adopters self-select (Product Hunt, Hacker News, Beta List). The pitch isn't "try my product" — it's "I'm building a solution to [problem]. Would you be willing to try an early version and give feedback?" People who say yes to that are your ideal first users.
Real-world examples
Case study
Dropbox: The explainer video as MVP
Dropbox's MVP wasn't a product — it was a 3-minute screencast showing how the product would work. Drew Houston recorded a demo of file syncing (using partially staged functionality) and posted it to Hacker News. The waitlist went from 5,000 to 75,000 overnight. This validated demand without building the full product. The video tested the hardest assumption: "Will people care enough about seamless file syncing to try a new product?"
Why it works: Houston identified that his riskiest assumption wasn't technical feasibility (he knew he could build it) but demand (would people want it?). The video MVP tested demand at near-zero cost.
Case study
Zapier: Manual integrations before automation
Zapier's early days involved co-founder Wade Foster manually connecting apps for users. When someone requested a Salesforce-to-Mailchimp integration, he'd build the specific connection by hand. This concierge approach revealed which integrations had the most demand, what data mappings users expected, and what error handling was needed — all before investing in an automation platform. The most-requested manual integrations became the first automated "Zaps."
Why it works: The manual approach produced perfectly validated feature priorities. Instead of guessing which integrations to build first, they had real usage data from real customers. The concierge phase was an investment in product knowledge, not just a stopgap.
Common pitfalls
Building before validating
The #1 0-to-1 failure mode. You spend 6 months building a polished product, launch it, and discover nobody wants it. Validate demand (fake door test, landing page, customer conversations) before building. Validate the solution (concierge MVP, prototype testing) before scaling. Build only after you have evidence of both demand and solution fit.
Premature scaling
Investing in growth (marketing, hiring, infrastructure) before achieving PMF. Growth amplifies what already works. If your product doesn't retain users, more users just means more churn. Superhuman's rule: don't scale until 40%+ of users say they'd be "very disappointed" without the product.
Falling in love with the solution
You're not married to your solution — you're married to the problem. If evidence shows your solution doesn't work, the solution needs to change, not the evidence. The emotional attachment to a specific implementation is the most common reason founders persist when they should pivot.