What to Study as a PM — The 4 Pillars (and roof) of Product Management Knowledge

Special thanks to co-editors Bo Peng, Kaitlyn Yong, and Kaivalya Gandhi.

What should an intern or new full time product manager know?

How does one build their product management skills?

The purpose of this article is to answer these questions via a framework I like to call The 4 Pillars. This article is intended for students who already know the general definition of what a “product manager” is, and aims to map out the general knowledge areas when breaking into the PM space. These tips are targeted towards PM jobs in companies with software products.

I’m Jerry, a University of Waterloo Systems Design Engineering student who is passionate about product management. I’ve held Product Management / Program Management (PM) positions at SAP, Flipp, and Microsoft, and will be continuing my career as a PM intern at Yelp this summer (2018). With the help of Product Vision Club, I hope to shed some light on entering the PM industry!

To jump right in, I like to describe the PM space as 4 large pillars of knowledge:

1. Software

2. Design

3. Data

4. Business

There are also a set of extremely beneficial Soft Skills to develop, which I like to call the Roof, since it spans across all pillars and all PM jobs.

With that said, you might’ve heard by now that “every PM job is different”. While that is true, each will contain various combinations and proficiencies of the 4 pillars, and thus the amount of effort you take to dive into each pillar will depend on the company, the job, and your interests. While PMs specialize in having a “breadth” of knowledge, many great PMs are also deeply technical in a specific pillar. My suggestion is to try and learn as widely as possible, and specialize after you find an area you are passionate about.

Software

PM’s communicate what needs to be built to engineering / development teams, and therefore must have knowledge in the software realm (duh). The software pillar can be thought of as 2 parts:

A. Understanding what’s to be developed (CS basics / stack /constraints)

B. Understanding your role in the development process

While a PM does not need to know all the details of the technical implementation of features, they need to be able to communicate to developers using the same lingo, and understand what can be done and what can’t. For this reason, PM’s should have a good understanding of Computer Science fundamentals, the specific technology set (“stack”) that the development team uses, and the requirements / constraints / trade-offs the developers face. The technology stack depends on the product, but there are general areas of focus (eg Java/Swift for mobile development, or the MEAN/LAMP stacks for web development).

Many good PMs begin as developers in the product area they work on, and therefore the best way to gain experience is to roll up your sleeves and work on some small software projects. Step 1 is to learn software languages and CS fundamentals, and step 2 is to gauge how difficult various development tasks are, as well as the constraints and trade-offs with various technologies. While constraints and trade-offs are much more important to your day-to-day functions as a PM, it requires you to first go through the former step if you want to truly be good at what you do. Programming skills are generally not directly used on the job, as PM’s typically do not contribute to the code base for the product. However, they may have to write a few scripts (short pieces of code) here and there to obtain data or complete various small, random technical tasks that fall on their plate. For this reason, knowing how to code (step 1) is not a common part of the job, but is an useful skill to have (and a build up to step 2). It will also benefit your relationship with the engineering team, since communication works best when both parties understand each other.

Let’s talk about the development process. Now that we know what will be built, how do we actually do it? Different companies will use slightly different development processes, but the general trend is Agile Software Development. This manifesto/ideology has 2 popular implementation frameworks, known as Scrum and Kanban. By reading about these frameworks, as well as the overlaying Agile ideology, you will gain a better understanding on how to execute software projects and what role you should play a part in it. (Due to popular usage, sometimes Agile and Scrum are used interchangeably to describe the Scrum process). This area will cover planning deliverables and tasks for developers, software testing, as well as all the 4 meetings (planning/standup/review/retro) which go with it.

To improve your skills in this area, the best hands on practice is to use internships at software companies to see these meetings and processes play out. Outside of doing that, there are plenty of online articles and videos talking about the components of the Scrum process in detail. There are also certificates provided by an organization called the Scrum Alliance, which provide professional training for the various roles in the Scrum process.

Design

PM’s need to understand the user, and how humans interact with products. They must also communicate with design teams, and review the designs to be built by the engineering / development teams. Similar to how there are development processes, there are also design processes to facilitate the creation of these designs, and knowing these processes will help PM’s coordinate tasks between teams.

To break this down, design knowledge useful to PMs will include:

A. Understanding the user & customer

B. User Interface (UI) / User Experience (UX) knowledge

C. The company’s design process and associated tools

PM’s help drive human centered product development, and therefore must have a strong understanding of both the users and customers of a product. This knowledge requires a lot of research, and results in an understanding of what the different groups of users (segments) for your product are. Borrowing concepts from the Business pillar, market segmentation can be done via 4 ways:

• Demographic (factual traits like age, gender, income, occupation, etc)
• Geographic (physical location)
• Psychographic (personal principles like values, attitudes and opinions, lifestyle, etc)
• Behavioural (action patterns like usage, purchasing and spending habits, etc)

The statistical clusters which are found in these segments can then be generalized into specific descriptions called personas, which are used by designers to focus their empathy and clarity during the design process. While the knowledge required for understanding your users/customers will differ between products, the concepts of market segmentation and personas can be studied to provide a framework for how to think about your user and customer groups.

Similar to communicating with developers, a PM should have the design lingo to converse with designers, and provide feedback when reviewing mock-ups. This can very broadly be described as UI/UX knowledge, but some common areas when first introduced to this field are design principles, heuristics, and design patterns. Design principles and heuristics (“rules of thumb”) are general rules to follow while designing things, and typically have roots in behavioral and cognitive psychology. “Don Norman” and the “Nielsen Norman Group” are two large names in this space — a good place to start would be reading over “Don Norman’s 6 Interaction Design Principles”, and “Nielsen’s 10 Usability Heuristics”. Many more concepts from behavioral and cognitive psychology will be beneficial to PMs, but my suggestion for tackling this huge space is to read interesting design books like the “Design of Everyday Things.”

Finally, there are common design patterns and style guides you can study which are more specific than general principles and heuristics. Google’s Material Design and Apple’s Flat Design have good documentation online, and specific Google searches like “product onboarding”, or “navigation menus” will yield results on common design patterns for that specific topic. Similar to how understanding software will allow PMs to understand constraints for implementing features, understanding UI/UX will allow PMs to understand constraints for the visual designs as well.

Similar to understanding the development process, a PM should know their company’s design process and how they can contribute, including planning design deliverables. While there are many different design processes, the (very) general idea is to ideate and research, design iteratively with increasing levels of fidelity, and validate via testing all throughout. Common terms for deliverables in the design stage are wireframes, mockups, and prototypes — the details of which can be found online.

They are essentially drafts for the visual interface. The industry standard tool for creating mockups is currently Sketch, while prototyping can be done with a popular tool like InVision. Knowing these tools (or equivalents) can help a PM quickly communicate ideas and requirements from the business, user, and software sides to the design team using actual drafts of the design.

After the designs are created, PM’s oversee interface testing of these designs using methods such as A/B Testing, and User Testing, to prove the validity and success of these designs. This is where real users use the design (either a prototype or actual implementation), and both qualitative and quantitative data is collected to gauge the success of the design. You can think of this as an overlap between the Design and Data pillars. There are methods and guidelines for A/B Testing and User Testing, which can also be researched online to prepare for these tasks.

Data

Data is at the heart of all rational decisions, and it’s the PM’s job to constantly absorb data regarding the product, and adjust their opinions and decisions going forward. Day to day tasks involving data may include querying various metrics, figuring out how to measure success, and presenting results to senior leadership.

To break this down, knowledge in the data pillar will consist of:

A. Product Metrics (what to measure)

B. Obtaining data (how to get it)

C. Interpreting and Presenting data (understanding and showing others)

Metrics are quantifiable measurements of a process, and are used to make product decisions. A Google search for “product metrics” or “user metrics” can yield many results and acronyms for you to look over. An important highlight is that KPIs (Key Performance Indicators) are a subset of these, and are metrics relating specifically to the business strategy and objectives for the company. (You can think of KPIs as an overlap between the Data and Business pillars). While this is beyond the scope of this article, some common metrics include:

• DAU (Daily Active Users), MAU (Monthly Active Users)
• CLV/LTV (Customer Lifetime Value)
• CAC/CPA (Customer Acquisition Cost, Cost Per Acquisition)
• Churn, Retention

Typically these metrics are calculated using telemetry in the source code of the product, and sent to a database where the data can be queried, and used to populate dashboards. As a PM, keeping track of these metrics (and knowing where telemetry needs to be implemented) will help you understand how users use the product, and differentiate good and bad decisions quantitatively.

To query this data and create dashboards, 2 useful languages to know are SQL and Python. Specific Python libraries of interest are NumPy and Pandas, which are widely used for data analysis. (This can be thought of as an overlap between the Data and Software pillars). SQL allows you to calculate metrics and obtain answers from your raw data, and Python is extremely useful in writing short scripts to generate reports. Their usage is of course not limited to just these things, but their overall usefulness to the Data pillar cannot be understated.

After obtaining these metrics, the significance of changes in these metrics must be interpreted and communicated to the relevant teams (including upper management) in a clear way. This is where data literacy, data visualization and PowerPoint presentation skills will come in handy. There are many articles online about data visualization as well as PowerPoint Presentation “best practices”, which all come in handy when you have to use and present quantitative data.

Business

Business skills are important in aligning the product with the overall company strategy. This includes competitor/market research, which is an additional source of input for making product decisions on top of user research. While the business pillar is also quite broad, in my opinion one of the business knowledge areas most beneficial to PM’s is marketing. The reason is: the product could have amazing software and a great design — but all that work will be wasted if it’s never discovered or used by the people it brings the most value to.

