National politics might dominate the headlines and dinner table conversations. But office internal politics impact your everyday life in a completely different manner.
These outbreaks of disagreements, egos, and power grabs stand between you and your goals. They stymie your efforts to “move fast and break things.” They derail approvals and send you back to the drawing board.
Unfortunately, internal politics are pretty much unavoidable as soon as a company hires its second employee. As a product manager, you’re more likely to find yourself embroiled in these events since you sit at the nexus of so many activities and constituencies.
And while there are occasionally some truly original internal politics-driven struggles, most of them have happened before and will occur again. It’s best to be prepared for these inevitable distractions.
We outlined the seven internal politics situations you’ll likely encounter at least once in your product management career and how you can handle them.
1. An Executive Needs a Feature *Now*
Situation: You’ve painstakingly constructed a roadmap after consulting with various stakeholders, the development team, and your peers. Everyone approved it, plans are in motion, and things are moving along nicely. Then you get an out-of-the-blue request from an executive to finish Feature X yesterday.
Most of the time, this isn’t an option; if you could’ve built it instantly, you would have. Even if you slammed the brakes on everything else in production and made it an all-hands-on-deck emergency, you’re still usually looking at weeks between now and the actual ship date. So how do you handle it?
Solution:
- Understand their motivation. Why do they need this right away? What changed? Where is the pressure coming from? Remember, they’re dealing with board members, investors, and customers who may be applying pressure.
- Sympathize. Even the boss has a boss, not to mention demanding customers. You know what it’s like for someone to make unreasonable demands of you. Redirect some of those customer empathy skills toward your superior.
- Abstract the goal from the feature. What do your executives want? Maybe there’s a workaround or interim solution that can placate whoever’s demanding it.
- Cite the tradeoffs. Nothing in life is free. Make it clear what is sacrificed by bumping this feature to the front of the queue. Focus on the outcomes of competing priorities and not the functionality itself (i.e., “we can’t close this prospect” or “our competitor is eating our lunch because we lack this”).
2. Disgruntled, Vocal Engineers
Situation: A dysfunctional dynamic between product management and engineering (or specific engineers) can turn a workplace into a miserable minefield. “Soft skills” aren’t always part of their repertoire, not to mention loads of “developer-speak.”
Placating and pacifying aggressive rabble-rousing developers is a necessity when product management internal politics get involved. Here are some suggestions on minimizing the drama:
Solution:
- Get them excited about the opportunity. Engineers should hear why they’re working on a particular project. Learning what pain points they’re solving is motivating and will keep any complaints at bay. Treat them like any other stakeholder. Be sure they’re aligned with the vision and goals for the product. While disagreements may arise, you’ll all be working toward the same thing.
- Give them a say upfront and early-on. Some engineers don’t like that they don’t get to make product decisions. They don’t just want to be cooks; they want to be chefs. Let them offer up their opinions before development begins, ideally at the MRD/goal setting/roadmap phase. The early communication addresses any second-guessing from the implementation phase of projects.
- Set clear expectations. Agreeing upon a definition of done takes away the wiggle room and uncertainty that can plague a project. Remove any doubt regarding whether or not something is ready to release.
- Stay in your lane. Don’t try and own more of the process than you need to. Define precise requirements, let them know about deadlines, and then step back to let them do their thing. They’ll have questions and need input, but you don’t need to backseat drive them while they’re coding.
3. Missing a Promised Delivery Date
Situation: Stuff happens. Your estimates are wildly optimistic, and there’s a competing priority created a delay. Then things break. Parts were held up in customs, or engineers got the flu.
There are countless ways something may fall behind schedule, with the net result being a significant schedule slip for a promised feature. This deadline miscalculation is when people point fingers of blame and assign whose fault it is.
When a postponement is unavoidable, it might get ugly. The best you can do is soften the blow.
Solution:
- Provide early warning. Dropping the news that something is late on the day it was due is doing you no favors. As soon as there’s a hint of possible slippage, start socializing it among stakeholders invested in that date.
- Understand why the date is important. Were there real business reasons driving the date, or is it just following through on a commitment? If there is a business impact, explore alternative interim solutions.
- Minimize the damage. Trim the fat and take an MVP approach to the feature. Work with the team to figure out how quickly you can get it out, even if it’s not the optimal experience.
- Apologize. Regardless of who’s ultimately to blame, step up and take the hit. It shows character and that you’re willing to take ownership even when things aren’t going well.
4. Design Disputes
Situation: Product managers and UX designers share a common belief that inevitably leads them to conflicts: “I understand the customer best.” Both teams are trying to do right by the customer, meet their needs, and solve their problems.
The problems emerge in execution. Product managers aren’t supposed to have a pre-baked implementation in mind. We’re supposed to clearly articulate the business need and let everyone else figure out how it will work.
However, product managers usually have preconceptions of how things will look and behave. When the UX team presents their proposed design, those preconceptions don’t always line up with it. Conflict ensues, as both parties want to do what’s “best” for the product and its users.
Aspire for detente with design by focusing on collaboration.
Solution:
- Communicate early and often. Involve UX as soon as possible in the process, so they feel like partners and not subcontractors. They should be comfortable asking questions throughout the design process. It would help if you were quick and forthcoming with the answers they need.
- Don’t minimize their work. UX isn’t just making it pretty. They’re working on fundamental workflow and usability issues that directly contribute to the success of the product.
- Go back to the goals. Is the proposed design getting you where you need to go?
- Defer to the experts. If it’s a matter of personal preference or tastes, UX should always win.
5. Being the First Product Manager at a Startup
Situation: We all know founders shouldn’t try to wear the product manager hat once things start gaining steam. But, once they pull the trigger and bring on that first product manager, it can be a real adjustment for them.
They’re no longer a dictator when it comes to the product. They don’t make every decision and micromanage every detail. It’s not easy to embrace delegation and build trust with the new product manager hired to shepherd their baby.
Solution:
- Start with the tactical stuff. Many think that being the first product manager hired means you get a chance to be super-strategic. However, you must often take a backseat to the founder, who’s still heavily involved in these matters. Over time you might be given more responsibility, but vision, product-market fit, etc., is still in the hands of the founder until things are established and they’ve moved onto other matters.
- Get aligned on the vision. If you and the founder aren’t seeing eye-to-eye on the product vision, you’re going to be in constant conflict. If you get the big-picture set, then the details should follow smoothly.
- Share, don’t tell. Since product management is your full-time job and the founder has many other responsibilities, you’ll inevitably know more about what’s happening than they will. Instead of presenting data gleaned from users, developers, and research as irrefutable truths, offer it up as useful intelligence to add to the decision-making process.
-
- Make yourself useful. Until you’ve earned their trust and put in some time as a product management grunt, you can’t expect the founder to relinquish any real authority willingly. So keep plugging away and building up that credibility. Over time they’ll realize they need to offload things, and you’ll be ready to receive them.
6. Sales Complain that “the Product is the Problem”
Situation: To be successful, salespeople must be highly persuasive. They should also be able to map an organization, find out who has juice and work those folks.
So if a salesperson (or, gasp, the entire sales team) thinks you (or your product) are the problem, it’s going to get ugly. They will complain. Sometimes, they will lobby. They may cite anecdotes and conversations you have no way to refute since you weren’t there.
If the salesperson has a track record of delivering deals and revenue, their opinion will be given a lot of credence over you the product manager that never leaves the office.
They might say the entire product is at fault for their lackluster pipeline; it’s far more likely that they’ll pick on a particular aspect or “missing piece” of the product. This missing aspect will become the “only reason” they’re not hauling in whales. Then management will start wondering why you’ve prioritized anything over this “killer feature” that will solve everyone’s problems instantly.
Solution:
- Don’t disagree. You weren’t in those sales meetings, so you’re operating from a position of weakness to call “hogwash” on sales’ claims. Assume their request has merit.
- Do your due diligence. Explain that you want to be sure what’s delivered is going to meet the customer needs. If sales are shooting straight, they won’t mind a product manager chatting with prospects if it helps them get that deal done. If they’re hesitant to let you have that conversation, then it looks fishy.
- Get a guarantee. If sales are so confident that this functionality is the difference-maker, get them to put their money where their mouth is. Letters of intent/memos of understanding are legally dubious, but it gets everyone involved to agree that when you deliver, the customer’s ready to pay up.
- Dig in your heels with good reason. If you still disagree, you need a rock-solid case for why you’re standing between the company and this theoretical windfall. Be sure you’re making your case with stakeholders one-on-one to build support and see which way the wind is blowing.
7. Explaining a Failed Feature/Product
Situation: Nobody bats a thousand when they’re a product manager. There are plenty of possible reasons something failed, and the responsible party may or may not be a product manager. Given that, in many cases, product managers don’t have organizational authority, it’s hard to pin anything 100% on us.
- Don’t get defensive. If people blame you, don’t take it personally. Blame is an initial, emotional reaction, and you’re the low-hanging fruit that can’t bite back. Let it go.
- Stick to the facts. Conspiracy theories and accusations aren’t going to help anyone learn from this mistake. Use real data, customer interviews, timelines, and other hard evidence when recounting what transpired.
- Conduct a post-mortem. The product or feature is deceased, so it’s time for an autopsy to determine the cause of death.
- Own your mistakes. Whatever your part was in this unfortunate outcome, take responsibility, and commit to improving going forward. If you must create or tweak a process, take the lead on making it happen.
Takeaways
The seven internal politics situations we just covered merely scratch the surface of the political pitfalls of product management. While you may view these spats and personality conflicts as obstacles, working with people is the most critical part of the job.
Product management leaders anticipate, minimize, and settle the internal politics conflict, so it doesn’t derail product plans. Looking for more tips on excelling in product management? 
