Skip to content

  1. Solving the Wrong Problem

    I woke up to an NPR interview of author, Jonah Lehrer this morning. His book, Imagine: How Creativity Works, goes in depth on the brain science behind creativity and innovation in the workplace.

    One anecdote highlighted in the interview was particularly striking. A group of chemists at Procter & Gamble were given the task of designing a new soap for mopping floors. It turns out that this isn’t a simple problem to solve because stronger soaps, while better solvents for cleaning, can irritate the skin and strip the sheen from floors.

    After years of unsuccessful attempts the problem was finally outsourced to industrial design firm, Continuum. The first thing that Continuum did was take 9 months to observe people mopping the floors in their own homes. By watching the process they learned that the act of mopping is actually a very messy ordeal. Mops are designed to capture dirt and wringing them out is tough and often dirt is sloshed back onto the floor in the process.

    During the course of their discovery they found that subjects would often clean before the team arrived in their homes. So the designers would unwittingly spill coffee on the floor. In this experiment, the subjects didn’t go for the mop at all. They usually reached under the counter for a paper towel which they would wet under the faucet, use to wipe the floor by hand and toss into the trashcan.

    Thus, the Swiffer was invented – a disposable paper towel attached to a mop handle.

    So, what can we take away?

    Beware of solving the wrong problem – As evidenced in this anecdote, the smartest people in the world often are challenged not to start with the end in mind. According to the story, at one point Procter & Gamble had more PhD’s on staff than any other company in America. They tried to solve the problem as they saw it, but not as their users experienced it.

    [update: according to the P&G Doctoral Recruiting page on facebook, they have "more PhDs working in our core areas than Yale, MIT and UC Berkeley combined do in the same areas." (emphasis mine)]

    Observe people where they work - There is no substitute for watching users in their element when it comes to understanding the problem you’re trying to solve. We should also be careful to understand the side-effects of our discovery and design experiments that ensure we’re getting what came for. The Continuum team had to do this when they began to realize that their subjects were cleaning the floors prior to the observation.

    You’re not likely to outthink the scientists – Continuum took a different approach because they knew they couldn’t out-chemistry the chemists. Innovation is as much about the pedestrian work of learning and watching so that easier solutions can be developed to the address the really hard problems we face.

    Discuss on Hacker News.

    Categories: Innovation, Product Development, Product Management.

  2. Learning by Rapid Iteration

    You can read 100′s of books, listen to countless podcasts and read documentation and blogs, but nothing replaces actual doing when learning to program. The repetitive nature of coding -> compiling -> running -> troubleshooting -> fixing and trying again seems to be the key for me in learning new programming languages and platforms. This is how I learned to develop apps for the web over a decade ago, and lucky for me what I learned toiling away in those days is still largely applicable today (i.e. the fundamental nature of how the Internet works has not changed).

    This learning paradigm works well for programming, but it can also apply to other disciplines. The key is to figure out how to iterate often, “debug” your failures and try again. In the same way that consistent weight training builds muscle tone, exercises of the mind have the same effect.

    My son joined the chess club at his school and has (at 6) mastered the mechanics of the game itself; which pieces can move in which directions and the general rules of play. Now he is learning the strategy. To assist his learning, I’ve given him the freedom to “take back” moves as a way to facilitate rapid learning. He makes his move, we play out the scenario together, then he has the option of trying something different once he understands consequences of the move.

    It’s the hands-on experience dealing with small failures that is so important in learning. The more rapidly we can physically see the consequences of our actions, the quicker we can adjust to compensate.

     

    Categories: Agile, Productivity.

© Copyright Jay Nathan, 2010-2013