Product Management Rule #6: Product Management Is Inherently Political
Product Management Rule #6 from the best-selling book, 42 Rules of Product Management, was written by Rich Mironov, Author, The Art of Product Management
Allocating scarce resources always leaves some people dissatisfied, and drives them to escalate complaints or question the decision-making process.
Product managers tend to have very rational, process-driven views of the world. We’d like to believe that our various stakeholders are thoughtful, unemotional, and willing to compromise and put the company’s overall strategic interest ahead of departmental politics and personal rewards. Of course, that’s not how it is in the real world.
One of our primary jobs as product managers is to prioritize what gets done (and the many things that therefore won’t get done soon.) Unavoidably, most of our internal customers will be unhappy with some of our choices. And that’s regardless of how well we’ve applied “internal ROI” and other quantitative approaches to creating the best road map. MRDs are only the starting point in an ongoing lobbying campaign for product improvements. In other words, product managers will always have to manage the emotional world of people and internal politics.
Setting the Stage
You’ve collected a nearly infinite list of possible improvements, advances, new features, and architectural repairs. Your goal is to build one orderly list of items, review them with Engineering for size and suitability, and then issue a definitive road map or requirements document (MRD or PRD) that formally declares what will be built. Being analytical and a bit compulsive, you think of this as the end of a long process, after which Engineering will leap into action.
You’ve had to make choices from a dissimilar list of potential projects:
- Broad feature improvements as demanded by the market, reviews, user groups, and your
keen sense of what customers want
- Internal architectural changes that will be invisible to customers but are needed for
improved quality or longer-term goals
- Customer specials for specific big accounts, likely to be of limited use to
- Bug fixes and cleanup that reduce technical debt
- High-profile product bets on emerging market needs or new technologies
Trade-offs within each group are easy, but across groups are nearly impossible. Part of your job is to balance these different categories so that your next release meets a few needs from each group.
Ultimately, an MRD is the culmination of intense negotiations with all parties (engineering, marketing, sales, customers). It represents a compromise based on your best judgment and the facts on hand. Ideally, you’ve also made each constituent group feel valued/respected/listened to. After emailing the final MRD to all groups, your team takes you out for a well-deserved celebration. This feels like a milestone.
Nearly immediately, though, two kinds of problems arise. One is caused by actual changes in the world: shifting customer needs, market trends, product experience, and general evolution. The second is lobbying from the sales teams and internal groups that did not get what they wanted. By making hard choices about which features are in your next release, you’ve had to postpone other legitimate requests.
Political Issues Require Political Solutions
Allocating scarce resources always leaves some people dissatisfied, and drives them to escalate complaints or question the decision-making process. This is certainly true of product plans, which prioritize Engineering’s projects and schedules. You can call this “politics” if you like, or “group decision-making,” or any handy phrase from the MBA Organizational Behavior handbook. Regardless of the label, even the perfect MRD will leave some of your constituents unhappy. To keep the process moving forward, you need political support for the decision process and your final choices.
Generally, this involves pre-negotiation with executives in Sales, Engineering, Marketing and perhaps Finance or Manufacturing. Helping them understand your process—and how their teams will get some of the things that they need—is one way to get ahead of escalations and second-guessing.
Product managers are paid to make decisions that have an impact on the broader organization. This makes us part of the internal political process. Rather than ignore this reality, we need to understand how decisions are made and remade and work within the system.