# Product Strategy

### Glossary <a href="#glossary" id="glossary"></a>

<table><thead><tr><th width="151">Term</th><th>Definition</th></tr></thead><tbody><tr><td>PRD</td><td>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.</td></tr><tr><td>Roadmap</td><td>A document that describes when specific products and features will be built.</td></tr><tr><td>PgM</td><td>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.</td></tr><tr><td>TPM</td><td>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.</td></tr><tr><td>QA</td><td>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.</td></tr><tr><td>PR</td><td>Public Relations. A team that helps you tell the story about your product with the public and media.</td></tr><tr><td>i18n</td><td>Internationalization. A team and/or process that helps you bring your product to new markets around the globe.</td></tr></tbody></table>

![PMs sits between business, design, and technology.](https://3501392451-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LLZ89zzVxrdnG1RG6CA%2Fuploads%2FwjnIMof1iQ6qcNIqDZuG%2Fimage.png?alt=media\&token=96adb419-3e11-4822-836d-d9d01b94f77e)

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.

### Further Research <a href="#further-research" id="further-research"></a>

* [What To Expect as a PM from Startup to Scale Up, to Corporates](https://productcoalition.com/what-to-expect-as-a-pm-from-startup-to-scale-up-to-corporates-part-1-of-3-e7478117dd2b)
* [What It Takes to Become a Great Product Manager](https://hbr.org/2017/12/what-it-takes-to-become-a-great-product-manager)
* [Product Managers for the Digital World](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/product-managers-for-the-digital-world)

![PMs do a variety of things in order to help the team figure out what product to build and get it out the door](https://3501392451-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LLZ89zzVxrdnG1RG6CA%2Fuploads%2F6scAAGFkRzFxRMYZoHjt%2Fimage.png?alt=media\&token=faedbd01-0e5c-40aa-a3c2-f0fb075b87af)



### What a PM Does

1. Identifying Problems
2. Creating Solutions
3. Planning (Core team)
4. UX Design
5. Implementation
6. Testing
7. Launch
8. Review

### Product Managers do a lot of things! <a href="#product-managers-do-a-lot-of-things" id="product-managers-do-a-lot-of-things"></a>

* **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.



### More things that Product Managers do: <a href="#more-things-that-product-managers-do" id="more-things-that-product-managers-do"></a>

* **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).



![](https://3501392451-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LLZ89zzVxrdnG1RG6CA%2Fuploads%2F2IeeFEdvzGLcNuUjJcAI%2Fimage.png?alt=media\&token=ead9c1a2-b3e9-4341-ad8b-efd877f3b7a5)

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 |





### New PM

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



### 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:

1. Never be sure that all requirements have been identified
2. 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.

#### Further Research <a href="#further-research" id="further-research"></a>

* [Effective requirements gathering](https://blog.buildo.io/effective-requirements-gathering-b9cbd8176075)
* [Stop gathering requirements](https://www.goodproductmanager.com/2008/05/06/stop-gathering-requirements/)



> **"Innovation is not about saying yes to everything. It's about saying NO to alll but the most crucial features." - Steve Jobs**

###

### PRD (Product Requirements Document)

![](https://3501392451-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LLZ89zzVxrdnG1RG6CA%2Fuploads%2FG3eZ63Bz6tetj8dhirsA%2Fimage.png?alt=media\&token=2472d896-9fda-4a6a-b5cf-1972fe66942c)



#### PRD Template

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.

#### Further Research <a href="#further-research" id="further-research"></a>

* [How To Create a Product Roadmap](https://venngage.com/blog/product-roadmap/)
* [Product requirements documents, downsized](https://www.atlassian.com/agile/product-management/requirements)
* [How to Write a Painless Product Requirements Document](https://medium.com/@uxpin/how-to-write-a-painless-product-requirements-document-508ff6807b4a)

### Write a PRD

#### Problem <a href="#problem" id="problem"></a>

* Users don’t always wake up at the right time
* Wake up times may vary based on the time of day

#### Goals <a href="#goals" id="goals"></a>

* Users wake up on time
* Users can set different alarms based on their schedule

#### Key Features <a href="#key-features" id="key-features"></a>

* 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.



### Build a Roadmap

#### Q1 <a href="#q1" id="q1"></a>

* Basic Alarm
* Snooze
* Edit

#### Q2 <a href="#q2" id="q2"></a>

* Multiple alarms
* Better management for multiple alarms

#### Q3 <a href="#q3" id="q3"></a>

* Gentle alarm
* Custom tones

#### Q4 <a href="#q4" id="q4"></a>

* 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.



### Recap



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

### Total Addressable Market <a href="#total-addressable-market" id="total-addressable-market"></a>

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.

### Further Readings <a href="#further-readings" id="further-readings"></a>

* [How to calculate your total addressable market and make a great TAM slide for investors](https://www.forentrepreneurs.com/calculating-tam/)
