Product management is the practice of strategically driving the development, market launch, and continual support and improvement of a company’s products.

Table of Contents:

• Introduction
  • Questions for PMs
  • Skills of a PM
  • Purpose of Product Management
  • History of Project Management
• Role of Product Management
  • Differences in Roles
  • Type of User
  • Types of Products
  • What Project Managers Do
  • Other Roles
  • Exercise: New Project Manager
  • Identifying Requirements
  • Product Roadmap
  • Product Requirements Document
• Problem Identification
  • Identifying Opportunties
  • Understanding the Market
  • Target User
  • Total Addressable Market
• Vision & Strategy
• Communication Skills
• Glossary

Introduction

Learning Objectives:

• Describe the role of a PM and a PM’s critical partners
• Build Artifacts like roadmaps and write PRDs
• Identify and size opportunities
• Create a business case for a new product opportunity
• Define the use cases of a product, including its KPIs
• Build a projected revenue model for your new product
• Put together and present a compelling product pitch to gain internal stakeholder buy-in

Questions for PMs

• At it’s core, product management is about identifying and defining problems facing users and their needs.
  • In addition, they need to know their product and their competition.
• PMs must answer: What are we building?
  • What does the product do, do people want it, and what value does it provide?
• Who is the product being built for? What are their specific needs?
  • Eg. If you’re building a calculator, it’s going to look vastly different if built for a grade schooler vs. a scientist.
• Why are you solving this this problem, and why are we building this specific solution?
  • What is the impact?
  • How does it have both user-value and meet business objectives?
  • It’s also important to be able to communicate to the team why you’re building this over something else.
• When is this being built?
  • Unfortunately, you can’t build everything at once, so it’s important to udnerstand and priortize what to build exactly now, and what to put on the roadmap for later.
• Having compelling answers to all these questions will not only move the project forward, it will also get people excited to work on it.
  • You have to be mindful of answering these questions in a strategic manner that tie back to business goals and objectives, while also creating a cohesive narrative around the product and the company.

Skills of a PM

• PMs must create a good strategy for building and bringing successful products to market.
  • In addition to having both focus and intution around a user’s needs and how they’re respond to changes or updates to products.
• They also must be able to map out the steps needed to be taken in order to get the product to its full potential and vision
  • And, along the way while doing this, course-correct when new information arises,
• PMs are constantly comunicating out and responding to questions, they are the source of truth for the company and the product.
  • They need to be able to speak to multiple audiences, including the design team, engineers, exectuives, and customers.
• PMs also require coordination, and act as the glue that hold companies together.
  • With end-to-end visibility, they’re in the only role that sees the product through the entirity of the development process.
  • Design might not be aware of what marketing is working on, and vice-versa.
• PMs are required to also respond to a consistent flow of new information, and decide what to do.
  • Whether that’s results from a user-study, a new product from a competitor, or an e-mail from the CEO.
• Finally, PMs are also responsibile to mitigate crisis, and constantly think on their feet and tackle new issues as they come up.

Purpose of Product Management

• Bringing productsa to market is more complciate than ever.
  • It’s easy to build products that fail, but really hard to build something marketable.
• There’s a need for someone to focus on the user and the problem.
  • This ensures the team does not lose sight on the important things that really matter.
• Aligning the team and orchestrating movement in the same direction.
  • Advocate for users, understand the business, empower design, create stability for engineers.
  • While at the same time getting people excited for the product and focused on what’s important.
• It’s important to make sure you’re not only finding a problem to solve, but the right problem.
  • Not all problems will lead to succesful products.
  • AKA Real problems for real users.
• For example, Google Glass was an incredible innovation, but ultimately failed because no direct problem for users was being solved.

History of Project Management

1931 - Neil McElroy and “Brand Men”

Neil McElroy wrote a memo called “Brand Men” while at Procter & Gamble. This memo touched on two parts of this new role that carried into product management:

• “Full responsibility” - Product managers are responsible for the success of their product. They need to work across multiple teams in order to achieve their goals and build great products.
• “Studying things personally at first hand” - Getting out of the building, seeing problems first hand, and interacting with users is a critical part of the product management role. This experience will provide you with deep insights and build empathy for your users.

1930s - Bill Hewlett and David Packard

These two entrepreneurs met while at Stanford. McElroy was an advisor of theirs and they were deeply influenced by him. They went on to found Hewlett-Packard in 1939. And one of HP’s key strategies was to put decision making as close to the customer as possible. Being close to your customers and understanding their needs is a core part of product management.

1960s - Japan

After World War II, just-in-time manufacturing became common in Japan. In addition to reducing waste during the production process, there were also two important principles:

• Kaizen: change for better - continuously improving the business while always driving for innovation and evolution. Today you see Product Managers driving constant improvements and optimizations for their products.
• Genchi genbutsu - real location, real thing - This means going to the source to find the facts to make correct decisions. This is again, highlighting the importance for Product Managers to get out of the building and experience everything first hand.

Product Managers originally started in the marketing function and focused on making sure the product is in the right place, at the right price, with the right promotion. As tech began to create giant new industries, it became crucial that products were developed to more deeply meet user needs.

When looking at the 4 P’s of Marketing, Place, Price, and Promotion are under the role of brand management.

Role of Product Management

• At the end of the day, the role of a product manager is to make sure the team is solving the right problems, and successfully building products that people want.
• In order to achieve this, the PM is positioned at the center of: Design, Business, and Technology.
  • Design is to look at user needs, motives, and advocate for them.
  • Business is to align the product goals to the business objectives.
  • Technology is to understand how the product is built, as well as understanding complexity, risks, and tradeoffs.
• PMs need to be able to influence without authority, as they don’t usually have actual control over any particular team.
  • • Solving problems might make the product more appealing to users.
  • It has the potential to increase sales.
  • It reduces user churn, and keeps the company competitive.
  • It also can increase the team’s efficiency.
  • Or, it might be legally required if you want to continue selling the product.
• Regarding prioritization, stack ranked lists can help numerate different features more precisely.

Differences in Roles

• The role of a PM can vary a lot based on the company and product.
  • The size of a company has a big impact on the scope of a PMs work.
• At smaller companies it’s more likely that PMs will have more end to end responsibility and wear more hats.
  • There will be less support and process, and overall more ownership.
• At larger companies oftentimes there will be larger supporting teams, which allow PMs to maintain a narrow focus and go super deep on that specific area.

A company’s philosophy to building products also shapes the role of a PM. The most common philosophies:

• Product led: Solving problems for users, focusing on understanding and writing requirements.
  • Research is done through talking and studying users.
  • Then, once engineering has the requirements, they will build.
  • While this is a customer-centered approach, there might be a lack of empathy from non-customer facing teams.
• Engineering led: Engineers solve a technical problem, and the PM brings it to marketing.
  • This promotes technical innovation, and sometimes, customers don’t really know what they want, until they have it.
  • However, this increases the possibility that the product won’t resonate with the customer.
• Product + Engineering partnership: PMs write the requirements, but engineering is included in identifying them.
  • Engineering then builds based on requirements, but the PM is included in the Eng Design.

Type of User

• Consumers mean focusing on user problems and providing value.
  • Customer-facing products require a simple, clean UX design.
  • The user is likely the person who purchases the product.
• On the other hand, for enterprise products, the focus is both on the user and the business problems.
  • The bulk of the value is provided to the company, and some value to the user.
  • And, ultimately, it’s the company that decides to purchase the product, even though the employees will be using it.
  • In these types of environments, the user and the customer are not the same.
  • There are usually a lot more problems for PMs to identify any requirements to manage, thus creating slower iteration and development.

Types of Products

• Software products require PMs to really focus on UX and will also need to understand roll-out cycles and processes like App Store reviews.
• Hardware products focus on components, capabilities, cost, and the supply chain.
  • In addition to shipping certification, factory lines, and import implications.
  • Physical products also cannot be updated nearly as easily as digital ones, meaning there’s more emphasis on getting things right the first time.
• Data products are used for researching and possibly machine learning, getting super deep into data and numbers.
  • The goal being to figure out how to build a product on top of a lot of data.
  • Eg. Self-driving cars or Netflix recommendations.
• Growth is where PMs focus on accelerating the product through features that drive adaptability, either directly or indirectly.
  • The focus being on getting new users and having a deep understanding of their funnel optimization.