To summarize, a good place to start would be exploring the following areas:

A. Competitive Analysis and Strategy

B. The Marketing Mix (4 P’s)

Competitive analysis and strategy is all about understanding the market and your competitors, how to differentiate, and how to achieve business objectives and goals. Searching up how to perform competitive analysis online, you’ll find questions to answer such as:

• Who are my competitors?
• Who are their customers?
• What value are they delivering to their customers?
• What are their strengths and weaknesses?
• What is their business model?

PM’s should research these questions regarding their particular product area, and must always factor the answers into their decisions in addition to input from users.

Another notable concept is the Marketing Mix, which is a core marketing model to create a marketing strategy for the product. It consists of 4 P’s:

• Product (what to build)
• Place (how to distribute)
• Price (how much it costs)
• Promotion (how to tell people)

Each element links to other business areas such as advertising, branding, public relations, etc. These areas are general categories to think about when analyzing products from a business marketing standpoint.

“Product” is about satisfying your customers and users’ needs, and finding ways to make it unique from your competitors. This overlaps with the Design pillar, and is about figuring out who your customers/users are, what your product’s value propositions are, and what features provide those values.

“Place” is about knowing where your customers will look for your product, and putting it there. This is typically geared towards physical products involving supply chains and distribution channels. However, software products and solutions can also have various distribution channels like web vs mobile vs desktop, which are all different places a user might use your product.

“Price” is about managing the pricing model for your product. Various considerations should be made, including what goals the company is trying to achieve, how to price different user segments, and what ways the product can be monetized. There are also various types of pricing strategies to set the actual price value, which are beyond the scope of this article.

“Promotion” is about reaching out and acquiring users. This is where advertising comes in, which is extremely useful for PMs. Important advertising concepts include which marketing channels to acquire users from, and advertising metrics. Channels are mediums where users can be acquired from, like Facebook, Email, Twitter, etc. A great place to learn more about advertising metrics is Google Analytics, which is arguably at the center of digital advertising right now. Examples of advertising metrics include:

• Impressions (how many times something was viewed)
• Bounce rate (% visitors of page/screen who leave immediately without doing anything)
• Conversion Rate (% visitors who go through a process and successfully perform a desired action or end goal)
• CTR (Click Through Rate)

Since advertising is about awareness and engagement, concepts here can be applied to features (eg measuring conversion rates for a shopping cart feature), which is why it’s a great benefit to PMs.

The Roof (Soft Skills)

PM’s work with many people across a lot of teams, with different opinions and priorities. They often make decisions without all the information available, and must talk about topics with people who are more knowledgeable than they are.

It is for these reasons that developing good soft skills are extremely beneficial. The following list stands out after having numerous conversations with full time PMs:

A. Communication

B. Prioritization

C. Persuasion and influencing without authority

D. Adaptability and dealing with ambiguity

Communication: Communication is key. Getting ideas across to different people clearly and in a structured manner is very important for day to day meetings, and for communicating your long term vision.

Prioritization: A product team is never short on ideas for features. The issue is choosing which ones to build first, and certain prioritization frameworks such as “effort vs impact” are good for structuring your thoughts. In a nutshell, you should always prioritize low-effort/high-impact items and high-effort/high-impact items first. The former are low hanging fruits, and the latter are big bets. Investments in these 2 should be balanced out. Try to stay away as much as possible from low-effort/low-impact items, and high-effort/low-impact items are always a no-go.

Influence: When working with many different people and tons of information, there will always be different opinions. It is a PM’s job to distill these inputs and arrive at a decision. However, PM’s don’t actually have any authority over the teams and people they work with. To reach alignment on a task or plan, a PM must be able to persuade the people around them that their decision is correct. This often involves a mix of logical thinking, rational arguments and charisma.

Adaptability and Clarity: Markets change, companies pivot, and there is an inherent trade-off between gathering enough information and making fast decisions. These factors can cause a lot of ambiguity and change on the job, and PM’s often need to create clarity and structure out of this chaos, and make the right decisions despite these conditions.

“Soft skills” often sound vague, and can feel blurry to develop. However, in my opinion the best way to train soft skills is exactly the same as training technical skills — with a combination of knowledge and application. Articles and books do a great job at explaining how to act and what to think on these topics. After reading the explanations, application and experience is needed. Extracurriculars and management positions are great ways to practice what you learn, which is why recruiters often look for leadership roles on PM resumes!

Thanks for reading this all the way through, and I hope it was able to provide a useful skeleton of knowledge! Although this was targeting on-the-job PM skills, I’ve found that the Design and Data pillars are more useful for interviews than the other two.

One final point — many ideas here are informed opinions, but opinions nonetheless. If you have different views or additional knowledge on certain things please comment because I’d love to hear them!