I’ve worked with several project managers over the course of my career as a product designer and it’s always struck me that no two PMs define or execute their role in the same way. Their priorities, areas of ownership, and backgrounds have never been the same but they’ve all been dynamic, proactive, and resourceful. I took this class to figure out what other common denominators exist among PMs and why many other aspects of this role vary so significantly.
My question began to be answered during one of our first lectures which centered around the responsibilities of product managers. The scope of their responsibilities turned out to be …everything. While, if everything goes well, PMs are not the primary contributors implementing research, design, and code, the buck stops with them. Any output that is measured and evaluated, along with the elements of product driving that output, are the responsibility of the PM. It started to become clear to me why no two PMs I’d encountered were quite alike–there’s no single route to solving an impossible problem. After taking this course, that is how I would describe product management: an impossible task. Balancing quality, efficiency, creativity and the slew of variables that get in the way along the journey of conceiving of and implementing a product has no platonic ideal. There are infinite ways to go about it and no single way to define the quality of an approach. If anything, I’ve learned that, while it may be more closely tied to measured outcomes in some cases, product management is more similar to design than I’d realized. The value of the work, even the relevance of the metrics they are beholden to, is inherently subjective because both roles sit squarely in a sea of product ambiguity.
I’ve enjoyed many aspects of my stints as a product manager during this course, including devising strategy and discussing product tradeoffs, but this tension around highly subjective quality assessment and total responsibility has felt uncomfortable. It is incredibly difficult to set the boundaries that maintain your sanity when your role is completely boundless. I have really appreciated the frameworks, like OKR and outcome-based roadmaps that product professionals use to tame the scope of their strategy and their priorities. The clear and fairly ruthless way that product management requires you to define and strategically chip away at your goals is a skill that holds incredible value for adjective professions like product design as well.
That said, I have wished that this course more closely reflected the constraints and dynamics that I’ve experienced in industry. Our projects have been based on concepts that were selected in the first week after minimal needs finding and, given that pivoting required duplicating work, it was easy to almost immediately stay away from product-market fit. The further that we get, the harder it is to make the sort of high-stakes product decisions that I’ve observed PMs grapple with because the stakes have been inherently lowered by the impracticality of the product concept. I wonder if basing project work around a single, established product, with every team owning one area of the tool, for example, an EHR where teams own security, patient records, and provider portal, might make the dynamics and trade-offs more tangible.
