“Politics”
In most of my CPO coaching engagements, we eventually come around to the problem of “politics,” usually framed as frustration with C-level peers doing unexpected or unreasonable or department-centric things.
My default response is that we call it “politics” when we’re not good at it, or when it’s distasteful or confusing or somehow beneath us. If we see it instead as an essential part of executive leadership, we might call it “advocacy” or “getting things done in this organization” or “understanding the company’s reward system” or “building alliances in the C-suite.”
Backing up a bit, most product leaders (and engineering and design leaders) came up on the technical side, which has its own very special assumptions and language and debating style. We think of ourselves as rationalists, heavily data-driven, making long-term decisions for the good of the company, systems/process-oriented. (Can you hear GTM-side execs chuckling or perhaps groaning?) Our arguments tend to be non-financial and framed around data flows or technology or end user experience. There’s also the unspoken assumption that the smartest person in the room is usually right, so I often see some intellectual flexing in the guise of helpful corrections and comments – in case other participants missed our brilliance. (Full disclosure: I love this kind of intellectual swordplay.) And since we techies rarely have much of our paychecks riding on hitting current-quarter revenue targets, we have the luxury of planning into next year even if the numbers are weak this quarter.
Said nicely, though, our self-perceptions aren’t always accurate and our assumed superiority over go-to-market leaders is neither useful nor welcome [1]. Most importantly, that’s not how things work in most exec suites.
Here are some opportunities I see for many CPOs/product leaders to lead more, make positive changes at the company level, and not be blindsided by “politics”
- Understand the business... how this company makes and spends money. We (product leaders) need to think more – and talk more about – how the roadmap will drive revenue: framing trade-offs in broad economic terms rather than in vague qualitative words about voted-up features or technical debt or user experience. We need to champion what’s good for both the company P&L and our end users (who pay our salaries), not just what’s good for Engineering. IMPORTANT: Don’t be afraid to guesstimate – the rest of the executive team does it all the time.
- Unpack our company’s reward systems, especially around Sales and Marketing and Professional Services [2]. If closing new deals is worth more (in commission) than renewing existing customers, let’s not be surprised when Sales demands lots of “specials” to close new logos. If Marketing is bonused on NPS, let's expect them to push for simple-sounding features from last month’s survey. If Professional Services teams are rewarded for delivering minimally tested one-off product extensions, let’s insist that they own outages/fixes for the first 6 months of production use. This isn’t personal: people do what we pay them to do, not what we (Product/Engineering) want them to do.
- Merchandize product/engineering/design successes. The connection between “we shipped X enhancement” and “churn is down 8%, renewals are up $200k/month” or “support calls about authentication are 65% lower, saving €350k/year” may seem obvious to you, but are almost certainly not obvious to the broader company. If we don’t celebrate the frequent, specific contributions that our teams make… we can’t expect others to connect the dots. Or see that we’re making tangible contributions. Company-wide praise reminds everyone why we invest in R&D.
- Build coalitions. It’s rare for a CPO or CTO to singlehandedly argue a CP Sales out of “this deal is super-important, the prospect’s demands are simple, and there must be some slack in Engineering.” We’re usually late to the discussion, lacking key information, and seen as habitual naysayers. So savvy CPOs anticipate this (frequent) situation, and work with other functional leads ahead of the next occurrence... The CFO may be more attuned to accumulated service obligations and revenue recognition issues. The Head of Support may need help identifying that 60% of P1 crises are from one-off code. Marketing may wonder why MQLs for our ICP [3] are being ignored in favor of whales and unicorns. How do we (product leaders) organize some systematic C-level push-back?
- Fight for budget, headcount, appropriate metrics. Letting HR decide how many people we need – and their qualifications – is not a recipe for success. Nor accepting reduced budgets or staff cuts from Finance without a fight. Nor having Marketing choose product metrics for us. Hint: this is a core responsibility of leaders of every functional group. If you cede the playing field to your CxO peers, your team will be short-handed and working on the wrong OKRs.
It seems natural for product leaders to focus on technical issues rather than the core work of executives: people management, merchandizing and evangelizing success, building cross-functional coalitions, framing trade-offs in non-technical language, and jockeying for budgets and headcount and achievable metrics. Helping the leadership team (as a whole) to make good company-level decisions. If we get good at it, let’s call it “leadership.”
(Of course, there are lots of pathological, toxic, demeaning companies out there. “Politics as usual” doesn’t include employee degradation or sexual harassment or force-ranked reviews where the bottom 10% are fired. Knowing what normal politics smells like… makes it easier to identify whether you and your team should move en masse.)
Sound Byte
Whether we call it politics or organizational savvy, a product leader’s job includes helping the larger organization make good decisions – and not letting R&D go unappreciated or short-changed in budget battles. If that’s uncomfortable, there may be a Distinguished Product Manager role which fits better.
_____________________________
[1] In some of my workshops, I put up a picture of Dr. Sheldon Cooper, the physicist from TV’s Big Bang Theory, who always needs to be the smartest person in the room and needs everyone else to know it. He is not who we want to be in cross-functional groups.
[2] I’ve covered this in lots of different ways. See “A Working Request Process Should End in YES” or “Hearing About Accounts, Listening for Segments” or even my AMA on Working with Sales and Executives.
[3] Marketing Qualified Leads that match our Ideal Customer Profile. For fun, ask your CMO and CRO if they agree on what portion of MQLs turn into SQLs (Sales Qualified Leads).