Product Management Rule #6: Product Management Is Inherently Political

42 Rules of Product Management

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.

Download All Of Our Free Resources Here

Download Now

2 Replies to “Product Management Rule #6: Product Management Is Inherently Political”

  • Extremely well-written and completely accurate. I was nodding my head throughout. It’s even worse when you are introducing professional product management into an organization for the first time; and it can be worse yet when your own boss doesn’t understand the process. Therefore, it is essential that you spend time – in groups, and one-on-one – simply educating stakeholders – both technical and non-technical.

  • What a timely post. Almost the exact lessons I’m learning on my job. Ideally you are given a goal, you build a broad vision and then you go. You do all the right things, involve stakeholders, arrange the priorities, negotiate solutions, assume you have everything lined up and bam you are blind sided by some organizational politics that you least expected and you get left out in the cold. Not sure what to do. One thought I have is to break things down to small deliverables and aim for quick successes. That should get more people on your bandwagon and you build an army of supporters. Is that just motivational talk or is that real? What is your experience?

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *