A Decade of Product Management: First Advice
Looking back on the questions I asked experienced PMs, and how I’d answer them today.
2022 is my tenth year of being a Product Manager. In this series, I’ll share what I’ve learned, the highs and the lows of this unique and challenging role in the software industry.
Ten years ago, in 2012, I was very nervous to start my new product management role in an ad tech start-up.
Looking back, the conditions for making that change seem almost ideal. In 2009, I founded, then led, the account management team. I knew the customers as well as all of our two dozen engineers and had collaborated with all of them before. But even with that knowledge and political capital, I was scared to look stupid or mess things up.
I needed advice, so I turned to my network and found a few experienced PMs to ask for their takes on how to do this new role well and where it might lead. Most of those conversations were over email, and when I went idly looking a couple of weeks ago, they were right where I’d left them: in my Gmail archive.
Here’s what I asked, the answers I got, and how I would answer these questions myself today, ten years later. Every so often I still worry about looking stupid or messing things up, but I’ve mostly come to terms with it.
Q. What makes you a successful PM? How do companies evaluate you?
Why I asked
I had no idea and, being only the second product manager in the company I didn’t have any point of reference.
The answers I got
- Ship things
- Have a clear vision you can articulate and resonates with people
- You’re a mini CEO
- Consistently show results
- Ensure people enjoy working on projects with you
How I’d answer this question today
Fundamentally, product managers are there to build things that customers need, which should ultimately mean you’re helping the company to grow. Most companies have a culture of rewarding shipping new products and features with your name on them, and that is important.
However, a sign of a well-run product organization is that they also reward the impact of what you deliver to customers. The first is the impact that your work had on customer satisfaction and/or growth/revenue. The second is that you are a force multiplier who is creating clarity and enthusiasm around customer challenges and what you’re building to address them. These two things require a lot of other skills to pull off successfully that will grow your career in the long run.
I’ve never been too enamored with the “mini CEO” philosophy — one of the most important elements of being a PM is leading with influence over authority, which is not a requirement for a CEO. Unfortunately, this is also interpreted as “you should be like Steve Jobs” by people who forget how poorly he managed his team and stakeholders. Not the person to emulate (that might be another post).
Q. I don’t come from a technical background…I know clients and the user side of the product well, but not a lot about how it’s built. Any tips on working with the engineering team, and learning enough about the tech to have a general understanding of what’s involved in making changes?
Why I asked
The most intimidating thing about the job change was feeling like I had to get buy-in from a group of people whose job I didn’t fully understand and seemed extremely inaccessible and complicated.
The answers I got:
- Learn something about how to code to make sure engineers can’t “bullsh*t you”.
- Be clear about what the priority is from your point of view (e.g. we really need to think this through and future proof vs it’s ok to move fast and have a bunch of bugs).
- Don’t mix up technical terms, you may not need to know much about them, but you may need to look like you do.
- Think about why engineering should trust you and make sure you build that trust with them.
How I’d answer this question today
You don’t have to be super technical or get deep into the code to build a great relationship with your engineering team. As with most relationships, I think it really comes down to trust and respect.
Trust in my experience is rooted in the clarity and focus you can provide. It means you will do everything in your power to ensure that the team is working on the right things at the right time for the right customer and that direction is understood and supported up the chain. It’s also about making your requirements clear from a product and user perspective and being able to say no to random requests from other teams and customers when they don’t make sense, even if they are very loud and would be cool to do. Use data.
Respect is about valuing engineering time and expertise via empathy. Take time to understand the processes, pressures, and incentives your engineering team is experiencing — they are almost always related to yours but not the same. When they bring up a concern or question, listen, acknowledge and do your best to answer. Take time to understand the tech at a high level and ask questions. Never dismiss concerns about tech debt or things that would make the team more productive. Acknowledge hard work and great solutions. Stay humble.
I’m pretty confident no one has tried to “bullsh*t” me. That was probably the worst advice I got. I’ve never had a reason to be that cynical about anyone’s motives, and I try not to guess.
This isn’t exhaustive or anything mystical, and it can still be really challenging to get right (I’m still working on it). One thing that has surprised me over the last decade has been how much I love working with engineering and how little my not being familiar with specific technologies or the details has really mattered.
Learning a programming language and building some small apps helped me to both empathize with and understand engineering. I wrote about that experience in this post about becoming “technical”. Later this year, I’m launching a book that’s the explanation of high-level software concepts I wish I’d had when I become a PM.
Q. What are the potential career paths for PMs, as individual contributors or managers? Do you see a lot of people going into different areas, or staying in the field?
Why I asked
The path I had been focused on led to more senior client service and operations roles with relatively large teams, while I had no idea how product management careers progressed.
The answers I got
- CEO eventually, maybe?
- Most people stay in product and in individual contributor roles for a while
- Getting into product at the best/hottest/most prestigious companies is competitive, and it stays that way (including from engineers wanting to become PMs)
- Management roles are scarce and also competitive
How I’d answer this question today
This was probably the set of answers that are most aligned with how I’d answer now. If anything, I think the field is even more competitive in 2022. There are a lot more content about product management, a lot more frameworks, more certifications, and programs. And a LOT of talented folks.
The current CEOs of Alphabet and Microsoft are former PMs, and start-up CEOs (many ex-PMs) act as the first product person. I’d add that Chief Product Officer or (S/E)VP of Product are great aspirational goals if you want to manage people. I’m hopeful that more companies create exciting career paths for senior individual product contributors, similar to a principal or distinguished engineer — while great PMs are all leaders, managing people isn’t something you should have to do to grow.
A post that’s been on my to-do list for ages is PM manager vs IC PM — maybe 2022 will be the year I get that written.
Thanks for reading, and stay tuned for the next part of this series in February.
Any topics you want to hear about? Leave your suggestions in the comments.
