Product management as a discipline has a theory problem. There are frameworks, certifications, books, and MBA modules. There are workshops on prioritisation and courses on roadmapping. And almost none of it prepares you for the actual, lived experience of deciding what to build when you have no time, no money, and no team to blame.
Solo building does.
The decision quality gap
In enterprise PM, decisions are collaborative by necessity. PRDs go through review. Roadmaps get stakeholder alignment. Features are socialised before they're built. The upside is buy-in. The downside is that bad decisions survive longer — because there are too many people attached to them to kill them cleanly.
When you're building alone, a bad decision costs you personally — your time, your money, your opportunity cost. That alignment between decision-maker and consequence is rare and valuable. It sharpens your instincts in a way no amount of collaborative PM work can replicate.
What I learned from each type of failure
Building something nobody wants (RecipeSavr, early days): Taught me that "I would use this" is not market research. It's a hypothesis. The enterprise lesson: your internal conviction about a feature is not a substitute for user data, and too many PMs present internal conviction as if it were.
Underpricing (PriceLab v1): Taught me that pricing is positioning. Free with no conversion path isn't a growth strategy — it's deferred decision-making. The enterprise lesson: "we'll figure out monetisation later" is almost always a polite way of saying "we don't understand our own value proposition."
Over-engineering (Seyal): Built a beautiful, technically sophisticated productivity app that took 14 weeks to ship when it should have taken 4. The enterprise lesson: technical elegance and user value are not the same thing, and the gap between them is where most feature budgets disappear.
The best product decision I ever made was killing a feature I'd spent three weeks building because the data said users didn't need it. Solo building teaches you to make that call without a committee. Enterprise PM needs more of that.
The transferable skills
After 14 products, here's what I now do differently in enterprise PM contexts:
I time-box discovery ruthlessly. Two weeks maximum. If you don't have enough signal in two weeks, you're not going to get it in four.
I write the success metric before I write the PRD. Not after. Before. If I can't articulate what success looks like in a measurable way, I don't understand the problem well enough to spec a solution.
I treat roadmaps as hypotheses, not commitments. A roadmap that never changes is a roadmap being driven by politics, not by learning.
I always ask: what's the cheapest version of this we could validate? Not the cheapest version to ship — the cheapest version to learn from.
The real lesson
Enterprise product management has enormous advantages: resources, user bases, existing data, cross-functional teams. But it has one significant liability: insulation from consequence. Features ship without anyone feeling the full weight of whether they actually worked.
Solo building removes the insulation. And once you've worked without it for a while, you bring a different kind of accountability into every enterprise room you walk into.
That's the thing no PM certification gives you. And the thing every PM should find a way to get.