Archive for April, 2010

Thank Goodness for Smarter People

April 27th, 2010

Good news! You no longer have to wait for me to give the play-by-play of what happened at the Startup Lessons Learned conference. Sure you’ll miss my Ferris Bueller-esk commentary (okay it isn’t that funny except in my own head) but it is time to move on to other things and get busy applying those lessons learned. So without further ado here is the full list of speakers is here and links to their presentations are here and videos of all the presentations can be found here. Thank you Mr. Steve Blank-the current guru I’m learning from.

I’ll fill you in on how some customer discovery and hypothesis testing went tomorrow night. Stay tuned same bat time, same bat channel.

Startups Lessons Learned:Case Studies

April 26th, 2010
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.

Lean Startups Lessons Learned: Kent Beck

April 24th, 2010

Yesterday, I had the chance to attend via simulcast the Startup Lessons Learned Conference. It was  a great introduction and  discussion on Lean Startup methodology. It was conference in which everyone was encouraged to use Twitter to carry on conversations/comments regarding the many great speakers and case studies. The twitter stream however turned into a giant note taking mechanism (You can check-out all of the different tweets @brainhuddle using #sllconf hastag).

I’ll try using some of them while sharing what I learned. Kent Beck started our with a goat story that I believe demonstrates the success of startups and people. He was scratching a goat with the same motion on different parts of the goat’s body with pretty much the same effect. Then he got to this one spot in which the goat’s reaction was extreme enjoyment and continued to position itself so that it could keep being scratched there. Startups do this as well they look for the right spot where customers will really like what they have enough to pay them for it.

People are usually good at something in particular; they have a personal brand or unique set of skills that when applied to various circumstances produce a minmal impact but with the right timing and environment there is an extreme impact. I think that it what happens when people find and live their life’s mission. 

He then went on to highlight the evolution of software development and the Agile Manifesto adding to its 4 components:

  1. Team vision & discipline- use tools that everyone can use to harness the power of the team
  2. Validated learning-so you work on only the things that the customer’s care about
  3. Customer Discovery-Find the customer that has the problem you’re solving
  4. Initiating Change-Creating so you don’t have to compete or be reactive

He also proposed that startup engineering takes a huge project, cuts it into little pieces and rearranges the pieces to create things that test assumptions. He encouraged everyone to speak in terms of problems to be solved instead of features to be developed. 

I’ll continue to give overviews of what was talked about-mostly for my own benefit but I’ll separate it into multiple posts for your benefit. That way it is easier to swallow.

Get Adobe Flash playerPlugin by wordpress themes