Lessons learnt from failure

Joshua Kerievsky posted an insightful experience report yesterday. In it, he talks about an eLearning product his company (Industrial Logic) tried to introduce, which turned out to be a commercial failure. The analysis he draws from this failure is a valuable set of lessons:

• communicate product development needs and sufficient design requirements (essentially, the “good enough” criteria) early to minimize craftsmanship friction
• more content does not necessarily mean more product acceptance or commercial success
• instead, go for less content and better engagement with the audience

The key lesson there is to fail quickly. In Josh’s words, “Above all, RTPI taught me to move quickly, to fail faster and learn faster, rather than guessing and moving slowly.” It is also another argument in favor of the notion of good practices in context (as opposed to best practices) as he describes how his team changes their development style based on the context – experimenting or productizing. This resonates with me and my team. The development style and the quality bar are more relaxed when we are experimenting (spiking) vs when we are productizing. In addition, our early and frequent community  preview releases are examples of moving fast and if necessary failing fast. To take this up several notches, Flickr is doing even more frequent drops - 10+ deploys per day.

One a separate note, I believe just like software engineering researchers need to publish more empirical studies that show results with negative effects or no effects at all, we need more reports from the field like this one, that not only showcase great wins, but also share stories of failure that we all can collectively learn from.