Nov 03 Business and Beyond: Toyota, Drums, and Customer Experience (a Product Development Lifecycle Whitepaper)

Original post: June 3, 2011 | GoogleScholar | Academia.edu

Simple products break less

Here and there in my career, I have worked with software people. Whenever my modest inputs are required to help software developers build better digital products, I like to say this, among other things: “Let’s make this feature work like a drum!” This expression is not my own – I “inherited” it from a good friend who is a front-end developer, but it represents a principle in product design that I follow (more on that later). And believe it or not, it all started with cars and drums and LSD… as in Lean Software Development. Since we happen to be humans (even the geekiest of us), sometimes it helps to remember why simplicity is the mother of genius – because simple things break less. This notion is at the core of great products and customer experiences.

A Little history: Hardware vs. Software

I have never owned a Toyota and have little use for drums or street drugs. But I do take interest in precision engineering and love to study complex devices, including telescopes, watches, and other mechanisms. I also have been exposed to design, hardware, and numerous construction projects. Many will argue that physical objects and devices are more difficult and expensive to develop, and so it may be unfair to compare those to software in terms of approaches to measuring usability and customer satisfaction. But I say (and I may prove to you, if you don’t agree) that software and hardware are identical from the product development, usability, and customer experience perspectives. This is because

• both are designed for humans;
• both are designed to serve a specific need or to solve a specific problem;
• both can be expensive to develop and expensive to market;
• both can break;
• both are less likely to break when they have fewer moving parts.

From Toyota to LSD, to Agile

Did you know that the hip word “lean” goes all the way back to Korea over 60 years ago? To be exact, in 1947, Chung Ju-Yung founded Hyundai Group Companies and then dedicated the next 50 years of his life to turning Hyundai into a global conglomerate with over 150 thousand employees. Ju-Yung, whom I once had the pleasure of meeting in Seoul (ask me how!), survived and prospered not because he had a rich grandfather but because Hyundai was the first to use the so-called “lean manufacturing practices,” which helped the company develop amazing economies of scope and scale, starting with the manufacturing construction (its core industrial business) and about 40 years later leading to cool things like my Hyundai Genesis Coupe or your Hyundai widescreen display.

More specifically, lean manufacturing practices have their origins in the so-called Just-in-Time (or JIT) inventory control system – a production strategy that strives to improve a returns on investment by reducing in-process inventories and the associated carrying costs. By mid 1950′s, Toyota went on to “adopt” the JIT system, when Taiichi Ohno, and Eiji Toyoda developed what was then called the Toyota Production System, or TPS. In turn, because Toyota officially adopted and publicized the approach, it is also historically credited for the lean practices in manufacturing, albeit incorrectly.

A few decades later, in 2001, Kent Beck studied TPS inside-out and wrote what is known as the awesome Agile Manifesto, which Mary and Tom Poppendieck dutifully and wonderfully transposed into what most people in the world of manufacturing (and software) know today as Lean Software Development – a concept that was popularized by the book with the same title, which the Poppendiecks published in 2003.

More about Lean

The textbook – and the Wikipedia – definition of Lean Software Development is this: LSD is a translation of lean manufacturing and lean IT principles and practices to the software development domain. Again, the translation started with the original (be it the chicken or the egg), and the original had little to do with software as we know it. In other words, the supposed “break” between software and hardware in the context of usability and customer experience – whether it be in the context of software development or car manufacturing or anything in-between – is superficial and purely historical. Now, for the record, lean development – or LSD specifically – can be summarized by seven principles that, according to Wikipedia, are “very close in concept” to their manufacturing counterparts (listed here in the order of importance):

• Eliminate waste
• Build integrity in
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• See the whole

How does a drum play into this? (pun intended)

The lean approach to product development, which – as we now know – started with new industrial manufacturing trends decades ago, is about simplicity. Not the kind of simplicity that differentiates a plain-text editor from Microsoft Word, but the kind that separates a drum from, say, a violin or an electronic piano or keyboard in terms of complexity.

A typical piano keyboard is a nightmare from the standpoint of lean manufacturing. It has hundreds of microchips and dozens of hardware buttons and contains a vast amount of computing capacity that translates human inputs into music, which – mind you – can only happen with speakers and only when electrical current is present. A common drum, on the other hand, has only a couple of parts and will play sounds anytime and anywhere. You get the idea: a drum is simple, while an electronic piano is not.

Back to Software

To transpose an electronic piano into the product development domain, it has many complex parts that come at a great cost. Although these parts provide a great utility, they make the underlying product less dependable, more prone to breakage and malfunctions, and more difficult to learn. The same naturally applies to software products: beyond a certain point in development, many products become uncontrollably complex and result in a slew of features that a vast number of users – including many power users – can’t appreciate, which in turn increases costs, increases break points, and potentially lowers product usability and customer satisfaction. Practically speaking, there is something known as the Law of Diminishing Marginal Returns – a fundamental economic principle, which is defined as the decrease in the marginal (incremental) output of a production process as the amount of a single factor of production is incrementally increased, while the amounts of all other factors of production stay constant.

A classic example is adding more workers to a job, such as assembling a car on a factory floor: at some point, adding more workers causes problems such as workers getting in each other’s way or frequently finding themselves waiting for access to a part. In all of these processes, producing one more unit of output per unit of time will eventually cost increasingly more, due to inputs being used less and less effectively. Eventually, by increasing the product’s function you may actually be increasing its cost to a point of incurring an operating loss, directly or indirectly.

The same applies to software. In my mind, a good practical example is Skype, which I find to be a rather invasive application that I’d love to run on my MacBook Pro all the time… but choose not to because it consumes more system resources than I am willing to give up in exchange for the privilege of being easily accessible to my international colleagues.

With that in mind, I like to say – as one of my good colleagues taught me in 2006 – that all good products must start out as drum and not as a keyboard, while most products don’t ever need to turn into a keyboard. So, don’t let my odd metaphor confuse you when you hear these words from me while discussing an app, a website or a software project. For at the root of every successful digital product there lies a simple principle: if you are going to make an electronic pieno, be sure that you have the advertising budget and the positioning strategy to market this baby to the people who will appreciate it. Otherwise, keep your product simple and don’t add things to it just because they are “nice to have.” The thought that “premature optimization is the root of all evil” (courtesy of Donald Knuth) also comes to mind here.

And every time you feel like questioning this logic, play with an Apple device to remind yourself that successful products don’t have to be complex, nor do they have to please everyone. Speaking of successful products that can be improved, I have written a related post about sealed batteries in Apple devices – check it out.

Do you want to continue this discussion? Message me on Twitter to start a conversation.