Long time listener, first time speaker
Despite listening to countless talks at events and conferences, I never considered speaking at one until this year. When planning began in the Spring for the 2018 Unbox product conference with fellow Boston Product (BP) co-organizers Adam Sigel and Aakar Shroff, the idea of going for a speaking slot was planted. Having seen what it takes to develop a speaker lineup through last year’s organizing efforts, I thought, “Maybe I can do that do too.” The ensuing months ended up serving as a mini-lesson on honing the product development process that we as PMs strive to perfect.
Unbox 2018 was a great day for the Boston Product community (plus some folks repping SF and NYC). Our speakers did an amazing job covering a variety of impactful topics for the core audience of experienced product managers striving to be better performers. While spending much of the day helping organize, I managed to catch a number of sessions with highlights including a keynote from Spotify’s David Murgatroyd on Leveraging Artificial Intelligence and Oliver Young’s talk Measuring Yourself as a Product Manager. The lightning talks came right after lunch, with my talk “Loops Within Loops” kicking off a series of 5 five-minute talks.
That’s me above a few minutes into the talk after overcoming the initial jitters and kicking into gear. I got through the 5-minutes without any major issues — looking back it was all a blur and felt more like 5 seconds. I’d estimate that the talk had about 80% of what I wanted to say at about 80% of the desired effectiveness, which isn’t bad for a first time!
Sample feedback from our post-event survey had most responders rating it “Good” (equal to 3 out of 4) — with at least one person really disliking it, something that actually make the experience feel more real—you can’t please everyone.
I was surprised to learn how much of what we do as Product Managers could be applied to speaking gigs, especially in harnessing the power of iterative development. Since that was also the topic of my talk, it was a meta-feeling to apply those skills.
Here are 5 lessons I learned from PM’ing the process of prepping a lightning talk (Lesson 0 is that there is an XKCD comic for every possible tech topic).
Lesson 1: Don’t get stuck in Discovery
It’s easy to endlessly do competitive research, scope out the market, and ideate. Coming up with potential talk topics, reading informative posts on preparing a talk, and watching TED talks were activities that had merit but with diminishing return. Eventually it was clear that being “productively” stuck in the preparation phase seemed preferable to the clear yet difficult act of actually starting to put the talk together. Interestingly, it was a TED talk by Tim Urban which finally helped me “get off the couch.” If you’ve seen it and remember the end, then you know exactly why. If not, then I won’t spoil the story but recommend it if there’s anything you’re stuck on completing in life.
Lesson 2: When determining talking points (requirements), don’t lose sight of your audience and purpose
As the PM saying goes, “You are not your user.” While I’ve had significant exposure to systems thinking and feedback loop modeling, it was important to remember that the average attendee might not. On the other hand, as a group of experienced PMs, they’d be familiar with the general concept and so the more specific topic of Agile development would resonate.
As for the purpose — audience takeaways in a talk are the equivalent of Aha moments in a software product. Without them, you haven’t really accomplished anything longer-term for the audience/user. Much like a requirements doc might end up being a laundry list of features, it’s easy to lose sight of the objective for the audience when outlining a talk.
Lesson 3: When implementing, your prototype and MVP should have the functionality of the final product.
This brings to mind Henrik Kniberg’s cartoon that’s become a famous metaphor for MVP development.
I made the rookie mistake of coming up with a ton of content early on, intending to prune it down later to a 5-minute talk. That was the equivalent of scoping and designing a full-blown new platform when you really just want to deliver a small delightful moment on one screen.
Iterative thinking and development is a dense meaty subject so it was easy to overstuff by feeling unconstrained. As a result, in my early practice sessions, the talk felt like the just first 5 minutes of a much much longer talk, resulting in little impact. So the lesson here was clear, if the versions that you iterate through don’t actually deliver the intended value then you’re not going to finish with what you want. Ruthlessly prune non-essential functionality from the beginning and you won’t have to worry about feature bloat.
Lesson 4: Consider all user feedback … but judiciously apply what’s relevant from the right users
A big thanks to several of my colleagues who assisted the whole development process, ranging from pitching topics at the start to testing out talking points to sitting through various versions of the talk. The feedback here was relevant and useful because these folks were all product managers- representing the audience that I would eventually be standing in front of. Much like a stand-up comic workshopping jokes in a club, this made it feel higher-stakes than say presenting to family and friends, but the resulting feedback was more applicable.
Along with selecting the right testers, it’s equally important to filter their feedback for what I’d consider the most important question: “Did the product achieve the intended purpose?” If the answer is yes, then secondary questions like, “was it delightful?” or, “how efficient was it?” can be considered, but if not, the focus must be on making changes so the user value is delivered.
Lesson 5: Strive for faster and tighter loops during development, then after take a step back to look at the slower and looser big-picture loops.
Again, given that my talk topic, this lesson really hit home. I was able to see how intense short iterative cycles are effective in a context outside of day-to-day software development product work. In order to be properly prepared by the conference date, I iterated upon multiple versions (~5) of the talk, each of which took variable amounts of time to prepare and then improve. If I had instead approached this as a single linear process that ended with Unbox (e.g. waterfall) then I might have still hit the deadline but I doubt the talk would have been effective.
Now that it’s done, through activities like debriefing with my co-organizers and writing this post I can also see how this first talk is just the first loop within a larger loop of growing as a communicator and public speaker. By carrying forward the learnings from these lessons, my future presenting endeavors will benefit.
Bonus Lesson: I was hoping I’d remember to mention this in the talk and managed to squeeze it in — but the movie Groundhog Day is a powerful and unexpectedly deep illustration of the power of iterative development. Being the PM for Enlightenment as a Service (EaaS) … now that would be a interesting job.
Are you a product manager who’s always wanted to give a talk in front of an audience but have been hesitating? Go for it! In the spirit of continuous learning, the experience of preparing and speaking will allow you to apply PM skills in a different arena and discover your own lessons to bring back to work. If you’re worried like I was of ending up on stage tongue-tied despite all the preparation, I’ll leave you with a parting thought:
Choose to speak from the heart on matters that you care about, have experienced firsthand, and want others to care about too — then the words from your mouth will follow.
