How I Came to Storytelling and Product Management, or, a Short Origin Story
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.
These two realms started converging when I started structuring my fiction writing using, of all things, Trello, a project management tool. I used to be a big-time pantser — and will continue to do so with short fiction — but writing a novel required a little more organization. And the novel I had started (and am still writing) happened to be in the crime genre, which made it crucial for me to keep track of the sequence of events and figure out how to pace what I reveal or conceal for maximum effect.
So the project manager in me was already gravitating to a need for structure — something that writing by the seat of my pants wasn’t going to accomplish well. So I steeped myself in reading about plotting. I read about outline structures and the snowflake method.
And for each short story I was working on, I broke out my writing to-dos-”rewrite everything tagged #clunk,” “fix reporters scene”-and started working on them Kanban-style by moving tasks into “Doing” and “Done” columns. (And yes, I kept the WIP column to a minimum.) I created more categories — plot (intro, middle, end, epilogue), setting, character — and plugged in more to-dos, photographs of places and people, random snippets of prose I had scribbled throughout the day. It was a combined writing task list and mood board for my story and it worked perfectly.
Nothing new about a writing task list. But in my head, connections between these two seemingly alien universes were slowly snapping into place.
Here’s another connection. Take the example of the most basic unit of organization in Agile, the user story, which is something I use at work every day:
As a <type of user>, I want <some goal> so that <some reason>.
Like you’d ever use this outside of work, right?
So one morning I was commuting to the office and the bus was making its usual awkwardly wide left turn from 8th Street onto Central, right by Washington Park, and I was hunched over my laptop, squeezing in some writing time before work started, trying to figure out what my protagonist — which just so happened to be a bewildered techie lost in the desert outside Vegas — needed to do in a specific passage, and thoughts about work and a couple of sprint planning sessions scheduled that morning were inevitably seeping in — when that metaphorical bolt of lightning zapped the top of my head.
Because the structure of the user story is exactly how one writes a scene. Your characters (the “types of user”) want something (the goal) because of some other thing (the reason). (And if your characters in a specific scene are at cross-purposes, or they want the same thing but for different reasons, even better.)
What do they want, what are they feeling, what do they value — and how do you reveal these wants and emotions and values as they move around in the world and interact with other characters? (As Chuck Wendig writes, a scene needs characters who want shit.) Otherwise your characters flop around doing diddly.
(And to reframe this dynamic more specifically from a product management lens: your customers use your product for a specific reason — your product has a “job to be done” — so that they can achieve a goal. That’s the basis of a problem statement.)
That realization — I still recall to this day the bus ride and the view of a park outside my bus window when that bolt of lightning zapped the top of my head-was when I came to realize that some basic principles of writing fiction could also be implemented in product management.
This is no surprise to any reader long steeped in marketing and branding — but I am, however, not one of those people. I made a circuitous journey from anthropology professor to creative writer on the side to customer experience lead to straight-up project manager to product manager before I started stitching these connections together, slowly building up to a point when I felt confident enough to teach my storytelling and product management workshops at work.
So for product managers looking to engage with their product teams and customers more deeply and creatively, I got some stuff for you coming up.
p.s. The contents of a scene: One big difference in the craft of fiction is how writers should throw a little sand in the gears and put an obstacle in the character’s way. Keeping protagonists frustrated from meeting their goals is, in a sense, the principal way writers move a story forward.
In product management, of course, it’s the other way around: it’s all about understanding and minimizing that friction for users.
Originally published at https://www.thewilyfilipino.com.