The hardest phase of product isn't scaling. It's not growth, not internationalization, not the painful migration off a legacy architecture. The hardest phase is the one before you have real signal — when you're building for users who don't exist yet, making bets with data you don't have, and trying to hold conviction without confusing it with delusion.
I've been a founding PM three times. Here's what I've learned.
The Temptation of Premature Certainty
The first mistake most founding PMs make is trying to resolve uncertainty too early. You run a few interviews, synthesize some themes, and declare that you've "found the insight." Then you build for the insight. Then you discover the insight was a layer of the onion, not the onion.
Early stage product work is not about finding the answer. It's about systematically eliminating wrong answers while keeping your options open long enough to find the right questions.
Build for Learning, Not for Shipping
When there are no users, every feature is a hypothesis. The question isn't "how do we build this?" — it's "what's the cheapest way to find out if this is worth building?"
This sounds obvious. It almost never gets practiced. Teams default to building because building feels productive. Discovery work feels like delay. But a month of discovery that kills a bad bet is worth more than six months of engineering a feature nobody wants.
At pre-product-market fit, the job title is "PM." The job is "researcher."
Conviction Without Confirmation
The uncomfortable reality of 0-to-1 work is that you will have to commit before you're certain. There's no PMF signal to anchor to. There's no retention curve to read. There's just your judgment, your team's judgment, and a set of assumptions you're betting the roadmap on.
This is where the best founding PMs distinguish themselves — not by having better data, but by being better at knowing which assumptions are load-bearing. Identify the two or three things that have to be true for your product to work. Test those relentlessly. Leave everything else for later.
What "Later" Means
Later means: after you have users who are genuinely, demonstrably better off because of your product. Not users who signed up. Not users who said nice things in interviews. Users who would be genuinely disappointed if the product disappeared tomorrow.
That's the signal you're building toward. Everything before it is preparation.