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. Because the movie industry still feels very glamorous to an outsider like me, I felt a mild ego boost when she analogized a product manager as a director, a program manager as a producer, a UX designer as a cinematographer, and an engineer as an editor.
Her insight that directors, like product managers, do "everything and nothing" resonated deeply. As a PM, I try to do a variety of things: craft sales strategy, triage software bugs by severity, and nudge 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 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 never do.
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 inspiration and rallying the team. Script-style PRDs might not work for every technical feature, but they change how we think about the problems we're solving. On a similar note, it’s also important to me to keep things in perspective, and I think words can send the wrong message if used inappropriately, which is why I object so much to the usage of phrases like ‘war room’ for certain types of meetings. But that rant is for another post.
