Startups Lessons Learned:Case Studies

April 26th, 2010 by hoha Leave a reply »
There were 3 successive case studies presented at the Startup Lessons Learned Conference last Friday. The first was Ash Maurya of WiredReach regarding Continuous Deployment. He started off with a reference back to lean principles. Waste is any activity that doesn’t add value for the customer or in this case customer learning. He then made a rather counter-intuitive statement: “Product development gets in the way of customer learning.” he then transitioned by explaining that continuous deployment shortens the development cycle reducing the waste and allowing the customer to do what they care about.

He described what that looks like. They release several times a day instead of every 2 weeks and it is usually 25 lines of code instead of in the thousands. They took some time on the front end to set up some test automation and then spend their time fixing everything else once it is launched so they’re working only on the things that matter to the customer. They transitioned into this methodology by starting with non-user changes first.

He encouraged people that were going to embark on this type of process to identify the top 3 customer problems that you want to solve, use the 5 whys to analyze the root cause or customer need, and validate each feature by collecting qualitative data directly with the customer by calling or emailing them. Any additional feature rquests should be a pull from more than 1 customer.

The next case study was presented by Farb Nivi of Grockit fame. (He named it after a term in Heinlein’s Stranger in a Strange Land. Grok means “to understand profoundly and intuitively.”) He has used agile software development to build his social media site for students that need help studying. His two main tools/methods he used was Pivotal Tracker as a narrative not a to do list. Software devlopment is a human endeavor and paired coders (1 coding the other checking). He also cautioned that while agile software development is an engine to move your business faster but you still need to steer according to your customers need.

The 3rd case study was presented by a team from IMVU trying to answer the question whether the lean approach can scale. They found initial success by allowing anyone to make changes or add features whenever they wanted as long as they were focusing on meeting customers request. However as they scaled or grew it created technical debt. Meaning a lot of features took up resources and had to be maintained but didn’t necessarily increase revenues or ensure ownership (leftover projects). They then described what they did to try to eliminate that debt through team organization focused on different things and finally settled on 3 teams-product, monetization, and keeping things running. The owner of a product/feature decide where the resources will be used but the team decided how.

Even though they were able to show an increase in revenuesthe whole process sounded like a lot of meetings. Their lessons learned was that when you get large enough you need to look for big returns instead of changing every request. And that it required a cultural shift from independent changes to accountability (ship it or kill it for the best of the company). Still a work in progress but I was impressed with their culture/assumption that their people are doing their best. It allows them to continue to be agile and being okay with short-term failure in the name of learning. That can be tough to do.


Leave a Reply

Get Adobe Flash playerPlugin by wordpress themes