Seven Sins of PM'ing

A coworker gave me the fun idea of writing a little post about some “seven sins” of product management earlier this week.

And since I’m not studying (lazy!), I figure I’ll spend a little time writing it up. I make no guarantee these are in any particular order, are the worst mistakes, or necessarily are even always mistakes. We’re paid for nuance, not rote application of “rules”. Besides, the whole point of this blog is for me to laugh at my younger self. So here we go!

In trying to keep the length of this piece short – so I didn’t run out of interest while writing it! – my discussions might be a bit shallow, and I apologize for that.

Having an ego

An ego can sink not only a career, but a life. I always say the greatest enemy is the difference between expectations and reality, and ego sure does drive expectations.

Egos hurt because you’re always trying to protect and reinforce them. Being right becomes a goal in itself, so folks with big egos universally take feedback poortly. How can you become a better person and build better products when you can’t see yourself as being wrong?

For a lot of the same reasons, I think it’s unwise when people argue with their manager and peer feedback. Why can’t they search for the kernel of truth inside instead to help make sense of it? Or they refuse to do important / grunt work because it’s “beneath then”. Wouldn’t you rather make a difference? Or they lean into their strengths and even redefine their weaknesses as strengths (big yikes).

Let’s just all lose the egos!

Spending more brownie points than you earn

My model of relationships is about balance. You can measure it in “brownie points” we earn and then spend with the people around us. I have a “purse” with every person I’ve ever worked with.

You earn brownie points by being a good coworker! You help, act thoughtfully, show up when asked, make adjustments when asked, collaborate, appreciate. You help someone with their goal even if you disagree. You spend them by fighting with people. You no-show to a meeting or reschedule last-minute. You hear a person’s strongly-held opinion and you go a different way. You tell someone their concerns aren’t the most important ones.

“Blowing up a relationship”, in these terms, is just spending a lot more brownie points than you have. “Drive-by product management” is product managers spending carefully, but without earning any points to start with. Promotions or role changes can make certain things cost fewer brownie points.

But you always have to count your brownie points and maintain the balance.

Misidentifying the center of power

I also imagine every team (or every decision, perhaps) having a “center of power”. Imagine each stakeholder (or function) seated around a table, holding fishing line connected to a ball at the center of the table. The most powerful stakeholders pull the hardest, and the ball achieves balance at the center of power. Even “data” can have a seat at the table!

When people misidentify the center of power, they’re often ineffective, because they got the wrong stakeholders on board. And they’re often frustrated, because they thought they were going to walk out with one decision and walked out with another instead.

Once, as an APM, I kicked off a three-person meeting with my director and my SVP. I couldn’t sleep that night, thinking of how simple my director’s words were, and if I could just string together the same words in the same sequence, I could be him. But of course it isn’t that simple; the model (correctly) shows it’s less about WHAT is said and more about WHO is saying it. And, oftentimes, the brownie points being spent and earned in the meeting.

And people’s biggest mistake: thinking the ball is closer to them than it really is …

Seeking to be right instead of seeking to learn

PMs are taught to have strong opinions, and I’ve said myself that a PM without a proposal is like a guitar without strings: useless. PMs have a “toolbelt” of skills like vision, narrative, storytelling, principles, strategy, data, and so on to land their proposals.

But if you remember that it’s not just “strong opinions” but “strong opinions, weakly held” you’ll see where I’m going with this. The best PMs are intuitive scientists; they rapidly identify new (true) information that doesn’t fit their theory and they modify the theory from the ground up if necessary to accommodate it.

I do this by starting from the fundamental assumption that everyone is always right (it works at a place like Google). We’re all just coming in with different information and perspective. If I can just extract the underlying information – and some people are bad at communicating their real underlying reasons, so I do use the word extract deliberately – I can make the proposal much better.

This requires always seeking not to be right, but to learn.

Accepting data you agree with and attacking data you don’t

Good UXRs will quickly remind you the limitations of their data. It may reflect all kinds of biases, some of which we can mitigate in study design and some of which are inherent to the methods available to us¹. And even perfect studies are subject to our own biases, like the human likelihood to see patterns where none exist, and – the one I see most – a likelihood to see only the results that confirm our expectations.

I very often see a study yield one result that everyone agrees with and another result that surprises some folks. It’s the same study, with the same biases and limitations, but we accept the popular result trivially then debate endlessly the one that surprises us. We only debate how the study’s bias affects the surprising issue, and even though it would’ve had similar effects on the unsurprising results, we never debate those.

In the end, we start about where we began, with maybe a bit of randomness depending on where the center of power has always been.

So I try not to pivot too hard on just one study for those big decisions, and instead wait for it to reproduce across multiple methods.

Large-group discussions

You do need large-group discussions to finalize things or make progress quickly or exchange information efficiently, but I don’t think it should start there.

If you really want to hear someone’s true thoughts, you need to pull them aside one-on-one. Yes, it can be slower, and it still requires the big-group meeting at the end anyway, and it often takes multiple “rounds” as your own opinion changes before your first and last one-on-ones. But the perspectives you get from people when they’re alone and you ask good questions are much, much more valuable than what you get in big group meetings.

In big groups, we just measure the center of power – group dynamics. We don’t exhange all information, or the most important information, or hear from the most-affected people. Being an “advocate” for yourself or your team is harder, and infinitely harder when there are 20 other people watching you and listening to you.

If you drive your work in small groups and one-on-ones before going to your big discussion meetings, you’ll make better decisions and earn more brownie points.

Applying small fixes for small problems

This sounds like a good idea – why overcorrect in response to a request for a minor tweak? Just make the tweak and move on. If your manager asks you to fix a phrase in a slide title, type it in, boom, done, move on. Congrats, you solved the problem! But did you understand the intent and philosophy behind the request?

I understand this especially well now as a manager. Most often when reviewing documents I find problematic patterns, like assuming the audience is more familiar with the technical details than they are. I can say exactly that – “you need to consider your audience isn’t technical, please avoid using this acronym and ones like it”. And I swear to you, reader, they spell out that acronym in words and resolve the comment. What I want is for them to rewrite the document from scratch with a different mental picture of their audience.

The first draft isn’t supposed to be the final one, after all.