4 ms·
Reading this blog post, I see two skills in conflict: 1. Ship now, ship often 2. Strive for perfection The first one is required for entrepreneurs. Your "wor
by csytan 8y ago
Reading this blog post, I see two skills in conflict:
1. Ship now, ship often
2. Strive for perfection
The first one is required for entrepreneurs. Your "work <--> reward" iteration cycle should be as short as possible, and should end with the customer handing you money.
The second one is a skill that rewards knowledge acquisition, and can be especially helpful for those looking to improve their skillset in order to move up the career ladder. It's also an iteration cycle, but the reward often doesn't end with directly delivering value to a customer.
Lastly, I think that startup media (Tech Crunch, YC, etc) has a lot to do with this. There are way fewer stories told about bootstrapping something long term, compared to stories about successful startups hitting home runs. The reality is that the bulk of the work will be after you launch, and will likely require continuing effort in the form of years rather than months.
- strig 8y agoMaybe it could be rewritten as: 1. Ship now 2. Ship often, and strive for (eventual) perfection
- enraged_camel 8y agoIME, the core of your product, the part that your customers use regularly, should work perfectly. It’s okay for the other stuff to not be perfect.
- Swizec 8y agoOn the other hand: if nobody is buying your product, it doesn't matter how perfectly it works.
- enraged_camel 8y agoThere is some truth to that, but most people want to try out a product before they buy it. So if they run into bugs during that trial period, then your conversion rate will suffer.
- opportune 8y agoHonestly I think ship now ship often deserves an asterisk by it. When you’re designing large and intricate back ends for a system that needs it, and you’re a PM who only sees things in terms of end-user features, it’s easy to set yourself up for failure trying to ship so fast that you accumulate technical debt faster than you can ever pay it down (because you underengineer the underlying platform but need to support it forever to meet SLA, and good luck arguing for a complete rewrite) That is, no mantra above a certain level of abstraction should be adhered to too strictly. Sometimes it’s better to ship 3 months later if it means 3 years of way simpler support and scaling