willbryant.net

Lessons of cup noodle

Published Sat 21 February 2009 00:07 (+1300)
Tagged
    (no tags)

An O'Reilly Radar post highlights this good Ignite talk (Ignite being like pecha kucha) from Jason Grigsby which talks about the management, innovation, and research of… cup noodles.

<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/h65O54MZMp8&color1=0x3a3a3a&color2=0x999999&hl=en&feature=player_embedded&fs=1"></param><param name="allowFullScreen" value="true"></param><embed src="http://www.youtube.com/v/h65O54MZMp8&color1=0x3a3a3a&color2=0x999999&hl=en&feature=player_embedded&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344"></embed></object>

It touches on something I've got in trouble for before: some people hate it when I try and identify the constraints of the space and the problems with the approach being proposed early on, seeing it as too negative.

I don't see it that way at all – for me, identifying the problem clearly is just a prerequisite to solving the problem!

For one thing, in identifying the constraints we frequently realise that they aren't really anything to do with the way things are already done, pushing the perceived constraints back; there's requirements underlying them, proving the constraints can't be ignored – but we now know we can reinvent as far as required to solve the problem so long as we actually meet all the constraining requirements.

In analysing and rejecting a flawed approach, we more accurately identify what the actual requirements and constraints are and start generating new approaches that don't have the same flaws.

So iteratively you can see new possibilities that solve the real problem, ie. the requirements, not the problem you initially thought you had. When you know the problem, you can start working on a real solution.

For cup noodles, it started with a clear vision from management to accurately identify what they wanted created – and it was a functional requirement (make a self-contained ramen product that can be prepared in 2 minutes to sell in the American market), not an perhaps-impossible variation in the way things were being done (cook ramen the same old way but make it happen in 2 minutes, and do it without the hardware that Japanese kitchens have but American households don't).

“A self-contained ramen product that can be prepared in 2 minutes” is a statement of constraints. The team didn't say “that can't be done” or “don't block me, man”; they embraced the constraints and set to working out how to solve the problem within them.

New requirements became clear as the considered approaches and found them inadequate; the container needed to be something you could pick up and carry, without scalding you. Something needed to be done to make the noodles cook through – solved by the container design. Something needed to be done to make the toppings cook through – solved by new preparation methods.

It's a good example of how people work to fulfill actual needs and opportunities, not wishful fantasies of hardcore “ideas men” who don't like hearing the flaws in their output.