I recently read the book: “Super-Flexibility for the Knowledge Enterprises” by Homa Bahrami and Stuart Evans. It discusses the concept of a knowledge enterprise being super-flexible to harness the inevitable uncertainty. This is highly applicable to start-ups that have to go through uncertain periods as well as to any organization being affected by the current economic environment.

The book is not an easy read, and it does not provide prescriptive actions similar to 10 steps to building your start-up. However, it has a lot of insights that you would be able to apply, if you read carefully with your organization in mind.

Follow me on Twitter

I am getting closer to the end of the book: “Dreaming in Code”. Chapter 11 is titled “The Road to Dogfood”. Eat you own dogfood is a concept that recommends using your own products. Chandler team had taken more than three years before they had a product that could be shipped or at least could be used internally. In my view, they were too ambitious in trying to ship a great product in the first attempt.

This reminds me of the commencement speech made by Guy Kawasaki at the Carnegie Mellon Silicon Valley graduation last summer. One of his advice was “Don’t worry be Crappy”. The following is taken from his blog:

An innovator doesn’t worry about shipping an innovative product with elements of crappiness if it’s truly innovative. The first permutation of a innovation is seldom perfect–Macintosh, for example, didn’t have software (thanks to me), a hard disk (it wouldn’t matter with no software anyway), slots, and color. If a company waits–for example, the engineers convince management to add more features–until everything is perfect, it will never ship, and the market will pass it by. - Guy Kawasaki.

On hindsight, a similar vision coupled with an agile development methodology would have helped Chandler. An agile methodology like Scrum or Exreme Programming would have made the team focus on releasing the most essential features of the product early without waiting for all the functionalities to be in the product. This would have been ideal for Chandler as its vision was only defined at a very high level. Early releases of a usable system with less features would have expedited the process of fixing bugs as well as enabled the feature definitions to take shape with more early feedback from the user community.