Getting in the feels
Config 2025 was a lot of fun. At my favorite talk of the conference, Ebi Atawodi compared product teams to film crews with the kind of confidence that made me momentarily forget that I've never stepped foot on a film set before. She analogized PM as Director, Program Manager as Producer, UX Designer as Cinematographer, and Engineer as Editor.
Her insight that Directors, like PMs, do "everything and nothing" resonated deeply. As a PM, I do a variety of things: I craft sales strategy, triage software bugs by severity, and champion new features through the product development maze. Mostly, I make a lot of judgments based on pretty limited information, and ask a lot of questions to make better decisions.
While I'm somewhat skeptical of using Hollywood as our model (the drama of the film industry makes me wonder if their team structures are optimal), Atawodi's core message about storytelling struck a chord.
Her suggestion to write scripts instead of PRDs felt like someone giving me permission to abandon soul-crushing Confluence templates in favor of a more human map of features. I've been testing this approach while working on a brightness gradient feature.
Technically, for this feature, we need three distinguishable levels of brightness. But the meaning of 'brightness' changes depending on whether you're capturing a campfire story, or lighting a TV studio where someone's career is impacted by how cakey their foundation looks. So it's important to have the context of stories behind each brightness range, especially when making technical compromises. If it takes three additional months of engineering development to make 200-300 lumens possible, a compelling user story might justify that investment—or help us accept a lower maximum brightness.
This balance between emotion and analysis is my daily struggle. Atawodi's fundamental insight—that emotion makes stories memorable—explains why some features stick and others fall flat. Onboarding experiences either convey "we understand you" or "we designed this after the CEO shot down the first two ideas." The results often reflect the process all too visibly.
There's something satisfying about imagining something, documenting it, and watching it materialize. Finding the right words matters before, during, and after product creation—not just for documentation, but for alignment and inspiration. Script-style PRDs might not work for every technical feature, but they change how we think about the problems we're solving.
Atawodi's challenge sticks with me: What story am I dying to tell through my products? (Besides "it would be cool if you liked this feature we spent six months building"). Perhaps the answer lies in finding that sweet spot where technical requirements and human narratives converge—where lumens meet campfires, and metrics meet meaning.
