Launching faster changed how I think about ideas
I used to sit on ideas, waiting until they felt “ready.” Weeks would go by, and excitement would fade before anything went live.
Then I built ShipAhead. Not to make things perfect, but to get a working version online while the idea still mattered. Once I could launch quickly, the feedback cycle changed everything.
I started shipping more, testing assumptions faster, and actually learning what worked instead of guessing. Most projects still fail, but now failure happens with data, not doubt.
If you feel stuck in endless prep, moving faster might be the simplest thing that actually works.
I just came from that mental change. Before I spent months polishing a merch ecommerce and I learned very little.
Now I'm doing the opposite: small experiments, simple wizards, something quick to use and talk to real people.
The most difficult thing is not to launch quickly, it is not to return to builder mode after the launch.
How do you decide when to keep pushing an idea and when to stop without deceiving yourself?
"Failure happens with data, not doubt" - that's a great line.
I'm experiencing this now. Built MeetDone in about a week, launched 4 days ago. Zero paying customers yet, but I'm learning way more from real feedback than I would have from another month of polishing.
The hard part isn't shipping fast - it's staying in distribution mode after launch instead of retreating back to "just one more feature."
What's your threshold for deciding when to keep pushing vs. move on to the next idea?
As a product manager, I used to believe in making a product as perfect as possible before launching. But after release, when no one used it — or only very few people did — it was extremely discouraging.
Over time, I realized that launching fast, iterating quickly, and collecting feedback early matters far more. An imperfect product will gradually become better. Users will give feedback, grow with the product, and shape it along the way.
As long as the core demand is right, having bugs is not necessarily a bad thing. In fact, bugs often create better opportunities to talk with users and truly understand whether the product is solving real pain points and meeting real needs.
Solid breakdown. One thing I wish I'd thought about earlier was how fragile third-party data sources can be once you depend on them. Shipping fast is critical, but having a plan for when your data pipeline breaks saves you from scrambling later.