Building a Better Mousetrap at AME

Durward Sobek, Michael Kennedy and I conducted a workshop on lean product development at last week's Association for Manufacturing Excellence conference.

The workshop uses the Mousetrap® game as a product development challenge: can you build a better mousetrap? Here is the "before" picture (Mousetrap 1.0):



The purpose of this workshop is to help people gain more comfort using rapid learning cycles as part of the product development process. The teams develop Mousetrap 2.0, 3.0 and 4.0 in iterative development cycles, use LAMDA to investigate their ideas and A3 reports to document their findings.

The groups are all part of one development team competing for a customer order against a competitor who has set a high bar for performance.





This time, all four teams could only catch 7 mice in five minutes, using three people with the original set up. The "winning" solution, which included ideas from all four teams, caught 23 mice in 5 minutes with only one person, a 10X improvement in mice caught per minute per person.

By sharing the best ideas among the entire group, we end up with at least one solution that will work among the four teams, demonstrating the value of set-based design when the team has a high degree of technical risk and a lot riding on the outcome.

The group used rapid prototyping tools (scissors, masking tape, construction paper) to quickly design and test their ideas in ten minute development cycles, followed by five minute trials.

Special thanks goes to Jamie Flinchbaugh and the Lean Learning Center who originally developed this simulation, and helped me adapt it to product development.

Lunch with Ken Kreafle of Toyota

I had lunch today with Ken Kreafle, General Manager of Vehicle Production Engineering for Toyota North America, while I was in Northern Kentucky this week. It was a great way to cap off the Association for Manufacturing Excellence’s annual conference.

He defined lean as, among other things, “workers improving their work within their teams.” In other words, lean is not something that someone can do from the outside. Those of us who support lean from the outside can only support the people on the inside as they improve the process.

He strives to remind people that it took sixty years for Toyota to get to the place where it is today (and it’s not perfect by any means). All the “stuff” - 4/5/6S, kanbans, work cells, etc, etc emerged from a process and a culture of relentlessly attacking problems so that they get solved permanently. We can improve our operations and product development by modeling our practices after the tools, but that’s only the tip of the iceberg.

It’s much easier to emulate specific tools and practices than it is to truly empower workers to improve their own work - to give them the tools, set the expectations, manage and reward them so that they come in every day willing and able to solve problems so that the problems don’t come back.

We have it a little easier in product development - after all, we come in to work every day prepared to solve customer problems, and figure out how to meet customer needs more effectively with the next products than we do with our current products.

Still, how many of us have problems that crop up over and over again - always at a time when we don’t have time to do anything more than place another bandaid over them? How many of us stumble at the same places in development over and over because there’s never any time to fix the problems permanently? How many of us spend a lot of energy innovating in areas like checkpoint meetings that add nothing to customer value, sucking time and energy away from the things that drive revenue growth and profitability?

What would we be capable of doing if we rigorously attacked those problems so that we could move on to better problems?