I see product management as a role fostering connection—combing business strategy, user needs, and technical acumen. The challenge is being accountable for a product’s success without direct authority, but instead must enable collaboration, remove roadblocks, and make decisive choices when the path forward is unclear.
This role resonates with my background as a muralist coordinating artists across Seattle and Bellevue. I’d sketch concepts and paint the story in artists’ minds, then empower them to leverage their unique styles toward our shared canvas. The book emphasizes that great PMs “bring out the best in people on your team” and avoid the “Hero Product Manager” trap of trying to build everything single-handedly—exactly the hands-off approach I developed through mural work (Lemay, 2024, Chapter 1).
However, the reading challenges my assumption that PM work is primarily about vision and creativity. The author stresses that day-to-day work involves “less building than it does communicating, supporting, and facilitating” (Lemay, 2024, Chapter 1). While I focus on creative problem-solving, the book suggests the unglamorous connective work—understanding what needs to get done and figuring out how to make it happen—defines effective product management. My artist instincts provide relevant collaborative skills, but Stanford’s technical foundation fills a critical gap: the ability to communicate credibly with engineers.
The book’s discussion of “Ambiguously Descriptive Product Roles” is particularly relevant to my question about career paths (Lemay, 2024, Chapter 1). Rather than seeking one “correct” definition, the author suggests focusing on “doing your specific product job as best you can” (Lemay, 2024, Chapter 1). This supports building around my niche in local travel while developing technical and business acumen, especially with the book noting successful PMs coming from diverse backgrounds including “music, politics, nonprofits, theater…” (Lemay, 2024, Chapter 1).
Questions:
The book states PMs come from anywhere and don’t particularly need CS backgrounds, yet also emphasizes you can’t succeed without technical credibility. How do you navigate this tension practically? At what point does “enough” technical knowledge become trying to be an engineer?
You discuss avoiding the “Hero Product Manager” trap, but also emphasize PMs must proactively identify problems rather than waiting for direction. When I coordinated murals, I learned to distinguish between “stepping up when needed” versus “taking over because I don’t trust my team.” How do you maintain that balance, especially when you see problems your team hasn’t flagged yet?
The book describes PM work as largely unglamorous facilitation rather than visionary moments. Can you share a specific example where seemingly minor connective work—a meeting you facilitated, a miscommunication you caught—ended up being critical to a product’s success? I’m curious to see the impact a PM’s task has day-to-day.
Reference:
Lemay, M. (2024). Product Management in Practice: A Practical, Tactical Guide for Your First Day and Every Day After (2nd ed., revised and expanded). O’Reilly Media.
