What 0→1 Actually Means After You've Done It

The phrase '0→1' shows up in every PM job description in 2025. Everyone wants to hire someone who's done it. Everyone calls their own work 0→1. The phrase has lost most of its meaning.

Underneath the noise, 0→1 has a specific shape. It's three distinct phases. Each phase requires different skills. PMs who think the whole thing is one undifferentiated 'building something new' job tend to over-rotate on one phase and starve the others. The output is usually a polished prototype that nobody uses.

Before you build, you validate. Three things specifically.

**Problem validation.** Is the user pain you're solving real? You learn this through conversations, not through prototypes. Five to twelve interviews in your target segment, all centered on the problem space, before any solution is sketched.

**Audience validation.** Who specifically experiences this pain enough to pay for a solution? Not 'developers' or 'small businesses.' A specific, addressable cohort with predictable behavior.

**Willingness validation.** Will they actually switch from their current solution (which is often spreadsheets or doing nothing) to your new thing? Conversations are weak signal here. Letters of intent, pre-orders, or paid pilots are strong signals.

Most 'failed' 0→1 efforts skipped phase A and went straight to building. The build was good. The market didn't exist. Phase A would have caught this in three weeks instead of finding out after eight months of engineering.

Now you build. But not the full thing. The smallest version that lets a real user complete the core flow end-to-end.

This phase has its own pitfalls. Two common ones.

**The MVP that's secretly a v1.** Teams over-spec the MVP. Onboarding, settings, multi-user, integrations. None of it is required to test whether the core flow works. The over-specced MVP delays the test by months.

**The MVP that's secretly a prototype.** Teams under-spec to the point where the MVP can't actually run for a real user. Demo-ware. Looks great in screenshots. Falls apart on actual usage.

The MVP definition: a real user, doing the real task, on the real system, end-to-end. Nothing more. Nothing less. Everything else waits.

MVP scope is brutal. If it doesn't hurt to cut, you haven't cut enough.

MVP ships. Now the real work starts. This is where most 0→1 efforts actually die.

The MVP gets feedback. Some of it is signal; most is noise. The team has to distinguish 'real users find this confusing' from 'one loud user wants a feature they don't actually need.' This requires interviewing the users who churned, not just the ones who stayed.

The team has to decide: does the MVP need iteration on the existing core, or does the core need to change entirely? Both are 'iteration' but mean radically different things. Iteration on the core means polish, fix, add the next missing feature. Changing the core means going back to phase A — you misread the problem, you need new validation.

Most teams refuse to change the core when the data says they should. They keep iterating on a wrong core because the cost of admitting the core was wrong is too high. This is how 0→1 efforts fail despite shipping.

0→1 is done when three things are true.

One: real users use the product for real work, repeatedly, without the founder hand-holding them.

Two: the team has a credible, evidence-based hypothesis about which next 2-3 features will move retention or growth.

Three: at least one channel — sales, organic, paid, referral — is producing leads at a cost the unit economics can support, or there's a clear path to such a channel.

Fewer than one in five 0→1 efforts hit all three of these. The ones that don't aren't '0→1' anymore. They're early-stage struggle. The phrase is being used to describe the work, not to claim a milestone.