Storytelling is at the heart of product management. Whether referring to assembling the nuts and bolts of product delivery, crafting a product strategy, or selling a product vision, stories are key to both successful product development and customer engagement as a whole. I’d even argue that stories—and no, I’m not just talking about user stories—are also integral to the execution of projects. A story—that simplest of frameworks—serves as a musical counterpoint, if you will, to the formal project management phases.
Consider below some general reasons for using stories (and prepare yourselves for some unapologetically mixed metaphors). In a later blog entry I’ll focus on storytelling and specific applications to product management—but I’ll set the stage first before the curtain rises.
So this radioactive spider accidentally got loose in a lab and—ahh, who am I kidding. But my interests in the intersection of storytelling and product management do have an origin story of sorts.
Most people keep the different spheres of their life completely separate: there’s the day job, and there’s the stuff they do for fun. By day I’m a senior product manager, working with development teams to build software applications for internal customers at the Federal Reserve.
At night—or on weekends, or early in the morning, or on the bus back when I used to commute to work—I write. That’s my other “job.” I write blog posts like the one you’re reading now, but what floats my boat the most is my creative writing. I’ve written and published a handful of short fiction, a couple of personal essays, and I’ve also left the husks of many short stories, a novella, and a full-blown novel in a metaphorical desk drawer. (I am, however, still working on a crime novel. I haven’t given up on that one yet.)
And for a long time, there was no connection between these two aspects of my life.
Sometimes my wife and I get into these conversations where I tell her about great advice I received, whether I read it in a book, or heard it from a colleague.
And she would say, “But I told you that before!” Which was sometimes true—I just didn’t recognize it as great advice then.
Sometimes it’s because of the way the advice is presented or framed, whether as a gentle suggestion or a swift kick in the pants.
Sometimes you hear something four or five times but the sixth time’s the charm.
Sometimes you’re just not ready to hear things yet. I’m reminded here of Nick Cave, on songwriting, emphases mine:
“You are not the ‘Great Creator’ of your songs, you are simply their servant, and the songs will come to you when you have adequately prepared yourself to receive them. They are not inside you, unable to get out; rather, they are outside of you, unable to get in.”
Some fortuitous combination allowed Jeff Gothelf’s Forever Employable to get in. Some of it has to do with my own receptivity, after being well-primed by some great managers of mine, and excellent career coaches along the way. But a lot of it has to do with Gothelf’s lucid, pragmatic style, and the way he gives you pointers to put into practice immediately.
(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.
From Unsplash.
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.
The other week I was conducting a storytelling and product management workshop—more on this in a future blog entry—and walking people through an exercise on customer needs. I had instructed the participants, who were IT managers and officers, to write down fictional characters and their needs, and then analyze the latter in terms of a functional dimension, and an emotional dimension:
Functional: A young man needs to blow up the Death Star and save the galaxy from the Evil Empire.
Emotional: Luke wants a larger purpose in the galaxy and longs to be a Jedi like his father.1
Then I asked the participants to think of the following:
actual customers and their needs,
the functional dimension, and
the emotional dimension
Simple, I thought: Functional needs were easy. We worked in IT, so we saw functional requirements all day. But the emotional dimension? A couple of participants expressed difficulty with this part of the exercise, and in the moment I, too, was stumped, because I was so used to baking in the qualitative outcome in my storytelling framework, and couldn’t properly describe to the participants what seemed to be a bit of a mental leap.
How do I work backwards, and contextualize how one gathers this “emotional requirement,” as it were? Some thoughts follow.
