I saw wisdom in this approach immediately, but I had to think for a while about what this process means for games.

  There are some obvious things that leap to mind, like paper prototyping and playtesting early.  These practices are so common they're almost cliché.  On the other hand, there are often essential elements of games that are impossible to paper-prototype and difficult to test.  After all, this is an art form.  Beethoven didn't go around saying "Da da da dum!  What do you think so far?"  A good game is a symphony of harmonious elements, and missing pieces can be palpable.

  There is a style of game design, however, which seems particularly susceptible to the lean thought process.  It's one of the many approaches to game design in Jesse Schell's book "The Art of Game Design"(http://amzn.to/yKjmwF). To attack the problem of designing a game, you come at it sideways, by first making a toy. 

A lot of great games are wrapped around a toy core.  'Angry Birds' (http://bit.ly/yNOrkG) is built around Box2D, which is sort of a digital set of blocks.  Dodgeball (http://bit.ly/xJyudR) is built around bouncy balls with good grippy texture.  'World of Goo' (http://bit.ly/yCNAzP) has a rubbery bridge-building set at its center.

Toys create a fun experience even without the rules that make up a game.  Toys are already fairly minimal, in a way.  Once you've designed a toy and identified what's fun about it, you're halfway to a game design.

  You can see how one might iterate pretty quickly on a toy (Lean principle #3) and, without knowing it, we sort of took that approach to 'Squishy's Revenge' (http://squishysrevenge.com/).  The first toy we designed was a 2D world where rows and columns can be rotated independently.  It wasn't that much fun, so tried again.  This time we made a sliding-tile world for Squishy to live on.  This had the virtue of familiarity (it works a lot like the stocking-stuffer 15-puzzles we've all tried), and novelty (there's a creature who lives on this puzzle!).

So you have a fun toy.  Now you just have to add rules.  Rules can pile up quickly, so verifying them one at a time, or even in small groups, is a difficult thing to do.  I'm honestly not sure what the best way is.   

What is simplest set of testable rules you can make without sacrificing the emergent properties of the game? If you can situate the toy directly between the user and their goal, and add whatever rules are necessary to make them go through the fun parts of the toy, rather than around it, then that seems like the minimal testable set of rules.  Perhaps there's a way to test an even smaller set.  If there is, I don't know it.

The fun part of having a set of blocks is knocking them over, so 'Angry Birds' makes this the goal.  You start with a fully built structure and you must knock it down.  To make sure you fully experience the fun of blocks falling down, a rule is added to prevent you from toppling them directly -- you have to throw birds at them.

As for Lean principle #4 (shorten your iterations), small teams are doing it without thinking about it.  Agile game development (http://amzn.to/x5h4ij) and the rise of weekend-long game jams like Ludum Dare (http://ludumdare.com/) are proof of that.  Long periods between playable versions make game developers nervous.  We need to play our games often, and have others play them, so we know they're still fun every step along the way.

The "Toy" approach to game design is only one of dozens.  Maybe others are even more amenable to the Lean treatment.  I'd love to hear more from you.  Are there any other Lean game designers out there?