What would the ideal learning environment look like for an early career PM? I think my experience was not far from it. I started my PM career in 2007 at a Silicon Valley tech company called Intuit. They had already established a strong definition of the PM role and culture at a time when this role was still very much being figured out across the Valley. But what was unique is that I joined them as a member of a PM Leadership program that they offered at the time. The program optimized for development; I worked with multiple experienced Product leaders during my first few years, across a range of products. This gave me exposure to different domains, teams, and business challenges.

I learned a lot from these great managers and mentors in my early Product career. So in this second half of a two-part piece (see part 1 here) I will pay it forward by sharing some of the learned behaviors that contributed to much of my early growth as a PM.

Develop skills as a generalist

PMs are the connection point between a variety of specialized roles which are all required to deliver a product.

When you work with people in other functions, find time to better understand their world. Ask your engineer what parts of this feature are the most complex to build and why. Ask your designer about the tradeoffs they made for their design and why they chose this approach. Take some customer support tickets. Have your Ops team walk you through their workflow.

Even if these activities aren't immediately relevant to your task at hand, they will be a valuable investment. Over time you'll find yourself able to work more effectively with your teammates because you better understand their context. Also, you'll find more cases when you can manage without specialized support instead of being blocked. I was fortunate to have opportunities to work closely with talented User Researchers during my early PM career at Intuit. I learned how to design research activities, how to ask questions in the right way to get the least-biased answers, and techniques for testing product ideas. I was far from an expert, but when I found myself working at a start-up without any User Researchers, I was able to use these skills to better inform my product decisions.

Another benefit of these investments is that you will build a more positive working relationship with your colleagues. You will develop more empathy for them, and they, in turn, will develop more trust with you.

Habitually collect teammate feedback

It's not enough to do quality Product work; a PM also needs to build strong positive partnerships with their cross-functional team members. And this only becomes more true later in a PM's career.

A great way to improve your partnerships while also growing your skills is to create an early habit of feedback collection. Habits are built by repeated behaviors, so use project completion milestones as a recurring opportunity to reflect with your teammates: even if the project went well.

There is a lot to be said about the art of feedback collection, so this topic is best left for a future post to truly explore. But there are a few suggestions that should be quickly shared:

First, know that people are often uncomfortable sharing honest feedback. Find the right environment to draw this out. If I anticipate a sensitive topic, I will usually have a 1x1 and either go for a walk with the person or discuss it over a beer at the end of the day. Don't fall into the trap of believing that the feedback is all being shared just because there is a forum to do so. An unanswered request for feedback or an uneventful Sprint Retrospective could just as much indicate a problem, depending on the context.

If you can get good insights from someone by asking "How can I improve?", then you're in luck. But for most feedback-givers, it's difficult to share professional criticism directly with someone. You can more easily draw this out by collecting feedback on the process instead of your actions. Here are the questions I'll typically ask my teammates at the end of projects:

1. What went well?
2. What didn't go well?
3. What would you hope for next time?

Just remember to connect the dots between the process mistakes that you hear and the professional mistakes that may have caused them.