Companies tend to follow either:
- Apple-style 'big launches' where polished things are released infrequently
- Lean-method releasing features often and getting feedback early

As designers, our tendency is to polish things up as much as possible before releasing, so we are attracted to 'Big Launches'

But 'Releasing Often' definitely gets you better feedback and in the end results in better design (IMHO) within the same timespan.

Is it possible to do both? Is one better than the other?

I've always been tending toward 'Release Often' ideologically, but a lot of times I get distracted and the projects balloon because of domino effects on the rest of the product that'll require updating.

Also realizing this will differ on web vs mobile/desktop app (where your release cycles are throttled by Apple)

Releasing often doesn't — necessarily — mean you're releasing to (all of) your customers often. There's something to be said for anticipation and being Lean doesn't have to compromise that. 1-2 week sprints; sign off; user testing; iterate. Then ship to your customer pool every 4 weeks or every 8 weeks. If that's your thing.

Lean and Agile are absolutely invaluable parts of the design process now though; 'releasing early, releasing often' to me means getting away from the old model of Lead Designer going away to her cave for 6 months and coming back with something that's wildly diverged from what it should be.

Here is how I like to think of it. Anything that is going out needs to meet a basic set of user experience and polish. The core experience should be there. In that sense I hate the term minimum viable product, because all it looks for is the viability of the product's existence as a "thing", I like to look at it more as the Minimum Lovable Product.

I am NOT at all a fan of the release early release often mentality. Often this means releasing half baked product. For almost all products that I have worked on, they are a part of a complex interconnected system. The other thing about the "let's just get this out of door" approach all the time is that shit piles up and starts to show in overall experience.

tuhin.co

Also it is easy to see that in the light of the ideal illusionary image of a designer who likes to working on things all by themselves for a really long time. I am not like that. I like to build products and get them out. But I am never comfortable or even ok with them going out unpolished. If you cannot manage polish within the deadline, reduce the number of features, but never the quality of what you are building.

Needless to say this is a continuum rather than a black and white argument.

Adding further a tangential point since testing and iteration was mentioned, this user testing approach often falls flat on its face when it is social behavior that is being tested. Everything from how you manage the idea of a "person's identity" in profile to what the privacy settings are affects social. Often I have seen totally valid ideas being marked as a failed one because testing it in a random group of 50 deemed it useless. So if you are testing social features, test how people would use it if it were live to everyone. They would find a dense network of social connection, fake that by launching it to friends and family so that the feature makes sense to them.
Of course tweak as per your product's needs.

> If you cannot manage polish within the deadline, reduce the number of features, but never the quality of what you are building.

It's very common for engineering to cut features because of time constraints, but for some reason I've never seen design teams go "we can't do this well, so we shouldn't do it at all". An unpolished design is akin to hacky engineering, but startups seem more comfortable with the former than the latter, I wonder why.

Releasing often. With a few caveats.

In general I'm a fan of getting things out quickly, and iterative design makes a ton of sense to me. What I don't find a lot of value in is putting just any old thing in front of your users/customers. This is my biggest issue with the way people talk about Lean methodologies today. You might have a great idea that simply needs more time and polish - don't taint your vision simply to release early. Do those internal rounds (ideally with something "real") and get it to a state where it'll make sense when put in front of your customers.

Taking the time to get something right is important. IMHO, more important than meeting deadlines. Having said that, validation is key, so don't wait too long.

I like this thought of Releasing Often internally. Does anyone have insight into how this works at companies like Apple? I'm sure they have rigorous internal testing/prototyping.

I've known quite a few people who've worked at Apple, and, yes, they go through a TON of internal testing/prototyping. I think many companies also do a lot on non-public (NDA-style) user testing.

For some products, frequent releases with lots of experimentation will alienate your user base. What if you had to update your copy of iTunes—or worse yet, your OS—every four weeks? It's disruptive to you as a user, since apps and OS software can't (currently) be updated without user intervention, and unexpected changes in UI that you use daily can be very frustrating.

Internal testing helps tremendously, but if it's just typical QA looking for defects it's not necessarily going to reveal larger strategic errors, and those are the errors that will really bite you later.

Another problem: larger companies are often still wedded to waterfall software process, though if said that to their faces they'd deny it. Most of the teams (but not all) at Apple suffer from this.
Rather surprisingly, they also don't have many effective tools for measuring the success of design change at a granular level.

But that's for native apps and OS. Web sites and apps—and native apps that use served web views for aspects of their UI—are different. I was just going through this excellent slideshare deck when this branch popped up: slideshare.net

I love this approach. Break down your hypothesis into smaller, verifiable chunks, then test them, individually. With metrics.

This is the magic of the web, but also a curse.

Finding a typo or little CSS bug after deploying to production takes seconds to fix. If you realised you'd made a typo in the new version of iTunes you'll (probably) not deploy an update straight away.

This does mean that in small web-based startups we're less stringent with QA than if we were *distributing binaries*, however that may be (App Store, boxed software, enterprise installations etc).

@jon: Absolutely right. It's a combination of medium and audience. If your medium and your audience can handle it, more incremental releases is a great approach.

Put another way: sure, on the web you can make changes all the time if you like. But if your web app is deployed to an enterprise audience that fears change, even if you can make lots of little changes over time, you need to find a way to roll them out while keeping your users comfortable.