• Internationalization is the focus on bringing the product to new places.
  • This means deeply understanding the differences in those markets, user behaviour and expectations, and adopting the product to fit.
  • This also includes adaptions such as adding support to right-to-left languages in UI or creating systems that can customize content in an app based on location.
  • Some markets might also have additional requirements that must be met before the product can be launched there.

What Project Managers Do

• Finding the problem (Understand, Identify, Define)
  • This one of the most important things that a PM does.
  • Understanding the user and their needs, as well as the space that the product will be in.
  • Conducting market, user, or competitive research to leverage existing product insights and data or other inputs to create hypotheses and test them.
• Creating strategy, once armed with an understanding of the problem space and opportunity.
  • PMs can build strategies for how to solve the problem through the creation of their product.
  • Creating a high-level overview of the product, features and what it does.
  • As well as how it maps to goals, objectives, and KPIs.
• Once the problem and requirements have been identified, then planning begins to figure out how to tackle the work.
  • This usually involves working with design and engineering to figure out how much time is needed to both design and build the product.
  • For larger products that will take a longer time to ship, it can be helpful to break things down into milestones.
  • It is also important to identify key points of contact in both design and engineering that will be working with you as PM.
• During UX design, it’s super important to focus on building out mocks and the spec for the user-experience.
  • Your role as PM is to provide context that can help inform design decisions.

Other Roles

Exercise: New Project Manager

Imagine that you have just started a job at a new company as a PM. How would you want to structure your first weeks on the job?

• When you join a new team or company, it can take awhile to ramp up. To get started on a good path, here are the things that I would try to do during my first few weeks on a new team:
• Company
  • What the company does
  • How the company makes money
  • Short term goals and objectives
  • Long term goals and objectives
  • Current projects in flight
• People
  • Manager, other PMs, partners, etc.
  • See above chart.
• Product Experience
  • Check out the product’s website
  • Review the app store listing
  • Use the product
  • Journal of my experience using it
  • Questions that I have about why it is the way it is
  • List of issues that I encountered while using the product
  • Get help for the product
  • Review the support site
  • Reach out to customer support for help with an issue
  • Use competitor products
  • Compare similarities and differences
• Other
  • The Process
    • Learn the process for how to get things done
  • What needs to be reviewed
  • What requires approval
  • Shadow support and listen to customer calls

There will be lots to learn! But even while you are ramping up, you can still provide value to the team by providing a fresh perspective on your experience using the product and the issues you ran into. And make sure to ask lots of questions!

Identifying Requirements

• Once a requirement has been identified, it gets documented in a PRD (Product Requirements Document).
• Keep in mind that identifying requirements is a much more active and involved process than just “gathering.”
• It’s important that PMs understand the problem and why a specific requirement exists. Identifying Requirements can happen through a variety of channels:
  • Research
  • Prototyping
  • Input from users / customers
  • Input from cross functional partners
• And two common challenges that come up when identifying requirements are:
  • Never be sure that all requirements have been identified
  • Users might not be able to tell you what the product should do (ie: the requirement).
  • Instead it’s better to focus on understanding the problem the user is facing and their needs. Ask why. Then ask why again. And keep asking why until you get to a deeper understanding.

Product Roadmap

• Product Managers spend a lot of their time answering the question WHAT should the product do and aligning internal teams to execute against their vision.
  • There are two tools that PMs use to communicate WHAT the product should do: Roadmaps and PRDs.
• A product roadmap is the plan that the team will be executing against.
• Product roadmaps provide a high level overview of the direction of the product over time.
  • It calls out work that is required to meet business objectives and roughly when that work needs to happen.
• Roadmaps are a powerful artifact because they set expectations across the team in terms of the team’s priorities.
  • They also are a powerful mechanism for driving alignment across various stakeholders and making tradeoffs between new requests and planned work.
• In addition:
  • High level overview of the direction of the product over time (ie: multiple features)
  • Rough timelines when work needs to happen
  • Set expectations across the team around prioritization.
  • Drive alignment across various stakeholders and help make tradeoffs between new requests and planned work.

Product Requirements Document

• The PRD is the source of truth that answers the question WHAT is the team building and WHY, which is incredibly helpful to drive alignment across the team.
  • A PRD is never done and will continue to evolve as the team is working on the problem.
  • It’s the PM’s job to write the PRD and keep it up to date as decisions are made and new information becomes available.
