From The Hardest Lessons for Startups to Learn · 5 notesNoteExampleDemo
The thing I probably repeat most is this recipe for a startup: get a version 1 out fast, then improve it based on users' reactions.
By "release early" I don't mean you should release something full of bugs, but that you should release something minimal1. Users hate bugs2, but they don't seem to mind a minimal version 1, if there's more coming soon.
There are several reasons it pays to get version 1 done fast. One is that this is simply the right way to write software, whether for a startup or not. I've been repeating that since 1993, and I haven't seen much since to contradict it. I've seen a lot of startups die because they were too slow to release stuff3, and none because they were too quick.
As with exercise, improvements beget improvements. If you run every day, you'll probably feel like running tomorrow. But if you skip running for a couple weeks, it will be an effort to drag yourself out. So it is with hacking: the more ideas you implement, the more ideas you'll have. You should make your system better at least in some small way every day or two4.
This is not just a good way to get development done; it is also a form of marketing. Users love a site that's constantly improving. In fact, users expect a site to improve. Imagine if you visited a site that seemed very good, and then returned two months later and not one thing had changed. Wouldn't it start to seem lame?
They'll like you even better when you improve in response to their comments5, because customers are used to companies ignoring them. If you're the rare exception-- a company that actually listens-- you'll generate fanatical loyalty. You won't need to advertise, because your users will do it for you.
2Note
One flow that works beats ten that half work.
3Demo
Ship to a preview URL first. Cheap to share, cheap to throw away.
Preview first, prod on request →4Note
Small fixes count. A better empty state, a faster button.
5Note
When you ship someone's fix, tell them.