Furthermore, during the innovation phase, many features get added and thrown away shortly after. It is the normal process of innovation. Not everything attempted will turn into success. The value lies more with rapid development and ability to try out the features in front of small to medium audience to tell whether the features are worth keeping.
Lean projects are characterized by rapid iteration that gives insight what features will stay and see scale. For those features, scalability should be considered. But out of the many developed features, few will see the light of day and many should probably be discarded - so to cheapen the innovation phase, I don't put much emphasis on scalability.
7) Say no to good ideas
Lean projects by definition require a lean amount of resources. And this article deals with ultra-lean projects. That means there are a limited number of features that can be built at any given time and the decision-making process really needs to be extra crisp in deciding which features or functionality to create.
A common difficulty is deciding which few features to do out of the infinite good ideas that are possible to pursue. That means saying no more often than saying yes, and a focus on rapidly bringing to market the few features that were decided on, and really trying to find the market fit for those released features.
8) No heavy Languages
I realize that no one will use C++ to create a Web startup today. But many people still set out to create Java-based products. Java is still great for enterprise, but it is way too heavy for lean projects.
Most young projects today are done with PHP, Ruby or other new languages that are faster to prototype with. A great example of a successful startup that prototyped with Ruby On Rails is Twitter, which was born out of doing something I am advocating in this article, which is iterating over product ideas. For the team of Twitter, one of those iterations turned out to become Twitter.
9) Speed over quality
This is another controversial point because in the long run quality always wins. In the beginning, the successful features are not known, so the task is to bring something to market fast and if it shows signs of life, then to focus on improving the quality of that product. And if it does not find people who may use such a product, admit it as a cheap and quick failure, learn what made it a failure, figure out how to avoid repeating the failure and quickly release something better.
Teams embracing the lean and ultra-lean projects love the word "failure" because they understand it as a big success. Every failure costs little, and offers insight that no amount of theory would have predicted. These teams quickly learn from the "failure" and a short time later surprise everyone by releasing much better products that arose from the ashes of the failure.
10) User experience over user interface
Over the past 15 years we've seen the Web grow and mature. There are even Web eras like pre-bubble, post-bubble, etc. In each era there are many examples of companies or products that looked and felt extremely simple, but provided a lot of value to people, and caught on because they did one thing really well despite looking very simple. Craigslist, Google's search, and Twitter are some of the biggest companies the Web has seen and are all very simple-looking with great usability (UX).
The reason I bring up this point is that many people find reasons why a product has to have many features and look very beautiful. But the truth is that it doesn't always have to win with that. It has to have a great core feature set that is easy and extremely intuitive to use. Yet there has to be quite a bit of innovation before such a product is created, and that is why the lean and sometimes ultra-lean style of rapid prototyping and iterative improvement wins.