My improv journey started at Mile Square Theatre, learning from Tarik R. Davis. Since then, I’ve explored improv, sketch comedy, musical improv, and storytelling. Somewhere along the way, I started noticing changes in how I showed up at work.
I became more aware of when I was planning my response instead of listening. I got more comfortable making a choice without knowing where it would lead, and letting something we created together turn out differently from what I had imagined.
On September 30, I facilitated the workshop, Play Better Together: Improv Games for Product Managers. I wanted to share some of the improv games that helped me become a better PM.
Hearing the rest of the sentence
In One Word at a Time, a group tells a story together, with each person contributing exactly one word. You might be planning the end of a sentence when someone adds a word that changes its meaning. Your carefully prepared contribution no longer fits.
I asked participants to notice the story they were secretly writing in their heads.
I recognize that habit in product conversations. Someone is still explaining a problem, and I’ve already started working out how to solve it. I’m following enough of the conversation to respond, but some of my attention has moved to my own answer.
Imagine a customer describing a spreadsheet they maintain alongside your product. It’s tempting to start thinking about how to bring that spreadsheet into the app. But if you keep listening, you might discover that they use it to explain decisions to someone who doesn’t have access to your system. That changes the problem you need to understand.
You can practice this in a customer interview by summarizing what you heard before proposing anything. Give the other person a chance to correct your understanding. Then ask one more question about the part you’re least certain of.
Improv has helped me notice when I’ve mentally moved ahead of the person speaking. That’s my cue to come back. There may be something in the rest of their sentence that changes my answer.
Letting someone else change the outcome
In Yes, And, one person establishes something, and the next person accepts and adds to it. It gets harder when someone contributes something you wouldn’t have chosen.
At work, that might happen when engineering raises a constraint with an approach you’ve spent time developing. You hear the concern, but your first instinct is to explain why your approach could still work.
There may be good reasons to challenge the constraint. But it’s important to understand it before you start negotiating with it.
Imagine engineering explains that a proposed feature would depend on data that only updates overnight. You might ask: “Given that delay, which parts of the customer’s problem could we still address? Where does freshness matter?”
That gives engineering a chance to help shape the solution, rather than leaving them to defend the limitation.
Acknowledging a contribution doesn’t commit us to every suggestion that follows. We still need to evaluate ideas, make tradeoffs, and sometimes say no. The practice is to understand what someone has contributed before deciding how to respond.
Making another choice when the plan changes
In Fortunately / Unfortunately, people build a story by alternating between fortunate and unfortunate developments. Every contribution changes the circumstances, and the next person has to continue from there.
Consider a team preparing to build a feature based on a recurring customer request. New research suggests that the request is a workaround for a different problem. The team now has information that could change the scope, or whether the feature should exist at all.
It’s easy to keep discussing how to deliver the planned feature. There’s already work behind it, people are expecting it, and changing direction creates more conversations.
To practice adapting, pause the discussion and name what you expected, what you now know, and which options still make sense. Then decide what to do next.
Why I wanted to share this
I’m still practicing these habits myself. In improv, I can notice them while very little is at stake. If I try to control a story about a haunted laptop, I get an immediate, slightly ridiculous reminder of how hard it is to build something together while privately deciding where it should go.
That was why I wanted to run the workshop. I wanted other PMs to have a chance to play, notice their own reactions, and consider where they recognize those habits at work.
If you’d like to try the games with your team, I’ve shared the handout from the workshop. It includes instructions and prompts for all three exercises. Pick one, play for a few minutes, then leave time to talk about what happened. When did you start planning ahead? What did you do when someone took the story somewhere you hadn’t expected?