Marco Arment remarked on this post from Matt Buchanan complaining on the futility of updates that:

Nothing has changed: the products that were great on day one are still great, and the ones that weren’t still aren’t.

The consistent message I hear about how to do product development right is that the lesson that Apple learnt, and tries to impart upon it’s developers, is fix one problem, and fix it completely. Future updates are to solve future problems, not to fix the thing you tried to fix before.

If you can’t solve the problem with a software update, you solve it with a hardware update. But when you fix the problem that your customers are having (whatever problem it may be - they may not even know they have the problem yet), fix it totally. Don’t release something that’s half-baked.

Marco sums it up well in his previous post that he calls out again:

In brief, their philosophy seems to be to ship only what’s great and leave out the rest. That’s why, instead of having a bad copy-and-paste implementation for the iPhone’s first two years, we just didn’t have one at all.

There is a danger for product teams who have successfully adopted continuous delivery, or maybe are trying out Eric Ries’ Lean Startup ideas, to release something that doesn’t work the first time because it’s technically easy to. ‘It’s okay, we can solve it later’ is a good way to under-deliver to your customers. Trial your idea extensively first, work out the kinks, then ship the thing that works.