Product Strategy
Last updated
Last updated
| Term | Definition |
|---|---|
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. |
At its very core, the role of the PM is to make sure that the team is solving the right problems and building the right products. Throughout this process, Product Managers will shepherd their product from an idea all the way through launch and partner with a wide variety of cross-functional teams to make the product real. Prioritization also plays an important role in this process, since no company has unlimited resources-- there will always be tradeoffs that need to be made.
Identifying Problems
Creating Solutions
Planning (Core team)
UX Design
Implementation
Testing
Launch
Review
Finding the problem (Understand, Identify, Define) This is part of the core PM and is one of the most important things that a PM does. PMs spend a lot of time defining the problem for the team to solve.
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.
Communicating The best PMs ensure that the entire team is on the same page. This can be accomplished through a variety of different mediums like presentations and conversations.
All PMs write PRDs to frame the problem and document requirements for the solution.
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
Coordinating development and launch PMs are also responsible for coordinating the development and launch of their product across all the various cross-functional partners involved (design, engineering, marketing, legal, support, etc). This doesn’t mean PMs do all the work; they facilitate conversations and help to remove blockers or things that might be slowing the team down. They also make sure that everything that needs to happen does actually happen.
Responding to new information Things change all the time. PMs need to stay up to date with the latest information. Whether that’s from new insights from user research, results from an experiment, feedback from the support team, new product launch from a competitor.
Responding to fires PMs need to be able to juggle multiple tasks and quickly switch focus when priorities change, (i.e. there is an outage).
PMs work with pretty much everyone on the team. Here are some of the most common functions that PMs work with:
| Team | Role |
|---|---|
Design | design what the product looks like |
Research | provide market, user, and product insights |
Engineering | build and maintain the product |
TPM / PgM | keep the team on schedule |
QA | make sure the product works |
Data Science | product insights from data and experimentation |
Marketing | explain the product to users |
PR | explain the product to the media |
Sales | sell the product |
Support | help users use the product |
Legal & Privacy | reduce the product’s risk |
Policy | create rules for how the product can be used |
Ops | help deliver the product to users |
i18n | get the product to additional countries and languages |
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
My manager
My manager’s manager
Other PMs
Design partner
Research partner
Eng partner
TPM partner
QA partner
Data Science
Marketing
PR
Sales
Support
Legal & Privacy
Policy
Ops
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
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
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.
"Innovation is not about saying yes to everything. It's about saying NO to alll but the most crucial features." - Steve Jobs
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
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:
Product Roadmap
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.
PRDs
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.
Both Roadmaps and PRDs should evolve over time as the team is iterating through problems and gets new information.
Users don’t always wake up at the right time
Wake up times may vary based on the time of day
Users wake up on time
Users can set different alarms based on their schedule
P0 - Alarm based on day of week
P0 - Support for multiple alarms (at least 10)
P0 - Alarm management - edit and delete existing alarms
P0 - Alarm goes off at designated time
P0 - Snooze active alarm
P0 - Turn off active alarm
P1 - Customizable alarm tones
P1 - Alarm gradually increases in volume over time
P1 - Auto alarms - Alarm goes off a specified amount of time before the first event on the user’s calendar
P1 - “Silent alarm” that vibrates only
Keep in mind that this is just the very start of a PRD. As you work with the team to further define the product, each key feature should have much more detail about the specifics of what the feature does.
Basic Alarm
Snooze
Edit
Multiple alarms
Better management for multiple alarms
Gentle alarm
Custom tones
Auto alarms
Sleep monitoring
The important part is that the most critical features were earlier on in the roadmap, compared to nice to haves and explorations which came later.
You’ve reached the end of the Role of a PM lesson. We covered the following topics:
The Role of a PM
What a PM Does
Who PMs work with
Identifying Requirements
The Roadmap & PRD
At this point, you should be able to:
Understand the purpose of the PM role
Understand what a PM does during the different stages of the Product Development Cycle
Identify key cross-functional partners and customize communications based on an understanding of their key priorities
Describe different methods for gathering requirements
Define the components of a PRD and how to complete each component including documenting requirements
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.
