Lessons Learned from a Product Manager with a Non-traditional Path

Published in POC in Tech

Product Management is its own art form- equally an art and science. I often see the PM role lumped into other people management roles.

It assumes PM’ery is easy because it is “people management” but it vastly underrates and misunderstands the profession. Although each profession has its own version of “hard”, the PM role is a mix of many roles in one.

Here are 4 of the most valuable lessons I’ve learned going from a Anthropology, Biology, Chem new grad to Technical PM role:

1. Communication is the building block of collaboration: Written and spoken communication are equally important. Clear, concise, and effective communication is essential for success. As a PM you are often the go-to person for questions about your product, and being able to communicate quickly to customers and field representatives, the direction, strategy, and functionality of your product means you must always be on your toes. You must also be a good storyteller to communicate data and a good documenter in the form of proposals or Jiras. You must also be a good producer of visual experiences to communicate via presentation decks.
2. Prioritization- knowing what to work on first is integral to spending your/your team’s energy in the right places: With so many tasks and projects on the go, it’s essential to prioritize effectively or you can get lost doing work just for the sake of it. I’ve learned to be selective and assess which tasks are most critical and focus on those first, while also considering the long-term impact of each project. There is a whole science to this but ultimately this is a mixture of PM gut feeling informed by research and customer feedback to derive your best estimation of doing work that will matter most first.
3. Organization/ Structure- having a single source of truth to track your work is key. Without it, the cumulative effects of not having any well-written documentation and long-term issues not tracked, can be a time bomb waiting to happen, slowing down the team and making it hard for newcomers to the team/ project to learn the job and pitch in quickly, reducing your ROI as a team as a whole. Documenting repeatable processes also help new stakeholders know how to work with you. I love how Red Hat has agile coaches and scrum meetings to stay organized, as an organization.
4. Technical Skills: Being able to understand the high-level architecture of your product along with the core tech stack, answer engineers' questions, co-consult customers on their use cases on your product, and communicate the direction of what to build while having an understanding of what’s under the hood. This is the hardest part of the job as this is a solo journey where there is no specific course or manual for understanding all you need to know about your product, but the closest you can get to it is to read through your documentation, Git hub page and play with your product. I do this by stepping into the developer’s POV - pushing/pulling images etc., I set up alerts to git hub merges, and always asking questions when I don’t understand and repeating it back in my own words to make sure I understood. I continue to invest in this area as you can never stop learning, it is even more challenging to do so in a remote-only work setting but not impossible, especially if you recruit mentors and allies to support your cause. It’s up to you to find them.

If you had a nontraditional path to tech you have to be ok with working 3 times as hard to get up to speed, but this does not make you any less valuable. In fact, it is an asset in how we see the bigger picture, think from a business, user centirc POV and even without understanding the entire technical iceberg we can see the tip of it and with that view, contribute fresh ideas, tactics, to engineering/product discussions influencing our strategical direction as a product for the better. Also, customers don’t always have the background/insider knowledge your team/company does, therefore, having someone of a different school of thought, who can cross-check to weed out biases or assumptions in how you present/sell your product to customers is vital.

The elitist bro mentality in tech that you are only valuable according to what tech jargon or concept you know, needs to go. Knowledge when kept to oneself for the sake of feeling superior is useless. You don’t create an impact by keeping knowledge to yourself. Luckily, I have encountered many people of all seniority levels willing to share knowledge, without judgment, at Red Hat.

We are all just one google search, one call, one course, one project away from gaining more basic technical knowledge every day. Don’t ever think you can’t understand something until you try, multiple different ways until it sticks.
Even if no one tells you: We need more diverse perspectives and schools of thought in tech.

Overall, my experiences as an Associate Product Manager have taught me valuable lessons that will help me to grow and contribute to the success of my team and company at large. I’m excited to continue learning and applying these lessons in the future in the form of future product releases and community initiatives. Stay tuned.

Let me know if I should do a part 2 to this or elaborate on some points. My aim was to keep this article concise. Thanks for reading 🥳