Netflix.com

Executive Summary:
Netflix.com is one of the most successful web sites in the world: the sole customer interaction point of their home DVD-rental business. Over the past 9 years, the site has grown from nothing to serving almost 6 million customers who use the site to prune their rental queues, rate movies, and handle any billing and transaction issues. Netflix isn’t the only company using a fast iterative design approach. Google has also gained attention for their unorthodox design methods; with many people complaining that they have a huge stable of products, but only a few they’ve designed well. Netflix.com updates their site in every two weeks and they realize that the most of the changes will work but most won’t. This applies equally well to web-application development. Fast iterations provide the freedom to innovate because teams can test more features. This reduces the risk of each tested feature. However, it takes getting used to and not everyone adjusts so easily. As with most design processes, teams get the most benefit from quick iterations when they fully embrace the process.

Key Takeaways:

  • Fail Fast – A major benefit of fast iteration is you also fail fast. Failing fast means you invest less time in the things that don’t work.
  • More Experimentation – The faster you fail the more experimentation you can do. You can try out ideas that might not have a lot of support, but could be potential winners. This allows for an innovative environment.
  • Learn Quickly – Fast iteration helps solve this problem by giving developers a platform on which they can test quickly, helping to collect data about any outstanding questions instead of resorting to opinionated arguments.
  • Provide Continuing Interest – The best teams not only design the changes, but design the process for introducing the change. They experiment with methods to overcome the users’ natural resistance to change, providing migration paths and clear benefits for each improvement.
  • Reduced Risk – Quickly iterating helps reduce risk during design. If teams can make many small changes instead of a few larger ones, they mitigate risk because they know which changes have what effect.

Full Case Study:  http://bit.ly/1jIRPTk

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Prove you are human *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>