Communicating Complex Concepts in Video: Luxr’s 5 Whys Video

Luxr has produced a clever encapsulation of the 5 Whys methodology, a technique for persistently probing the symptoms to find the root cause of a problem. Compared to several other “5 Whys” videos YouTube steered me to after I viewed this one I was struck by how practical and tactical Luxr’s explanation was. It communicated the concepts in way that even process averse startup folks could immediately engage with.

I transcribed the script below because I think there are several things to appreciate about it:

• They take a real situation that anyone can relate to. It’s a clever encapsulation of how a startup might stumble over a problem and use 5 Whys to get to root cause.
• They show the real way that the technique would be applied which is as a sequence of conversations as you peel the onion to determine who to talk to next.
• They never talk down to the audience and incorporate a lot of sly humor about what’s really involved in working in a startup.
• They enact a tiny drama to illustrate the method instead of using a talking head or slides.
• My unofficial transcript runs about 350 words and doesn’t capture about half of what’s going on (e.g. subtitles, some stage directions, some camera angle decisions, shot by shot breakdown). The video is about 75 seconds long. This is very dense compared to common “talking head videos” used to walk through 5 Whys. But the density keeps it interesting and communicates a lot more than you first realize.

Unofficial transcript:

1. Narrator: “Startups are works of focus, determination, and love. But all startups will eventually run into catastrophic, emotionally gut-wrenching problems.”
2. Kate, an overworked startup entrepreneur discovers the coffee pot is empty and asks herself “Why?” five times.
3. Narrator: “asking why should not be a rhetorical question. Ask “Why?” five times to help everyone on the team to search for a better solution together.”
4. Kate approaches a co-worker, “Jason, why is there no coffee?” Jason replies, “Because no one refilled it.”
5. Jason approaches Jeana and asks, “Jeana, how come nobody refilled the coffee pot?” Gina replies, “Because there are no filters.”
6. Gina then confronts Melissa, “Why are there no filters?” Melissa answers, “Because nobody bought any.”
7. A zoom in on the bathroom door shows a blue sticky note labeled “weekly shopping list” surrounded by yellow ones labeled: sticky notes, granola bits, tea, sharpies, beer, and “$1,000,000 in funding.”
8. Melissa approaches Janice and asks, “Janice, why did nobody buy any more filters?” Janice speculates, “I don’t think anybody knew we were out.”
9. Janice comes full circle to Kate, “Kate, why didn’t anybody know we were out of coffee filters.”
10. Kate pivots to the camera and summons her inner John Moschitta to speed talk her way through this analysis: “Because there was no way to tell that we were running low before we ran out so that we could prioritize buying more.”
11. The voice and hands of the Narrator returns: “Instead of fixing a symptom by buying a ton of coffee filters or casting blame on the heaviest coffee consumers, the “Five Whys” helped us to devise a system to solve our problems with a simple sticky note.”
12. His hands flip through a stack of coffee filters and affix a sticky–the hand to hand weapon of choice for all UX designers–labeled “Buy More Filters” to a filter about 1/4 of the way from the bottom.
13. In the final scene the narrator rushes into a unisex bathroom next to the coffee pot and closes the door, only to lament, “Hey, why is there no toilet paper?”

The point about saving money with a sticky over ordering a lot of filters was an approach that bootstrappers could appreciate. The ending brought a smile to my face and reminded me of  Van Vleck’s three question extension to complement root cause analysis:

1. Is this mistake somewhere else also?
   Look for other places in the code where the same pattern applies. Vary the pattern systematically to look for similar bugs.
2. What next bug is hidden behind this one?
   Once you figure out how to fix the bug, you need to imagine what will happen once you fix it.
3. What should I do to prevent bugs like this?
   Ask how you can change your ways to make this kind of bug impossible by definition. By changing methods or tools, it’s often possible to completely eliminate a whole class of failures instead of shooting the bugs down one by one. The bug may be a symptom of communication problems in the programming team, or of conflicting design assumptions which need discussion.

The original version of the video was available at http://www.youtube.com/v/MuT6E4RgHkk but has now been made private. I have substituted the official version which differs slightly.