Ship ugly first
The fastest way to learn what you should build is to put something rough in front of a real person.
Every product I’ve been proud of started out embarrassing. A rough build, held together with defaults and duct tape, put in front of someone before I felt ready. I used to read that embarrassment as a sign I’d moved too early. Now I think it’s the whole point.
Rough beats theoretical
You can argue about a feature for a week, or you can build the ugly version and watch someone use it for ten minutes. The ten minutes wins every time. People don’t react to your plan. They react to the thing in their hands, and what they do with it is almost never what the plan predicted.
Shipping early isn’t about lowering the bar. It’s about moving the argument out of your head and into the world, where it can actually get settled.
Speed protects the idea
A good idea has a short shelf life. Sit on it long enough and you’ll talk yourself out of the risky part, which is usually the part that made it good in the first place. Momentum is fragile. The longer something lives in a doc, the more caveats and second opinions it collects, until the version that finally ships is the safe, boring cousin of the thing you were excited about.
Building fast is how you get the real idea out before it gets sanded down to nothing.
Polish the things people touch
Shipping ugly doesn’t mean shipping careless. It means being honest about where polish pays off. The parts a person actually feels, the first ten seconds, the moment something works, the copy on the one button they’ll press, those earn real attention. The rest can stay rough until use tells you it matters.
Do this a few times and a pattern shows up. The features you were certain you needed rarely survive contact with a real user, and the ones that end up mattering were hiding somewhere you’d never have found from the plan.