The Heady 8: Product Manager Edition

The PM is what I like to think of as the point guard. I have the ball (product) in my hands and must be aware of everything that happens on the court while ensuring that everyone on the team understands the goal.

Some people think we’re glorified secretaries: scheduling meetings and writing things down to relay to others. Others think we just tell everyone else what to do and that we don’t really have a skillset of our own.

Our role is a bit more complex than that. I am a client-facing PM, so I work with them daily to identify and solve issues that their user base are facing, and to create a great user experience overall. Once we have a high-level understanding of how to enhance the product, it’s on me to create and organize clear requirements for my internal team of designers, developers, and QA.

So yes, I am a secretary and also, I tell people what to do.

There is a definition I really like, which is great: ‘A PM is the brain of an engineer, the heart of a designer, and the speech of a diplomat.’ This is my goal of being a PM. Day to day, my job is to define the project roadmap and strategy, research customer needs, work on various facets of product execution, and ensure that the team will ship great digital products.

...Constantly having a lengthy mental to-do list at all times. Most times, tasks are required in such a short amount of time that I don’t have time to physically write them down. Because I manage designers, developers, and QA while also maintaining a roadmap of expectations with my client, I have many asks (sic) from my internal team that constantly arise during projects. I have to prioritize and fulfill all of these asks, because if any team member is blocked for too long, it could significantly affect the roadmap.

For me, [it’s] learning how to strike the balance between communicating what is absolutely achievable vs what is more aspirational. In Product Management there is nuance to the way you deliver information. A new feature request comes in two months before launch on an already tight timeline. The PMs job is to gather the information and data to support the best path forward, which often means serving the client’s desire to stick to timeline, over the emergent desire to add functionality. So a ‘not now’ to the new feature sounds more like: ‘Given resource and time constraints, the best path forward is for this feature to be a fast-follow to launch.’

Seeing products in production (live and available to users) is the most rewarding part of a Product Manager’s job and the jobs of most of the app development team. Seeing an app in an app store is very gratifying, and the insights gained from post-release monitoring can either prove the value of work already done, and/or point toward valuable future work.

The two most rewarding parts of work as a PM for me are

1. Working with diverse skill sets like designers, devs, department leads, and clients, because then I get to have a peek into each of their worlds and pick up skills/insights into how they work and fit together with other teams. And...
2. Working on projects around subject matter about which I know little to nothing so that I can become a novice expert over the course of the project.

Shipping a product that has positive impacts on the user’s life. Product Management is all about solving problems for people and making their lives better. Being able to drive a group of talented team members to achieve this goal is the best part of being a PM. This is my ultimate motivation.

I always give them a ‘this or that?’ question. For example, I let them know that we can still hit the release date BUT we might need to reconcile a few items. So the question becomes "would you prefer to hit your release date knowing there might be future items to address, or would you prefer all items are addressed prior to launch?"

My approach is simple: transparency, transparency, transparency. Delays and increased scope are often unavoidable, but keeping the client close to daily progress helps us share ownership of the timeline.

I immediately check Slack when I wake up to make sure there aren’t any developers that are blocked and could be unblocked by something I can provide. Usually, I do wake up to questions/requests.

The beginning of a Heady Product Manager’s day is always the most intense, as this is the best opportunity of working directly with resources in Eastern-Hemisphere time zones (we have them in places like India, Spain and Ukraine).

Given the international team set up at Heady, I hit the ground running each day. The day usually starts with checking important Slacks and emails, then I move to running stand up(s) and project-specific meetings, then end the morning with follow up communications with the client for the devs to get a head start on for the next day.

I think it’s important to remember I’m no one’s boss. The boss/who we all answer to is several things: the client, the timeline, the users, even the product itself. And I often find the devs and designers are my boss in various ways, because they are the experts and should heavily inform the best choice or process for getting the work done. So to “enforce,” I defer to other disciplines’ expertise and the data available to arrive at a logical decision point. Usually when presented with that information, other team members readily understand the chosen path.

But also, being kind and being human always helps with collaboration. I try to get to know them personally and share things about myself. And I try to let people know when I don’t know something, so that when it happens for them they aren’t afraid to ask for help.

My approach is to influence without authority. To develop my knowledge and skills so that I can understand the subject matter, and so that my audiences know what I know. To build trust with the team and understand their personal and professional goals, so that they will be more inclined to listen to me and follow my directions.

The perfect gift for a Product Manager is more time. When I hear of resources I can borrow from other projects that have downtime, I am extremely grateful, even if the agreed-upon timeline isn’t in particular danger. It’s always good to launch minimal viable products as soon as it’s safe and possible. Also, alcohol makes a good gift for those who partake, because switching gears from a very active day of problem solving to a personal evening is often a challenge.

Get me a gift that can help alleviate my stress. Product management is a stressful field of work!

[Get us a] meditation tool. The day-to-day can be hectic, and the workload can be stressful. It would allow PMs to take time to ground themselves, and to come back with a refreshed mind to be more focused and productive.

‘Master of Questions’ sounds esoteric, but it reflects that a Product Manager is the one to find/provide the answer to anyone’s questions, from the correct color of a button to the risk that a release date might move.

‘Director of Organizing Everyone Else’s Work.’

‘Can-of-Worms Opener.’ The can was always going to be opened anyway, so might as well deal with the worms now before it’s too late.

‘Master of Problem Solving.’ Our job is to constantly identify the problem and find a solution.

I never could settle on a single thing I wanted to be when I grew up. Working in science was interesting. I was a teacher for a short stint. I also studied public health. But all of those career paths were very prescribed, with little room for learning new things or being exposed to new ideas.

Product management attracted me because I could create while still being technical and logical; I could meet and work with people with skill sets and perspectives different from my own. I could learn the intricacies of what a client was passionate about enough to build a digital solution for it. Being a PM makes it so I don’t have to choose.

Miscellaneous problem solving is one of my key skills, and I also realized that no other non-technical role involves as much mystery and intrigue as product management. The discipline is also more of an art. One can’t learn to be a good Product Manager from a book, but on the other hand, there is always more to learn in fun hands-on ways.

I initially wanted to be a PM because I graduated from college with a Computer Science degree and realized that I hated coding. I looked up online what I could do with that degree that didn’t involve coding, found the job description for Product Manager and thought, ‘easy enough.’ It turns out I was wrong, and being a Product Manager regularly makes you want to cry yourself to sleep at night due to stress of release deadlines, which are made worse by the fact that you’re the villain if anything goes wrong. However, I came to like the job due to the interactions I get with team members from other departments (like designers, QA, and devs), the wonderful warm culture at Heady, and for the ability to be seen as a partner by my clients. They truly see me as an extension of their own team.

TL;DR, I like organizing work for others, I like leading a team towards a goal, and I like being a thought partner.

It turns out that me hating coding was a blessing in disguise.