Honing my skills as a product manager

How I found my groove in product management

👋🏻 Helen here with our weekly installment talking about career in tech today. If you are interested in more content on career in product management, check out Adam’s Finding Purpose in Tech Careers: The Explorer, the Journeyman, and the Healer, my thoughts on Building Critical Habits at Work and Adam’s The People Angle: A Lens on Career Advice & Job Seeking in Tech.

As always, we’d appreciate you spreading the word and sharing this newsletter with your network.

I have now worked in tech for 11+ years and in product management for 7+ years - and as a career switcher with a non-technical background (read my post on 3 careers by mid-30s), I still periodically wonder if someone will come to tap me on my shoulder and say “You don’t belong here. You don’t actually know the first thing about working on product in tech.” And they’ll show me the door.

This begs the question - what does it take to be successful in the discipline of Product Management and how much of it is art vs. science?

Over the years, I have seen many types of product managers but overall, the successful ones have some combination of the following three skillsets: communication, customer-first thinking, and tech chops - and while no one I have met is excellent at all three all the time, they definitely excel in at least one of these areas consistently.

I initially went into Product Management because I knew I could offer something in the communication bucket, was excited to learn and lean into experimenting with user needs and potential solutions, and I figured I would muddle through and learn the tech part eventually (for context, academically, I have a BA in Politics Science and an MBA). I also really wanted to make decisions about what we build instead of being confined to compelling product storytelling.

My assumptions have turned out to be mostly correct but of course, the journey has been a lot more complicated and colorful. I’ve had to work and improve in every “skillset” over the years to earn the right to “decide” on what to build. Having said that, I am more in the flow in my career as a product manager than I have been in any of my previous ones. So what has it been like - where was my starting line and where did end up is the focus of this post.

📢 The communicator - be precise, concise, and accurate

As I switched to the PM discipline, I knew that I was good at asking clarifying questions and stating back what I heard. I also struggled with how to add value as a Senior Product Manager dropped into the deep end of the pool (many tried to convince me to start at a lower level, so it would be a safer transition, but I worked hard to become a Senior Product Marketing Manager and was not interested in what I perceived to be a step back).

One way in which I found I could contribute is to immediately take notes in meetings and share them out. Even though this was the one thing that I was sure I knew I was good at doing, I saw quickly that I needed to make some critical tweaks for this skill to truly transfer to tech. I needed to learn how to be very clear on what the next steps were, who was on point and by when. I remember documenting a requirement that two things needed to happen at the same time in product and my dev counterpart corrected me that there is no such thing because something always has to happen first, then second. Precision mattered a lot more in this new world than it did before.

For me, taking notes really helped me start out in the PM role because it enabled me to:

A) Be helpful since many people don’t actually like to do this

B) Get up to speed about what’s going on - if I got a concept wrong or said that someone committed to doing X and I was wrong, there was no shortage of people who jumped to correct me

C) Practice and hone my communication skills - it’s not just about taking notes, it’s also about synthesizing key decisions, simplifying key points and identifying next concrete steps

My first PM manager told me “We don’t write code, we don’t design, so usually the point of a meeting is to clarify what/why, next steps, etc. So if you go to meetings and walk out with no clear next steps, accountabilities, and documentation, the meeting might as well have not happened.”

A quick aside on being a woman and a notetaker - there are many times that women are taken for granted and are expected to do emotional labor for the team such as organizing team morale activities and ensuring there is food during “lunch and learns”. To that end, I am strategic about when I offer to take notes - I do it mainly when it would be helpful for my professional development.

Over the years, I have evolved my communication style from what worked in politics and marketing to what works in tech. And while communication in tech is less aspirational (aka fluffy) than it was in my previous professional lives, one key aspect remains true. Always lead with the context - whether it is one framing slide, an intro paragraph or a verbal sentence or two to remind people on what you here to talk about and why.

Figure out the “what” and aggregate insights to form a hypothesis

