Lean Startup Machine Weekend - Mark's Turn

Here are some notes and thoughts from Mark Warren on our experience at the Lean Startup Machine Weekend in Boston:

This would be a good experience for people to try. I went as observer to LSM in California earlier in the year and thought this type of venue would be good for Bryan and I to try out our ideas on. Incidentally, other Lean Startup platforms, such as The Hoffman Foundation, are slightly different than LSM, but both Lean Startup formats push you to test your assumptions and pivot. As a an observer, I watched a lot of eager young people try the process: pitch your idea and watch it get shredded! Now we got to try our hand at it!

Most people will see the connection to the JM program…the biggest difference is pushing you to define your guesses in the early stages. The Startup team members encourage you to define your riskiest assumption and (in)validate it.  We found that our riskiest assumption was not necessarily easy to prove. Tom Eisenmann, one of the speakers at the weekend event proposed an improvement: rather than go after the riskiest assumption that must be true for your idea to work, you can rank them by weakest assumption and simplest to test. Often the best approach is to test the simplest assumptions first and save yourself time if it is disproved. 

The other biggest difference between the Startup method and what most people do for a JM or Kaizen project is the weekend project takes a more scientific process of testing one piece at a time, the trap of the Kaizen approach is to change the whole process…you don’t know which change was good or bad, just the sum of the outcomes. This aligns very well with the Teian style of improvement where big problems are broken down in to very small problems and tackled one need at a time.

The next piece was the experience bias…this can be linked to both JI and JR…we think we know so our investigation is skewed by our experience. We really had difficulty in stepping back far enough to get into discovery mode. On the JR side, developing the question sets to "get the facts" was more difficult than we realized, as in the first rounds we created leading questions to validate our assumptions. In the JR ‘getting the facts’, this may be exceptionally difficult if the person doing the fact finding has any involvement with the people in question…personal bias is often hidden.

Overall, the experience was good in the sense that we learned some approaches to prove or disprove our ideas and how to step away from our ideas and not see what we want to believe. It seems there are still some approaches to consider for the format to work really well, but it also has some strong features that make you step out of your comfort zone as well - which is a key point to learning.

Lean Startup Machine Weekend Wrap-Up

First, our project update: the first leg of our excellent adventure ends today. We validated a few core assumptions - thanks to those of you who volunteered to play with our questions and get on the phone with us for follow up questions. It's hard to say at this point where we are going, we have a few more dozen experiments to run. The general theme and direction is geared around a core lean principle: flow. I'm curious what you think about the following questions?

• What interrupts the skill development of your people?

• What do you need to speed up how you develop their skills?

• Do you see the use of mobile technologies playing a core part in that development pathway?

---------------

Second, a brief review of Lean Startup Machine Weekend. Mark sketched out a Job Breakdown Sheet which we will share as an update later in the week. The event is very similar to a kaizen event: activities are biased for action. The primary objective is to save yourself some grief and heartache by breaking up with your ideas before you fall in love with them. I can see this methodology being used with product development teams or voice of customer exercises.

One unique trait of LSM is that once an experiment is created -you "get out of the building" immediately - we know this as go and see. The big difference is that kaizen events test multiple experiments simultaneously - "let's move 12 machines around" instead of moving 1. One could argue that LSM has a better experimental approach than those used in kaizen blitzes...improvement batch reduction has benefits: easier to get done, easier to evaluate effects, easier to adjust if changes are needed. This also happens to be more aligned with small kaizen and Job Methods approach. I found this to be a very solid feature of the approach that throws people right into discovery mode.

My big concern about LSM is the Lean brand associated with it. Those of us that have been around a while have seen this before. In this case the young people are extremely enthusiastic about Lean, as they understand it today. Unfortunately, that understanding is only of the outcomes of Lean, faster, cheaper, better. They only see and are taught, the tip of the iceberg. What lies beneath the surface is what supports the things they are seeing above.

The big benefit here is that this approach can help you reduce risk: shorter development cycles, less cycle cost, real feedback, kill your ideas early.

Well, not so fast. LSM is pretty cool, and I found it to be a fun exercise. But it is a couple of pieces of a bigger puzzle. The shortcomings? As results begin to breakdown later, because basic structures and habits do not exist...these young followers may become disillusioned with "Lean"...and LSM is just another fad thrown onto the scrap heap. This has happened to a bunch of other disciplines preceded with the "Lean" moniker - and it is one I caution the LSM team to watch out for. I'm skeptical that "Lean Startup" will survive, as this has a faddish, Rock Star, feel to it. The next year will be interesting to watch where this "movement", as one starry eyed follower puts it, takes hold.

And you thought Taichii Ohno was tough!

An excerpt from Diffusion of Innovations, 5th ed. by Everett Rogers, here is an interesting story behind Toshiba’s first laptop!

Convincing the corporate leaders at Toshiba that Mizoguchi’s vision for a laptop computer made sense turned out to be extremely difficult. The company had just failed in the marketplace with its personal computer, taking huge losses, and corporate leaders had decided to get out of the computer business. They denied Mizoguchi’s request for development funds and refused to assign him any experienced engineers for a laptop R&D team. Not discouraged, Mizoguchi went “underground” with the laptop project at the company’s Ome factory, located some twenty-five miles from Toshiba’s Tokyo headquarters. He diverted funds and shifted ten engineers from military projects to design the laptop. A prototype was created in twenty-four months, but the process was very stressful to those involved. For example, one Friday afternoon, the exhausted engineers were unable to find space to pack one more device into the already jam-packed prototype (Albetti, 1997). Mizoguchi ripped the cover off of the laptop and poured a glass of water inside (thus ruining all the electrical circuits). He turned the laptop upside down, and a few drops of water came out. Turning to his stunned engineers, Mizoguchi exclaimed, “See, there is some space left! Work smarter!”

On the one hand, you have to admire Mizoguchi's secret skunkworks approach to getting the first laptop computer developed. This takes a lot of bravery and vision to see this level of innovation through. However, not a lot of respect for people, property or his team’s effort and he was rewarded later in his career despite this destructive behavior towards other individuals. Any thoughts on how Mizoguchi could have devised a better coaching method - even if your method isn't as entertaining?