Product Management: Role of PM Flashcards
4 Questions Product managers have to answer
What are we building?
- what product should do
- Do people WANT it?
- Does it create value?
Who are we building it for?
- WHO is the user
- What are their needs
Why are we building this?
- What is the Impact (user value & business objectives)
- Why THIS solution?
When are we building this?
-Roadmap
The goal of product management
To bring a product to market
Core skills of product manager
Strategy Communication Coordination Agility Problem-solving
Why is Product management important?
Easy to build a product that fails, much harder to successfully bring a product to market
There’s an infinite number of problems that could be solved. Product Managers identify and define problems for the team to solve while making sure that:
- the problem is real
- the users are real
- the solution provides value
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.
PM’s positioning
at the center of Design, Business, and Technology
Design: Understandes user needs, and motivations. Acts as a user advocate
Business: understandes business goals, Alignes product to meet those goals
Technology: Understand how to biuld product, its complexity, risks and tradeoffs
Role of PM
Idea to Launch
Drive teams to alignment
Identify and Define problems
Prioritize what the team is focusing on
Spokesperson for product
Secure buy-in
Coordinate
How does Company Size influence PM’s role?
Small:
- broader focus
- less support
- less process
Big
- in Depth focus
- More support
- More process
How does product philosophy impact the role of the PM
Product Driven
- PMS write requirements
- Eng builds based on requirements
- Pros: Customer-centric approach, build what customer wants
- Cons: Lack of empathy from non-customer facing teams
Engineering Driven
- Eng builds things
- PM brings them to market
- Pros: Promotes technical innovation, Sometimes users don’t always know what they want
- Cons: Increases possibility that product won’t resonate with the customer
Hybrid driven
- PM’s write requirements but include eng in identifying requirements
- Eng builds based on requirements, but pm is included in Eng design
How does Type of User influence PM Role
Consumer
- Focus on user problems
- Provides value of the user
- User purchases product
- Faster place of iteration
Enterprise
- Focus on business + user problems
- Provides most value to the company, some value to the user
- Business is the customer who purchases, might not be the end-user
- Slower iteration (more problems/requirements)
How does Type of product influence PM Role
PM can focus on:
Software Hardware Data Growth i18n
each has its own focus and processes
How can you test the effectiveness of your communication?
You can test the effectiveness of your communication by asking people on the team “What are we building and why?” If you ask 5 people that question and get the same answer back from everyone the PM is doing a good job. If you ask 5 people and get 6 different answers back, the PM has more work to do
Who do PM’s work with?
Everyone
The product launch village:
UX Researchers Designers Engineers TPM + PgM QA team Data Scientist Marketing & PR team Sales team Support team Legal & Privacy teams i18n
Difference between PM and PgM
Pm
- Understand the user, the problem, and the market
- Figuring out what to build
- Create PRM
PgM
- Understand teh team, the org, and how to get things done
- Executes against the PRM
What should a PM do the first week at a new company?
Learn about the Company
- What the company does
- How the company makes money
- Short term goals and objectives
- Long term goals and objectives
- Current projects in flight
Meet the people
- the Product Launch village
Experience the product
- 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
-Shadow support and listen to customer calls
Understand the Process
- Learn the process for how to get things done
- What needs to be reviewed
- What requires approval
How do PM’s identify requirements
Research
User interviews
Stakeholder interviews (business objectives)
prototyping
What is requirement gathering
Requirements (Reqs) Gathering is the set of activities performed by a team, in collaboration with their customer and users, that transforms the wishes and needs of stakeholders into actionable requirements for the design delivery and development phases.
What is a requirement
input to the design & development phases to create the product.
What is an ACTIONABLE requirement?
A requirement is actionable by our design & development team when they can take it, and build the best possible product for the end customer. This means that the requirement must contain all the necessary information and context to allow the people who take it to do great design & development.
Difference between taking orders and gathering requirements?
If you want to be a good product manager, understand unmet needs and use that insight to drive requirements. A product manager who just “gathers requirements” is doing nothing more than taking orders or documenting requests. Good product managers add value to their product by understanding the problems and needs behind requests.
Good product managers do not just gather requirements — they understand unmet needs, existing problems, and opportunities for improvement, and they then use that information to determine the requirements for the product.
Methods for requirements gathering
Interviews
Event storing
User story mapping
Methods for requirements gathering
Interviews
Event storming
User story mapping
Should every feature be included in the product roadmap?
Not every feature request should go on the roadmap. It’s important to keep the team focused on creating the most value and saying no to distractions.
PRD
Product Requirements Document
The most important artifact that PO can create
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.
What is included in a PRD
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