I pride myself on being an empathetic person who understands what moves people. So I’ve always loved talking to customers and asking them open-ended and probing questions. When I became a PM, I was so excited to go meet with customers and discuss their pain points and desired solutions. However, it turned out to be a lot harder than I thought to convert those insights into actionable product requirements. I knew (and have read plenty of PM books) that taking a customer pain point and immediately thinking through how to solve it was not the right approach. I theoretically also knew that the first problem that a customer outlines is usually not the actual problem.

So I have started practicing the 5 Why’s (keep asking the why question until you get to the root of the pain point) approach - both with customers as well as with fellow PMs, researchers and designers. It was a shift that led me to be more detail-oriented and concise on what problem I was trying to solve.

As I continued going to customer meetings, I used to send notes from each individual encounter outlining what I learned about jobs to be done from the customer’s point of view. One day, my manager pulled me aside and recommended that my focus should be to aggregate feedback across multiple customers, find the trends and then publish. In the absence of that, I was not thinking about solutions that scale but a wishlist of a single customer.

Since then I have learned how to organize findings across multiple customer interviews, and if I do send any kind of an aggregate summary, it usually is backed by a table like this:

🔬 The technical PM - Be curious about the how 

While my strength is in communication and the “what” of the problem we are trying to solve, from early on in my PM career, I had a goal to not be scared of “the how.”

To help with that, in my first product job, my manager held me accountable to create and present a functional diagram of how my feature was going to work end to end. This was when I learned that the core in a technical deliverable was also communication - as many developers I talked to knew exactly how their component worked in addition to the one it was connected to but not really more broadly than that. They would point me to other people to talk to which enabled me to learn how to stitch together a full picture.

I remember doing a dry run with the said first manager, where I used a lot of fancy technical jargon to explain what was happening across the various pieces of code (I was quite proud of myself for memorizing how many times a call was made to some service). I still remember the conversation we had when he stopped me 5 minutes in:

Manager: Helen, why are you using technical “mumbo jumbo” to describe your feature?

Me: I am trying to sound like a technical PM! Isn’t this what I am supposed to be now?

Manager: If I needed another technical PM, I certainly wouldn’t have hired you. I need you to explain the scenario in laymen's terms that you understand and explain how this experience is powered. Please, just be yourself. That’s why you here.

In addition to this being a powerful moment of allyship, it made me realize that if can understand hard concepts and then explain/document them in accessible ways - both to a technical and a non-technical audience - that is a huge value add.

Over the years, I have also learned to be wary of people who speak in technical terms that I don’t get and thus I keep asking clarifying questions such as “how does this action impact the end-user experience” until I get to an answer that I can understand.

I currently run a monthly meeting with a couple of key developers in the organization where we document end to end architecture of our product. I get to ask a bunch of questions and the end result will be a diagram that will serve not just developers, but also PMs and Designers so they can better understand the product from a technical lens.

One does not need a degree in computer science or knowledge of how to code to ask the right questions. But curiosity, humility, and patience have gotten me the respect of my dev counterparts and the confidence to stand on my own two feet in the “how” conversations.

Summing it all up

Upon years of reflection, I know I am most effective and most in my flow when I play the role of a communicator. As such, I am uniquely positioned to drive complex problems that need partner alignment and consensus. When I started my PM journey, that’s the skill I focused on and up-leveled to work for me in the world of product.

Secondly, I worked on truly understanding the customer and the relevant jobs to be done which resulted in building product judgment. The work for me here has been asking a lot of why questions and not stopping until I was satisfied with the root cause of the problem we are trying to solve. In product, I have also learned that understanding the root cause is just the beginning of the journey to a solution. After deep understanding, come hypotheses, experiments, and iterations.

My third focus has been on “the how.” For every project I am a part of, I hold myself accountable to understand how it works and to be able to hold my own in a conversation with an engineering manager.

I am currently on my 5th(ish) product management job in my career. Every time I have made the leap within product management - whether it was to a new product or to become a people manager - I have thought about my unique strengths, what the role requires and the alignment between the two. Having the three skillsets/buckets of PM has helped me have a more thoughtful conversation with myself and my mentors about the right next steps for me to keep growing.