Below you will find learning resources to learn about product management, organized by topic, as well as my thoughts on how to onboard to a new team as a product manager.
A reader asked for learning resources I found useful when starting as a product manager without a computer science background. Below is a list of learning resources that I found helpful and rewarding as a new product manager. Most of the online resources are free.
Product Management
It wasn’t until around 2018 that I found courses focused specifically on Product Management that I thought were worth it.
- [web courses] Reforge: I’d highly recommend Product Managers of all levels to consider their offering. I completed their Product Leadership course 8 years into my PM career and found it very helpful.
General Management
There are many aspects of product management that are similar to general management.
- [web] Ian McAllister’s Quora answers. Ian McAllister shares a lot of great learnings from his 12+ years in Manager and Director roles at Amazon, Microsoft, and Airbnb.
- [web] First Round Review – Product articles. Possibly the best source of consistently high-quality content.
- [book] Creativity, Inc.*
- [book] A More Beautiful Question*.
Design
Apple’s success has been largely attributed to it’s strong focus on design. Great UI and UX strongly influence the user’s reaction to the product, regardless of its complexity or how impressive are its features. It is critical in product management to ensure that your products are designed well.
A few resources to learn about design from a product management perspective:
- [book] Inspired: How To Create Products Customers Love*.
- [book] The Inmates Are Running the Asylum*.
- [web] First Round Review – Design articles
Agile
A big part of product management is ensuring that work is properly scoped and scheduled.
Technical knowledge
Ian McAllister, and Amazon GM, very succinctly pointed out is that not being technical is never an advantage in product management. That is, you may do well in the role, but understanding the technical side of how products are built is advantageous.
I was advised to learn to script for data analysis, how to scale products, what levers engineers can use to make products faster, determining the right database structure/schema, among others.
Here are a few resources that I’ve used in the past to learn about more technical topics:
- [online course] Dash: General Assembly. this interactive online course helped me understand quickly how to bring together HTML, CSS, and basic JavaScript.
- [book] JavaScript & jQuery: The Missing Manual*. this book was fundamental to get me more comfortable with JavaScript & jQuery.
- [online course] CodeCademy web development courses HTML, CSS, JavaScript. I also learned some Python.
- [online course] Harvard CS50 on EdX. I completed roughly half of the course and nothing has been more helpful for me to understand the fundamentals of Computer Science. The course is taught on C and although time intensive it was rewarding.
- [book] The Datacenter as a Computer [free pdf]: on understanding infrastructure components.
Other topics that I’ve read up on, but don’t have specific resources to recommend right now, would be:
- Analytics: how tracking works, how data is processed, etc.
Entrepreneurship & Product Strategy
- [online course] Entrepreneurship: Coursera Specialization by Wharton. Product management is a highly entrepreneurial activity. I found this course to be helpful at general product strategy.
- [book] Zero to One*.
* Note: I use some affiliate links in this post, marked with an asterisk. If you click through and purchase products I earn a small referral fee at no cost to you.
Google PM Orientation
Some advice I got during the Google Product Management orientation.
- Be well-connected with TLM (Technical Lead / Manager, or eng manager)
- Data: know your numbers
- Uplevel: look 3-years ahead
- Your calendar should reflect your priorities
- Learn about ML/AI
- Launch: communicate early and often
- Stay in touch
- Focus: what does success look like for your product?
- Good PM: inquisitive, always a glue, thought of ideas but don’t force, vision but sought to understand, clearly articulated why, draw out the best of people.
- Conflict resolution: listen, use data, vision, big picture.
- Leadership is 27% IQ vs 53% EQ.
Onboarding as PM on a team
Your first few months as a PM can be quite unsettling. You are brand new to the team, want to contribute, may have a lot of relevant experience to bring to the table, yet have little to no knowledge or context about your new team and product area. There are significant gaps in your understanding that will prevent you from making a significant contribution.
Focus on learning by picking up many small initiatives, assimilating to your team’s processes and tools, asking your co-workers for braindumps, digging deep into the why behind what you learn, and observing your users. After a few weeks of consistently doing this, you’ll be ready to take on more significant initiatives and will be much more effective at helping your team.
Communicate what others should expect during your learning phase
As a new PM to an existing product, your focus must be on learning. Even when there is an improvement that seems evident to you, a product idea or process tweak, abstain from contributing too hastily. Consider that:
- You lack context. Your new colleagues have been working on the product area for months, maybe years. They have tried many ideas that failed, talked to many customers, and learned a lot in the process. Try to gain that context quickly.
- You have zero reputation. You can only go far if your team cares about what you have to say. You can quickly tarnish your reputation if you babble ideas or decisions before thoughtfully thinking through problems and considering all aspects of a problem.
So, focus on learning.
Pick up a few small initiatives
Dive in and pick up a small, non-critical project to work on while your team continues executing on their priorities. It doesn’t matter how uninspiring the project might be; what matters is that it is an initiative with the various phases that a typical project will go through – writing a PRD, going through design, practicing iteration, executing, and shipping a project.
Your goal is not to amaze anyone, but rather to maximize learning by getting through a full cycle of contribution. By doing this, you will learn many of the quirks of working with your new team and figure out tactical ways to be more productive.
- What level of detail works well for your team in your PRDs?
- Who should you consult in the process of designing a solution?
- How do you communicate cross-team dependencies or impact on other teams?
- How do you break down your requirements into tactical work items that your team can execute? Where do you file work tickets or bugs?
- Will you have help from other teams (design, eng, user research, etc.)? If so, how much?
- Do you need to get approvals or reviews by other teams? Which ones?
- How often should you get your manager’s input while working through an initiative?
Try to maximize the number of times you go through this cycle in your first few months by picking many small initiatives and owning them end to end. It will help you fill the gaps in your know-how of working with your team, and will be of great help when you pick up more significant projects.
As you go through the initiatives, ask why things are the way they are but don’t try to change processes yet. What you’re looking for is opportunities to learn what’s useful and to tune your habits to make a more significant contribution within your team’s established processes.
Tweak your habits to match your team’s workflow
Processes need to be just good enough to allow the team to work effectively. Constantly tweaking processes to improve them is often more distracting than it is worth. As you onboard, focus on matching your team’s process and work within them for the first few months, before you try to bring new workflows or tools for the team to use.
I had a new manager once join from a larger company. Within the first week he told me “we must get rid of these spreadsheets” referring to the team’s use of spreadsheets to manage the feature backlog. A month later, he realized it was a simple and effective way to manage the backlog and backtracked on the statement.
Get to know your team
You will need a lot of help over the coming months and years from the people you are meeting now. Meet them as people. Try to learn about their personalities, what they are interested in, what they like, and what they dislike about their job. Knowing your teammates’ likes and dislikes will help you when planning work for your team, something PMs do regularly throughout the year.
I acknowledge upfront my ignorance when I meed new team members, but offer to help as possible. “I don’t know anything right now, but if there’s something that you think I can be helpful on, just let me know.” It’s a simple statement recognizing that you are unlikely to be helpful but still showing your willingness to step up and assist.
You are not here to issue commands or speak of visions for the team to execute. You’re here to collaborate with your team to come up with a direction that will make the product excellent. You should be very involved and willing to help your team’s life less complicated. Make it clear to them that you’re here to do that.
Ask your coworkers for braindumps
A previous manager and I called our knowledge transfer sessions braindumps; these were sessions where she would share a lot of information and context. I’d soak all this information up and ask clarifying questions. Many of these sessions would start with a particular topic or area, but as we dug into an issue, we’d make a note of other issues that came up, and we needed to discuss further. These sessions covered a lot of ground, such as:
- How does the product work?
- How does a product initiative fit within the overall product and company strategy?
- What are the known issues with a given feature?
- Why hasn’t a critical issue been fixed?
- What are known feature requests or solutions that the team hasn’t implemented, and why?
- Why do parts of the product feel so disjointed?
- What did the team try to do and succeeded? How did they start down that path?
- Who are the players involved in making your product area a success?
Keep these sessions flexible. They are best in person, but often we’d do these asynchronously by using a Google Doc. My manager would type up a bunch of thoughts about an area or topic I needed context around. We’d then discuss.
During these braindump discussions, you will have many ideas, thoughts, and potential solutions. Don’t jump into looking for answers. Remain focused on surfacing issues and tidbits of knowledge. What you’re after is building a foundation of knowledge around the team and product. You must take the time to organize all this new information in a way that’s useful to you. As you do, ask why until you’ve hit on a point that is easily understandable and actionable.
Your coworkers will gravitate towards topics that have been important in the past 6-12 months since they are top of mind. This will make your learning process more focused than trying to read every document sent your way.
Observe your users
Get first-hand exposure to your users. You can learn a lot from talking to your coworkers. But, ultimately, your goal is to build a product for your users. Deeply empathize with those users. Observe them. Talk to them. Find ways to watch them in action. Listen in on support or sales calls. Read support tickets. The more you can identify with your users and understand their real goals and needs, the better of a product that you’ll be able to build.
Last Updated on March 12, 2023 by Omar Eduardo
Leave a Reply