So, confession: I am relatively new to the Product Manager role.
I will also confess that when I first started in this role I was quite nervous. I had never worked in Product before (much less knew anything about engineering), yet as a junior PM I would be stepping up to “lead” a team of seasoned engineers.
How could I, with zero Product or technical experience, convince this crack team of code Ninjas that I had any credibility to guide us to KR victory?
After a little light reading, the answer came to me! And it’s actually quite simple: build a culture of leadership through fear and domination.
So, to those aspiring PMs out there reading this and experiencing the same “what-am-I-doing-I-am-way-out-of-league” crisis I describe, fear not! I’ve collected a list of all the best tactics I learned along the way, and hereby pass it along for you to keep in your proverbial toolbox (along with several Red Bulls, a stress ball, and at least five different colors of Post-its):
1. Do schedule lots of meetings, and spread them randomly throughout the day
You might read that engineering tasks are deeply contemplative and require longer stretches of uninterrupted time for one to absorb themselves in the problem before they can create an elegant solution, and as such meeting overload can be especially painful for engineers.
This makes sense conceptually, but just remember that meetings are where you can most effectively create the “fear” and “domination” so crucial to your future success. So while you may be tempted to listen to people like Mr. Graham, just remember that meeting time is also prime chest-pounding, table-upturning, fear-mongering time and ask yourself: “do you want more, or less” of that? I’d rather have more.
2. Do not ever give context into why a feature is important and the potential value it may bring.
Engineers will be curious about the “why” behind what they are working on. This type of curiosity is toxic. As the PM, you are to be unquestioned and indulging this type of questioning only makes you look weak.
Don’t forget: even though engineers may have significantly more experience than you and understand the inner workings of the product better than you ever will, you are the PM. Stand tall.
3. Do shoot down ideas from your teammates, even if they are good.
Similar to the point above, get in the habit of continually shooting down other people’s ideas, as it will motivate them to work harder for your approval, producing a higher volume of better ideas down the road.
I will confess I actually stole this tactic from a leadership hero of mine, George Bluth Sr. from Arrested Development, who not only built a successful real estate company but also forged strong international business relationships in the process.
4. Do not have patience for “leisure” activities
…such as lunch, ping-pong, or using the restroom. Staying on schedule is critical, and there’s no time during the day for any of the activities previously mentioned. One time I saw an engineer playing ping-pong and you know what I did? I lit that table on fire. Now guess how much time we lose to that silly pursuit? Answer: none. #dominated
Sure, giving people a chance to reset and move around may help them stay focused in the long run, or arrive at a new solution to the problem, and yes activities like ping-pong are proven to be good for you, and yes it’s an Olympic sport, and yes it helps build a positive and productive work “culture.”
But don’t lose focus here: you’re in the business of generating fear, so anything that can be construed as “fun” is simply counter-productive.
5. Do behave erratically
This is basic psychology, really.
Think about it: What’s scarier than a rabid raccoon? Nothing. How do rabid raccoons behave? Erratically.
6. Do obtain merge access to your company’s GitHub repo and then use it with reckless abandon.
Is one of your junior engineers waiting for the Lead to code review before they can merge? Easy time-saving solution: just merge it.
Sure, there may be a critical error in the new code that causes a system wide meltdown this time, but you know who won’t dilly-dally on code reviews next time? That’s right, the Lead engineer.
7. Do insist on tickets taking half as long to complete as your engineers estimate
Sure, it may be notoriously hard to estimate how long engineering tasks may take, but do not let this pitfall fool you. The best way to ensure your team delivers on (or ahead!) of schedule is to pile as much work into a single ticket and then insist on it being code complete in no more than 2 days.
Why two days? Very likely two days is the maximum amount of time available in the project plan you’ve dutifully laid out using a fancy tool like a Gantt Chart, and extending the time to completion will cause your new, beautifully formatted chart to look unbalanced and weird, which is aesthetically unpleasing. This alone is a good reason to doggedly adhere to such timelines.
As Lieutenant Colonel Danny McKnight says in Black Hawk Down “nothing takes five minutes.” Take the same approach with engineering asks and you can’t lose.
8. Do not ever credit engineers for the accomplishments of your team
Especially when presenting findings or announcing new features at a venue like your company all-hands. Sure, they may have actually built the feature that your young and untested mind actually produced (of course with no buy-in from the engineers themselves, see points 2 & 3 above), but you’re the PM. Stand up and take a bow.
You might be tempted to highlight their work (you may even suspect that your engineering teammates take extreme pride in the work that they do, especially if it’s proven valuable to the company as a whole) and that calling attention to it might even be motivating.
But if you do so you run the risk of them turning into a bunch of Divas (or Devos) that question your authority, and that you cannot afford. If this does start to happen, see point #5 above.
If by this point you haven’t arrived at the conclusion that I am joking, let me be clear: this was written in satire.
That said, my initial confessions were absolutely true: I am relatively new to being a PM, have no technical background, and was absolutely terrified by my lack of experience when I joined.
But throughout the last several quarters I’ve learned a tremendous amount, the majority of which came from simply listening to my engineering team and trying to understand their perspective and leverage their expertise.
So, what’s my actual advice to prospective PMs?
- Listen. Seems obvious, but you would be surprised how easy it is to miss key insights amidst all of the noise. As a PM you’ll be ingesting information from many different stakeholders (Sales, other PMs, clients, and users) and your job is to see the signal through the noise. Being a good listener is therefore the first skill to master.
- Read points #1 – #8, and then do the opposite.