Why Did You Want to Become a Product Manager?

I've painted some pretty grim personal perspectives on Product Management in the past- perhaps comically so. There was that one time I dared make the sweeping generalization that most  PMs have no interest in technology itself, but instead favored the glory of power and implied intellect. Or that other time, when I suggested oversaturation of the space could push the title towards meaninglessness... similar to the fate of marketing departments recent fall from grace to what is best described as “MailChimp Coordinators.”  Brutal stuff.

That was around the time I decided to distance myself from Product and people who associate with it. I figured this bubble of egotistical hustlers would pop at some point. Thus far, I’m afraid I couldn’t have been more wrong.

Product Management: Bigger and Badder Than Ever

I mean “bad” in the literal sense, of course. Let’s rest on that for a moment to acknowledge what is objectively true: Product Management is certainly getting bigger. Bigger not only in the sense of volume, but salaries as well; reports are showing that average product management salaries have been on a steady upward trend (I'll post those them here once I find them). One report had the average salary of senior/director PMs overtaking Data Scientists: a perceived front runner for “sexiest job” thanks to a stupid article the Harvard Business Review wrote a hundred years ago. (On a side note, can we please never reference this article again? It’s excruciating to read field-based work without some subtle reminder that the author is “sexy.”)

In terms of volume of product managers, I don’t need to search for data to know something is wrong. Of the teams I’ve worked with in the last 10 years, whether they be external clients or departments in my org, it’s overwhelmingly common to see technical team breakdowns have as many or more Product Managers than actual engineers. In extreme cases, I’ve lobbied, begged, and cried for more Engineering staff in exchange for guaranteeing deadlines. The response, of course, is always the same: hire more managers. The thought process I imagine happening is “hey, there’s something going on there, we better bring in a Skilled Manager™ to figure that out!” Assuming that poor management is a company’s culture, the safest thing any upper-manager can do to hide their own cluelessness is place more buffers between themselves and problems.

My moment of Zen came to me after I had just started with a large company. Our team had a product team, as did the other (hundreds?) of teams in the same firm. With a straight face, our team’s Head of Product delivered the year’s initiative: to teach all the other Product Managers the concept of Agile Development. I paused. Looked around. Raised my hand, and could do nothing but say:

...Are we not addressing the more significant problem at hand here? How have we somehow managed to hire hundreds of PMs, each without the slightest clue as to how to do their jobs?

One person chuckled. As the head of product gave a political no-answer, I watched a room full of people trying not to internalize that statement. I was “taught” agile 4 times that year. I had been implementing Agile Development practices for 8 years prior.

Why Do You Want To Be a PM?

Ask any PM how they got into the profession, and I’ll almost guarantee you’ll receive some story of transitioning out of marketing or recruiting (neither of which have anything to do with product) because an opportunity opened up way back when. My personal answer to this question started by defining what I didn’t want.

It was a rainy day in Philadelphia. Now 10 years ago, the Comcast headquarters had just been completed as the tallest building in the city, and I held a gig on the top floor... as a Flash Developer. I was nearing the end of my contract, and a bit relieved to know that “White Shirt Wednesdays” and “Blue Shirt Mondays” would no longer remain in my vocabulary. As a favor, one of my bosses asked me to deliver a USB drive to a fellow on my floor whom I’d never actually met. After some quick directions to this gentleman’s office, I was beginning to see why he’d be hard to come by.

I was directed to what must have been a hallway perhaps 3 feet wide, and 10 feet long. One of those big-office “alleyways” to connect two sides of a floor. Strangely, one wall of this alleyway had a door- no, an entire office, looking out into the blueish grey wall 3 feet away. This was the guy.

I explained my business and delivered the USB drive. “The guy” wasn’t worried; in fact, he immediately laid back in his chair, hands folded behind his head, and let out a breath of self-satisfaction. “So you’re a developer, huh,” he asked.  “Let me ask you this: what you want out of life?” Before I could think to respond, he continued: “I mean, look at all this,” gesturing around his 8x8 foot office. “If you stay here at Comcast, all this could be yours too, someday.”

So there I was, on the 50-somethingth floor of the city’s tallest building, shrouded in storm clouds, sitting in a fluorescent-lit closet in a corporate office back alley. As the seconds ticked by, it became evident that this wasn’t a hilarious joke. At that moment, one thing was clear: I wasn’t sure what I wanted out of life, but I sure as hell didn’t want to be that guy.

Finding What I Wanted Out of Life

From that moment, I thought a lot about what I didn't want out of life. I knew that I loved coding, but after having picked up handfuls of Flash contracting jobs, I began to realize a trend. The more I created things for other people, my sense of autonomy diminished, the less individuality I had, and therefore, the less I enjoyed the act of coding. In a board meeting, one company referred to me as "the secret weapon." Another dubbed me the "the bullet," both of these things implying the same truth: when assigned a project, I would dissect it, refactor any nonsense, and over-deliver under time, and under budget.

That's all great, but I didn't want that. The problems I had with this type of heads-down work were the questions I had no authority to ask, such as:

• Why are we building this in the first place? Is it really worth this much budget, as opposed to a simpler and cheaper solution?
• Does anybody honestly believe that this feature will resonate with users? Imagine yourself using this app, except it wasn't your app. Is there any point of building this feature other than a stakeholder's personal need to have a sense of ownership over something?
• We have meetings every week about problem X. Why don't we consider building Y to solve this issue?

As I analyzed "what I wanted out of life," I began to notice other things happening around me. I was putting in 18+ hours a day of work attempting to save a final project for University, which happened to be a video game. Thanks to some administrative nightmare, 6 people of our 9-man team became virtually unreachable midway through the project (it's a long story). I found myself taking point and scheduling check-ins (standups?) with the remaining troops. Despite their limited coding experience, we found ways to play to our strengths. We had one man on audio and soundtrack, one guy on visuals, and me on... everything else.

I lost the better half of a year and a relationship to that project. It was miserable. Meanwhile, the other fully-staffed projects were doing fine; in fact, they were flourishing. It didn't matter that the other teams didn't deliver anything technically impressive, or in some cases, finished. The teams which did best were significantly rewarded for the idea they had, despite being virtually unchanged from day 1. What's more, those receiving the highest credit contributed nothing but the concept itself (typically stolen from a project at another university, mind you).

Nobody cared that I personally pushed the limits of web browsers at the time to create a multiplayer RPG. Nor should they, in retrospect: nobody had attempted to do this; thus, nobody had any barometer for the effort or complexity involved. That was Lesson 1: Nobody Who Matters Cares How Impressive Your Code Is.

Meanwhile, professors were euphorically celebrating projects they could understand: which were typically simple apps which leveraged social media somehow. Word on the street was that each of the "idea guys" got taken out for drinks in celebration of their genius. Lesson 2: Hard Work And Originality Does Not Equate to Success.

Our project got abysmal scores. Begrudgingly, we went along with an event to showcase all projects that year and set up a station where anybody could sit down and play. We had 4 computers running the app over a local network, and the crowd loved it. Despite being cast into a dark shadowy corner of the room, it turned out users knew what they wanted more than professors. Lesson 3: The World Has Too Much Clueless Leadership. If you're not careful, you could spend your entire life programming something that had no place in the world to begin with. 9/10 startups fail, which I think is a high success rate considering 9.999/10 ideas are abysmal.

How I Became A Product Manager

I didn't become a Product Manager because I was transferred, or promoted as an intern, or failed as a developer. I became a Product Manager by searching for Product Manager jobs out of college, and I landed it.

Everything I had learned from that final year of University taught me so many things that lead to a single conclusion: I am not happy in my career unless I am:

• Collaborating with intelligent people.
• Always having a say in defining what it is being built.
• Building something meaningful.

I became a Product Manager because I was born to be a Product Manager. I love to code, but there isn't a single job description that reads "code what you think is best for the company." In fact, if we were to translate most job descriptions, they'd probably be closer to "code the thing that will get the person above you a promotion." I couldn't bear to watch my hobby become something I hated, and I knew the world is filled with developers who live that reality daily. I wanted to help them.

I would challenge all organizations to ask PM candidates why they've chosen the path. If a candidate cannot articulate a purpose which is unselfish, or legitimately speaks to their interests, they should not be hired. End of story.

Transitioning to a technical lead role allows me to do some  of the things I set out to accomplish as a PM, but perhaps not as much as I'd like. The notion of switching back feels uneasy: the world has far too many Product Managers as it stands, regardless of how mediocre they may be. And let us not forget the "walled garden" effect: PMs can only become PMs because they know PMs. Shitty PMs hire more shitty PMs, and so on. I can say this from my personal experience interviewing at shitty companies I had no intention of joining: shitty PMs hate me. Misery loves company.

If I truly want to stick to what I love, a Principal Engineering role or equivalent feels like the next logical step for somebody like me to take. I can only hope the world's Product Management Hyenas can stay off Google Calendar and Slack for long enough to not to kill hope in the people I hope to help before then.