(A small disclaimer: a lot of thinking out loud is about to follow, with the caveat that I may revise and update this later for something slightly more polished. Sometimes I write more crafted entries (as with my movie / book / game posts), but it feels like a burden to have to deliver than just messily laying my thoughts out on the screen. So consider it a living document.)
The other week I told my colleagues they needed to be more like Yoda. It was part of a two-hour Design Thinking and Storytelling class I taught at work—yes, at work, and the truth is, this is fun stuff. It has been a blast to contribute to the work of an amazing team creating an online curriculum on implementing Product Management at the Fed, and I’m grateful to have been tapped for the effort.
What follows further below is a ramblingly annotated list of references, all of which were extremely helpful as I wrote up my seminar, which I sent, minus most of the commentary, to the participants after class.
Here’s what I do for this introductory class:
- take elements of cinema and some of my own experience in writing fiction
- combine it with my day job as a product manager
- advocate for deeper and longer qualitative user research (I used to be an anthropologist after all)
- wrap it up in marketing principles
- and teach co-workers about it.
No lie; this floats my boat. In the class, I’m able to talk about why Walter White’s motivations as a character need to be established early in Breaking Bad and the importance of staying in the problem space to clarify and refine the root challenge towards designing a product. Or what Luke Skywalker has to do with customer success. Or I compare Amazon’s “Buy now with 1-Click” buttons with the famous scene in The Terminator when Kyle Reese tells Sarah Connor, “Come with me if you want to live.” (They’re both calls to action, of course.)
This month’s class was my third time to teach about storytelling and product management—I had been teaching it informally to my teammates (more later)—but my first time to be part of a formal curriculum, and my first time to include a brief overview of Design Thinking. I did send a note to the class explaining that one could take hours of classes on any one of the phases alone—or a lifetime if you’re in user research—and that what they were about to hear was simply the tip of the tip of the iceberg. This wasn’t even design theater (ouch) as Christina Wodtke has put it, but more of an amuse-bouche, I hope.
A design thinking example. Of course, I had to start with a story. The GE Adventure Series scanner is always a favorite, but I rather like the example of the Embrace Infant Warmer. It’s also a heartwarming story, no pun intended, and, most important, it includes an instructive example of reframing a problem as the result of user research. (Those familiar with the story may remember this part, when the researcher sees all these empty incubators inside a Kathmandu hospital and discovers that mothers were instead having babies in remote villages many miles away. Redesigning an incubator using cheaper materials would’ve solved the problem as they understood it, but contextual inquiry unearthed a deeper root cause, and led to a more innovative and far less expensive product as a result.) There have been numerous articles (even a TED talk) on the Embrace Infant Warmer, but for a good quick read, check out this Salon article written by Tom and David Kelley from IDEO.
Readings on Design Thinking. I had initially wanted to show my colleagues the different ways in which the design process has been conceived—the British Design Council’s double diamond, the Stanford d. School’s hexagons—then ended up choosing this one.
(Using only one was the right choice, as the students didn’t need to learn that history for an overview class.)
For reading up on design thinking, you can’t go wrong by going straight to the source, over at IDEO. I also really like the Nielsen / Norman Group’s take, in this article by Sarah Gibbons (and the source of the illustration above), not just because it summarizes the different spaces of design thinking, but also because the article explicitly depicts the iterative nature of the process.
A Design Thinking activity. Here’s Sarah Gibbons again, on the empathy map. This was, in retrospect, not the best tool for the occasion—given my time restriction, it had to be a solo activity—but the takeaway here is found precisely in the challenge of filling it out. Ideally it should raise questions in the product manager’s head, like “How do I get the information I need to fill this out?” and “How is it possible I don’t even know how my customer feels about the application I helped make for them?” Note to self: in a future version of the class, I should make the exercise something students would be able to do the minute class ends, and not give them a tool dependent on input which they may not have—which, of course, is part of the problem. In any case, empathy is a muscle we should all be exercising regularly. It’s not just true for product management; it’s true for life.
The Hero’s Journey. Next, I talk about some product management / marketing principles, like “Make your customer the hero”—but just because they may be cliched doesn’t mean they’re not right. So it was fun to pull in something from my own fiction writing: the Hero’s Journey. The utility of the framework—for novelists, screenwriters, therapists, and this guy, for starters—is seen in its ubiquity in popular culture; even high school students use the structure as part of their English homework assignments.
There is even more material out there on Joseph Campbell and the Hero’s Journey, but they won’t be directly related to product management. But if you’re interested in delving further into the common structure shared by The Hunger Games, The Matrix, The Lord of the Rings, the Harry Potter novels etc., Christopher Vogler’s The Writer’s Journey: Mythic Structure for Writers is the classic text and a fascinating read (other than Campbell’s own The Hero with a Thousand Faces, which I haven’t read).
Marketing. Donald Miller’s Building a Storybrand is very much recommended; his book in many ways crystallized a lot of the ideas floating around in my head when I was plotting my crime novel at the same time I was plunging into product management.
Yes, it’s straight-up marketing, and perhaps alien to my fellow civil servants, but as famous salesperson Zig Ziglar once put it, “I have always said that everyone is in sales. Maybe you don’t hold the title of salesperson, but if the business you are in requires you to deal with people, you, my friend, are in sales.”
The emotional dimension. I talk a lot about getting to all the squishy qualitative stuff about people that requirement documents don’t capture. Working in an organization where traditional agile-fall project management still holds sway, we product managers at the Fed will probably always have our heads down writing user stories around highly technical product specs. It’s inevitable.
But our collective transition to product management doesn’t necessarily require the unlearning of our knowledge about Gantt charts and critical paths. The shift is more about adjusting the lenses through which we see the products we create, and actively seeking data about that subjective, warm-and-fuzzy dimension—and in turn a shift towards the people who use our products. Product Managers! Embrace the squishy!
Speaking of squishy, here’s Amanda O’Grady on the emotional component of products. I don’t always have the greatest patience for buzzwords like “delight”—sometimes a tool is just a tool, you know?—and O’Grady even capitalizes “Magic” and “Meaning,” but she passionately advocates for putting emotion at the core of design. In contrast, organizations generally prioritize emotion last, despite all those Forrester and Gartner studies that show the importance of customer experience. She is careful not to skip past the functional aspect of design though, and emphasizes how focusing on the emotional dimension can inspire teams to think more holistically about how the experience feels to a customer, and not just what the site or application does.
And finally, even more inspiration from Sarah Doody; the title says it all: “Why We Need Storytellers at the Heart of Product Development.” She argues for placing “product stories”—and a story, as I teach in my class, is a more intuitive and accessible framework for framing product strategy—at the core of product development. Product teams, she writes, focus too much on the technical aspects of execution—the how—instead of the why. (Being in IT, I can relate; it’s “natural.”) By creating a shared vision of the product for the team, product storytellers ensure that every element of the product, and the user’s experience of the product, cohere smoothly with each other.
The TL; DR version of the reference list
- Tom Kelley and David Kelley, “A Solution for Poor Mothers, When Expensive Hospital Incubators Won’t Do
- IDEO Design Thinking
- Sarah Gibbons, “Design Thinking 101”
- Sarah Gibbons, “Empathy Mapping: The First Step in Design Thinking”
- Christopher Vogler’s The Writer’s Journey: Mythic Structure for Writers
- Donald Miller’s Building a Storybrand
- Amanda O’Grady, “Stop Sprinkling Emotion, Start Creating Magic and Meaning“
- Sarah Doody, “”Why We Need Storytellers at the Heart of Product Development”
Postscript: On the Storytelling Framework as a Tool for Product Management
I’ll admit to being a little dissatisfied with how I brought Design Thinking and storytelling together. I had wanted to be very specific, in a product management context, about narrative and its relation with empathy. Stories, of course, create empathy on the part of the audience, whether potential customer or product team member; stories, after all, are far more persuasive than statistics. But I’m trying to push for empathy as the result of deliberate, intentional practice on the part of product managers, so… how do stories fit again?
The answer, I think, depends on me being very clear and explicit about the context in which the storytelling “tool” is used, and its utility thereof, on a scale of 1 to 5, with 5 the highest:
- Storytelling as a framework for customer engagement. 4 on the usefulness scale. Just actively striving to “make the customer a hero” would be a win in my book.
- Storytelling as a framework for pitching to the customer. 5 on the usefulness scale.
- Storytelling as a way of aligning a product team around the people using the product. Also 5 on the usefulness scale. This is part of the necessary shift in mindset from prioritizing outcome over output. (But how can I go about testing this though? How do I validate my assumptions once a product team starts seeing customers not as the font from which specifications and requirements flow, but as heroes who need help taking the ring to Mordor?)
- Storytelling as a way of facilitating user research, or augmenting the Discovery phase. 2 on the usefulness scale, because stories are necessarily the output from research. They simply don’t stand upright on their own without input from direct observation, listening sessions, and so on.
I want to refine this connection in later sessions if I get to teach this design thinking / storytelling combo class again.