• PRDs always need to have these components:
  • frame the problem… and answers the question WHY are we solving it.
  • outline the goals… both user goals, business goals, and success metrics. This section also helps to explain WHY the problem should be solved.
  • describe the requirements… WHAT does the product do? Remember, as a PM you are answering WHAT the product does. Design and engineering have to figure out HOW.
• Additionally, other components can include:
  • assumptions
  • options considered
  • UI mocks
    • (it can be super helpful to work with design and include these in the PRD because it is often easier to communicate some ideas visually instead of through text)
  • out of scope
  • risks & mitigations
  • support plan
• In addition:
  • More detail about a specific feature
  • Frame the problem and answer the question WHY are we solving it.
  • Outline the goals (both user goals, business goals, and success metrics). This section also helps to explain WHY the problem should be solved.
  • Describe the requirements and answers WHAT does the product do?
    • Remember, as a PM you are answering WHAT the product does. Design and engineering have to figure out HOW.

Problem Identification

Identifying Opportunties

• Finding the right problem to solve is critical for the success of your product!
  • If you aren’t focusing on the right problems, your product will fail.
  • This is something that both big and small companies struggle with. You’ll have to work through constraints and tradeoffs
• You can start to identify which problems to solve by looking at:
  • Market Research
  • User Research
  • Product Data
  • Support Data
  • Efficiency gains

Understanding the Market

• Understanding the market is critical to building successful products.
  • Some markets are better than others. And some products do a better job than others.
  • You’ll want to make sure that your product satisfies the needs of the market.
• Understanding the market allows you to focus on solving the right problem. Keep in mind that some markets are better than others.
  • Size: How many people have this problem?
  • Growth: Is the size of the market increasing?
  • Acquisition: How much does it cost to acquire customers?
• To better understand the market, you’ll want to talk to your users and customers.
• But before you do, you can look at some of these things to get more familiarity with the market:
  • Online research
  • Headlines & News
  • Similar products
  • Trends:
    • Mary Meeker’s Internet Trends
    • Google Trends

Target User

• Identifying a target user is important, because it makes it very clear who you are building the product for.
  • Oftentimes, a problem will best be solved in different ways for different types of users.
• Identifying a target user creates focus and lets you focus on solving the needs of that specific target user.
• Your target user represents a set of users with shared characteristics, like demographics, motivations, goals, and frustrations, who are likely interested in your product.
  • To identify your target user, you will need to talk to your users and do market research.

Total Addressable Market

• TAM, or total addressable market, is a measure of the revenue opportunity for a product. Keep in mind that TAM is not a measure of your revenue or future revenue. Instead, it allows you to understand the size of the market if you had 100% of the market. A larger TAM indicates a larger opportunity, with more demand for a particular product. However, just because there’s a large TAM does not mean that a product is guaranteed to be successful… There are lots of other factors that will come into play, like competition.
  • • TAM = Average revenue per user X total number of potential users in the market

There are several approaches to calculating TAM:

• Top Down
  • You start with a high level view of the economy, and then narrow that down based on factors like demographics. For example, you usually will start will everyone in the world and narrow down that audience to people who are interested in your product.
• Bottoms Up
  • This involves using known data points that you have (data from early customers and sales) that you could extrapolate to represent a larger market opportunity. For example, if you are already selling a product in one region and were considering selling it globally.
• Value Theory
  • Generally used for new product categories where you don’t have much information to base estimates on. This involves conducting market research to understand how much people would pay for your product and how many potential customers you have.

Vision & Strategy

Communication Skills

Glossary

• PRD: Product Requirements Doc. A document written by a product manager that describes why a product should be built and what the product should do, as well as how to measure success of the product.
• Roadmap A document that describes when specific products and features will be built.
• PgM: Program Manager. A person who helps a variety of teams (engineering, design, ops, etc) execute against the product roadmap. A program manager keeps the team productive and on track, as well as flags risks.
• TPM: Technical Program Manager. A more technical program manager, who works closely with engineering teams to execute against the product roadmap. A TPM is more involved in the technical details of software development.
• QA: Quality Assurance. A team that creates test plans and tests your product to identify and prevent bugs and issues from entering production and affecting users.
• PR: Public Relations. A team that helps you tell the story about your product with the public and media.
• i18n: Internationalization. A team and/or process that helps you bring your product to new markets around the globe.

---