[DOCUMENT TITLE]

[Document subtitle]
Contents
What is Product Management? .................................................................................................................... 2
Product Management vs Project Management ......................................................................................... 3
Types of Product Managers .......................................................................................................................... 3
CIRCLES .............................................................................................................................................................. 4
Methodologies.................................................................................................................................................. 5
Agile ....................................................................................................................................................................... 5
Waterfall ................................................................................................................................................................. 6
Scrum ..................................................................................................................................................................... 7
Kanban ................................................................................................................................................................... 8
User Personas ................................................................................................................................................... 9
How to create user personas? ......................................................................................................................... 9
Types of personas ............................................................................................................................................ 10
Buyer Persona ........................................................................................................................................ 10
Decision-Maker Persona ...................................................................................................................... 10
Customer Persona ................................................................................................................................. 10
Use Cases and Pain Points .......................................................................................................................... 10
UX Designing and Prototyping................................................................................................................... 11
Low-Fidelity vs. High-Fidelity Prototyping ................................................................................................. 12
Low-fidelity ............................................................................................................................................. 12
High-fidelity ............................................................................................................................................ 12
Minimum Viable Product (MVP) ................................................................................................................. 13
Solution ............................................................................................................................................................ 13
Prioritization ................................................................................................................................................... 14
RICE Framework................................................................................................................................................ 14
Value V/S Complexity ...................................................................................................................................... 15
MoSCoW ............................................................................................................................................................. 15
Product Metrics (KPIs) .................................................................................................................................. 16
Finding the right metrics ................................................................................................................................ 16
AARRR Framework ........................................................................................................................................... 17
The North Star Framework ............................................................................................................................. 18
HEART Framework ........................................................................................................................................... 19
Testing.............................................................................................................................................................. 20
What is a PRD? .............................................................................................................................................. 21
Product Management Cases (For Interviews) .......................................................................................... 22
Design a Product .............................................................................................................................................. 22
Root Cause Analysis ........................................................................................................................................ 23
Practice Resources ........................................................................................................................................... 24

1
What is Product Management?
Product management is the practice of strategically driving the development, market launch, and
continual support and improvement of a company’s products. Product management is vital to
delivering innovations and driving business growth. It is an important organizational role that is
growing in popularity.
Product managers can be found at all the companies that are building products and technologies
for external customers (consumers, end users, partners, etc.) as well as internal customers
(employees). In tech, where entrenched products are quickly uprooted by newer and better solutions,
there is more need than ever for an intimate understanding of customers and the ability to create
tailored solutions for them. That’s where product management comes in.
Product managers are responsible for the strategy, roadmap, and feature definition for a product or
product line. The position may also include marketing, forecasting, and profit and loss (P&L)
responsibilities. Product managers work closely with sales, support, marketing, design and
engineering teams to deliver the best possible customer experience.

Key Functions:
● Conducting Research
● Developing Strategy
● Communication Plans
● Coordinating Development
● Acting on Feedback & Data Analysis

2
Product Management vs Project Management
Product managers and project managers can and often do work closely together on the same
initiatives, but in most cases, they have two different sets of responsibilities.
Product managers have strategic responsibility for driving the development of products, whereas
project managers are responsible for overseeing the execution of those development plans.

Types of Product Managers

1. Technical PM: A Technical Product Manager is one of the easier job titles to understand. A
TPM is like a normal PM, but who has a strong technical background. Perhaps they
transitioned to products from engineering. While most of their actual duties will be identical
to a non-technical Product Manager, they’ll be able to lend more of their skills to the
engineering team, and have a more hands-on role. It might mean that they have less time to
dedicate to other aspects of the product, like marketing.
2. Growth PM: A growth product manager is focused on the user base and certain metrics
growing by running experiments. Typically the growth team is not the same as a regular
team, it has sales and marketing and UX people inside it to run quick experiments. Your
product is your user funnel and user experience.
3. Data PM: A data product manager (PM) focuses on product data management, which is the
process of collecting, organizing, storing, and sharing data within an organization. Data
product managers are responsible for finding ways to leverage data flow throughout an entire
product lifecycle (not just the design stage), and they use that data to build and perfect a
feature or product.
4. Business PM: The business product manager is responsible for the strategy, roadmap, and
feature definition for the product or product line. He/She evaluates product ideas and decides
if the ideas are worth pursuing. He/She oversees the product strategy and the steps that will
get the product through each step.

3
CIRCLES
The CIRCLES method is a framework that product managers can use to respond thoughtfully to any
design question developed by Lewis C. Lin. CIRCLES is an acronym in which each letter stands for
the first word of the step and explains what you should do to answer the question posed to you:

● Comprehend the situation: A product manager should seek to gather as much information
as possible about a design question. During this stage, ask as many questions as you want
to understand the context better: What problem is the product trying to solve?
● Identify the customer: The next step is to identify the customer you want to reach. That’s
going to consist of finding information such as their demographics, challenges, goals, income
level, etc. For example, here’s what our ideal customer will look like for our accommodation-
rental app: “We’re targeting tourists and travelers from the ages of 18 to 60 who want to
experience a new country in a unique way by living like a local. They travel around three to
five times per year and are either middle class or upper class.”
● Report the customer’s needs: To identify what the customer wants to achieve with your
product and the problems they want to solve. In the case of our accommodation app, we can
say that our customer’s needs are: the ability to book a rental based on specific limitations,
a way to book rentals in other countries without speaking that country’s language, and
viewing previous reviews.
● Cut through prioritization: To cut through prioritization means to rank which user need you
want to solve first in the product roadmap. You can prioritize user stories based on their
impact on revenue, customer satisfaction, and how hard it will be to implement features that
meet those needs.
● List solutions: Start listing solutions for each user story you created. These solutions must
be features you can include in the product that will solve your customer’s needs.
● Evaluate tradeoffs: After listing your solutions, evaluate the tradeoffs of each solution. It
involves thinking about the benefits of each solution, along with the potential constraints
that could get in the way of building this solution. For example, including a rating system

4
 allows users to look at reviews from previous guests on a booking so they know what to
expect.
● Summarize your recommendations: The last step is to summarize everything you discussed
during the interview. During this stage, Lin recommends simply telling which features you
think are best for the product, how it solves the user’s needs, and why you’d prioritize them
over others.

Methodologies

Agile
Originally designed for software development, this is one of the most popular methodologies today.
It’s particularly adopted for agile environments – when products have iterative, incremental
requirements, and solutions evolve as a result of a collaborative, self-organizing, and cross-functional
approach to product planning and implementation. The Agile approach is also open to constant
feedback from end-users.

The Agile methodology is an adaptive practice best suited for products where you know that
requirements and constraints are complex and prone to change (such as software development), and
therefore require a flexible approach.

5
Waterfall
This linear, sequential approach to product management is one of the more conventional
methodologies in existence. Product development in this case, including planning, execution, and
delivery, flows in a linear, unidirectional manner – much like a waterfall.

This methodology was originally developed in the manufacturing and construction industries, where
typically, one development stage must be complete before the next one begins. You can’t go back
to a previous stage, and any revision requirement results in scrapping the existing process and
starting at the top all over again.
Thus, if you’re debating on Agile vs Waterfall, remember that while Waterfall ensures better planning,
it offers less operational flexibility.
WATERFALL
AGILE

The Waterfall approach is ideal for large scale, capital-intensive product requirements that call for
disciplined planning and execution. It also works for routine requirements where chances of sudden
changes of any kind are low.

6
Scrum
Scrum is essentially a subset of the Agile methodology. While it’s also an iterative process, it actually
supports fixed-length iterations – also called sprints. A sprint can last for one or two weeks, which
means that deliveries can strike a regular cadence. Another point of distinction is that Scrum
emphasizes a fixed set of roles, tasks, and meetings, which never change.

During each sprint, task boards and burndown charts are created to help team members gauge
product development progress at a glance. Team members also have to attend a short, highly
focused Scrum meeting every day to discuss goals and issues. At the end of a sprint, all members
and stakeholders are required to meet to plan the next sprint.

Scrum works best for complicated product requirements that need to be proactively managed to
stay within reasonable timelines.

7
Kanban
Another Agile variation, Kanban, in the literal sense, means “visual sign” or “card” in Japanese.
Kanban is implemented via a Kanban board, which visualizes a product team’s workflow. The Kanban
board segregates work into three categories – to do, in progress, and completed. Every task is
captured on a Kanban card, which is moved from one category to another as it progresses along the
process.

The visual nature of the Kanban process makes it easy for all team members to remain on the same
page, while also helping them quickly identify opportunities for process improvement or
enhancements. For instance, it immediately highlights process bottlenecks and gaps. Kanban also
emphasizes limiting the amount of work in the “in progress” category at any point of time.

The end goal of the Kanban methodology is to continually improve the product development process.
Working towards this end, regular team meetings are held to discuss necessary changes, based on
the data on the Kanban board.

Kanban is best for products involving relatively small teams and few tasks. It’s also great for
recording and tracking personal productivity.

8
User Personas
You can think of a user persona as a character study of your target customer. It helps us to imagine
our target audience as real people and visualize how our product will fit into their real life. The main
purpose of a user persona is to create empathy for customers.

Here are the key benefits of defining user personas:

● Explain the “why” behind product decisions
● Focus on the needs of the most important user groups
● Prioritize features that solve actual user problems
● Implement new functionality in line with how customers will actually use it

How to create user personas?

You need to understand who is using your product. Personas must be as truthful as possible, so it
is important to spend time learning as much as possible about your target users. The specific details
you need to capture will vary based on your industry, market, and type of product. Here are the
different types of information that can be useful to gather:
● Personal background: Age, education, and location
● Professional background: Job title, income level, skills, responsibilities, and experience
● Psychographic information: Goals, challenges, likes, and dislikes

You can use qualitative and quantitative data to inform your research — such as directly interviewing
users, reading support tickets, talking to teams who interact with users, and analyzing product usage.
Personas help give your problem statement a direction and focus. There is no one size fits all when
it comes to a product. After your research, build out a persona such as the following:

9
Types of personas

Buyer Persona
The buyer persona is a central figure in a B2B organization. Often, this person will have a say in the
purchasing process. A buyer persona can represent several influencers and decision-makers within
a company, who might not even use the product themselves.
The buyers will, however, have different needs, challenges, goals, and fears from the user persona.
They might, for example, be equally concerned with protecting the company’s budget as with finding
the right solution to help the user persona improve their job.

Decision-Maker Persona
Whereas a buyer persona can represent several people in an organization who might participate in
the decision-making process, the decision-maker is typically a more-narrow persona—often an
executive at the company.
This type focuses on the big picture aspects of the decision: Will it improve the company’s bottom
line? Does it cost more than the business should spend? Product and marketing teams selling into
businesses will need to build the product and develop the messaging in such a way to appeal to
these concerns of the decision-maker persona.

Customer Persona
The customer persona is a catchall term to describe your product’s main persona. It might be the
user persona, for example, for a B2B product or be the buyer and user for a consumer-oriented
product. For a business that sells products to other businesses, a customer persona could represent
either the user or the buyer personas.

Use Cases and Pain Points

Broadly after finding out the types of user personas, we need to simultaneously look at the types of
use cases while building our personas. To do so, we must keep in mind certain pointers -

1. Ask the right questions: One approach is to ask Open-ended questions that allow people to
include more information in their answers, including how they feel, which will lead you to ask
questions you hadn’t considered.
2. Pattern recognition: When you conduct about 15-20 interviews, you will start to hear the
same things again and again. You’ll hear patterns. So by the 21st interview, you’ll ideally
hear something similar to what you’ve heard previously.
3. Prevent biases: Starting with a solution, rather than with a problem, will inevitably bias your
customer discovery process. You’ll find yourself involuntarily pointing out the use cases to
prospective customers, rather than listening to their problems.

All good products start with not only identifying an overarching problem, but also identifying a pain
point — the emotional, human component of product management that draws in customers and
makes them feel something.

10
Though you may think your product is solving a common industry pain point, the end result may
prove otherwise. That’s where market research comes in. You want to make sure that the product
you’re creating is built for many, and not just one instance of an issue. These steps of identifying the
use cases and pain points along with building the user personas go hand in hand.

UX Designing and Prototyping

UX is short for User Experience Design, and it can be defined as the branch of design that creates
easy-to-use and delightful products that focus on the user’s needs. UX is very important to all
Product Managers because it is a key component in product development.

Prototyping is an experimental process where design teams implement ideas into tangible forms
from paper to digital. Teams build prototypes of varying degrees of fidelity to capture design
concepts and test on users. With prototypes, you can refine and validate your designs so your brand
can release the right products.

The advantages of prototyping are that you:

● Have a solid foundation from which to ideate towards improvements: giving all stakeholders
a clear picture of the potential benefits, risks and costs associated with where a prototype
might lead.

11
 ● Can adapt changes early: thereby avoiding commitment to a single, falsely ideal version,
getting stuck on local maxima of UX and later incurring heavy costs due to oversights.
● Show the prototype to your users so they can give you their feedback to help pinpoint which
elements/variants work best and whether an overhaul is required.
● Have a tool to experiment with associated parts of the users’ needs and problems: therefore,
you can get insights into less-obvious areas of the users’ world (eg. you notice them using it
for other purposes or spot unforeseen accessibility issues such as challenges to mobile use).
● Provide a sense of ownership to all concerned stakeholders: therefore, fostering emotional
investment in the product’s ultimate success.
● Improve time-to-market by minimizing the number of errors to correct before product release.

Low-Fidelity vs. High-Fidelity Prototyping

Fidelity refers to the level of detail and functionality you include in your prototype. Usually, this will
depend on your product’s development stage. You can construct one that gives a wide view of the
entire system or subsystem (called a horizontal prototype – e.g., an entire website) or one that gives
a detailed view of just one feature (a vertical prototype – e.g., a checkout process). Consider the
differences:

Low-fidelity
Example: Paper prototypes
● Pros: Fast and cheap; disposable; easy to make changes and test new iterations; allow a
quick overall view of the product; anyone can produce them; encourage design thinking since
prototypes are visibly not finalized.
● Cons: Lack of realism, so users might have a hard time giving feedback; hard to apply results
from crude early versions; may be too basic to reflect the user experience of the finished
product; can oversimplify complex issues; lack of interactivity deprives users of direct control;
users must imagine how they would use the product.

High-fidelity
Example: Digital prototypes created on software such as Figma, Sketch or Adobe XD
● Pros: Engaging—all stakeholders have the vision realized in their hands and can judge how
well it matches users’ needs and solves their problems; testing will yield more accurate, more
applicable results; versions closest to the final product enable you to predict how users will
take to it in the marketplace.
● Cons: Longer/costlier to create; users are more likely to comment on superficial details than
on content; after hours of work, you the designer are likely to dislike the idea of making
changes, which can take considerable time; users may mistake the prototype for the finished
product and form biases.

Some designers split high-fidelity prototyping into “mid-fidelity” (where prototypes can have basic
digital interactivity or be slick wireframes) and “high-fidelity” (where they’re far closer to the final
version). Interactive prototypes yield far more useful results in user tests. However, fidelity is
relative—a static mockup of a landing page, for example, is of higher fidelity than sketched cut-outs
users can move. Overall, you should always commit to prototyping with the users’ needs in mind,
particularly with an eye for user flow.

12
Minimum Viable Product (MVP)
A minimum viable product, or MVP, is a product with enough features to attract early-adopter
customers and validate a product idea early in the product development cycle. In industries such as
software, the MVP can help the product team receive user feedback as quickly as possible to iterate
and improve the product. Because the agile methodology is built on validating and iterating products
based on user input, the MVP plays a central role in agile development.

It is the version of a new product that allows a team to collect the maximum amount of validated
learning about customers with the least amount of effort.

A company might choose to develop and release a minimum viable product because its product
team wants to:
● Release a product to the market as quickly as possible
● Test an idea with real users before committing a large budget to the product’s full
development
● Learn what resonates with the company’s target market and what doesn’t
● In addition to allowing your company to validate an idea for a product without building the
entire product, an MVP can also help minimize the time and resources you might otherwise
commit to building a product that won’t succeed.

Solution
Once you have identified the customer problems and user needs, the next biggest thing to do is
deciding on what you can uniquely create that can solve the problems you have found.

As a product manager, deciding on what to build is a critical decision. One mistake that many product
managers do is capture solution ideas in a lengthy feature backlog which is the list of features that
they like to develop. This is completely against the idea of focusing on customer problems rather
than solutions and chances are that you get fixated on specific solution ideas and jump to
conclusions with a risk of delivering sub-optimal solutions that don’t solve any user problems and
end up not getting used at all.

13
There are essentially three steps that product managers should include in their strategy of deciding
on ‘What to build?’:

1. Idea Management: The idea management phase where product managers should try to
capture suggestions, ideas, or feature requests for the product’s evolution.
2. Product Specifications: A product specification document is a document with a set of
requirements provided to product teams with all the information on what the team needs to
build. A product manager at this stage can limit himself to specifying the features at a high
level and leave the rest to UX designers/engineers who are specialists in developing the
solution.
3. Road mapping: A product roadmap is a visual document that is shared with all the
stakeholders to communicate the steps you plan to take to achieve your product vision. It
informs everyone involved, where the product stands today, the direction in which it is
moving and how to get to the vision or goal.

Prioritization
There are many prioritization frameworks that you could use to decide on how to prioritize features
and decide what matters the most. Here are the most popular prioritization techniques:

RICE Framework
The RICE framework was developed by messaging software Intercom for its internal use and product
management strategy. RICE is an acronym for the four factors measured for each product feature or
initiative using the technique- Reach, Impact, Confidence and Effort.

● Reach
How many people will the feature impact in a given time. Scale is from 0-100 % of the users.
● Impact
How much will the feature impact users, represented using a multiple-choice Scale as 3- for
massive impact, 2- high impact, 1- medium impact, 0.5- low impact, etc.
● Confidence
How confident are you about the impact and reach scores, measured as a percentage score.
● Effort
Time investment required for the initiative, measured as persons per month

The overall RICE score is then calculated using a formula:

14
Value V/S Complexity
In the Value versus complexity quadrant, you evaluate every feature based on the business value of
it and the relative complexity to implement it. This is a simple and common approach that most of
the product managers today follow.

MoSCoW
The acronym MoSCoW represents four categories of initiatives: must-have, should-have, could-have,
and won’t-have, or will not have right now. Some companies also use the “W” in MoSCoW to mean
“wish.” It is a popular prioritization technique for managing requirements.

15
Product Metrics (KPIs)
Metrics is a quantifiable measure that allow businesses to define and track the success of a product
or a business activity. Metrics are used by stakeholders, marketers, and the product management
team to detect problems, set goals, and make informed decisions.
Today, the biggest issue with metrics is not how to measure them but it’s choosing the right few key
metrics to keep an eye on, spend less time tracking, and more time acting upon the found data.

Finding the right metrics

The following example shows how various industries define metrics:

For other terminologies and KPIs, please refer to: https://www.altexsoft.com/blog/business/15-key-

product-management-metrics-and-kpis/

16
AARRR Framework
AARRR Pirate Metrics framework is an acronym for a set of five user-behavior metrics that product-
led growth businesses should be tracking: acquisition, activation, retention, referral, and revenue.

Acquisition (or awareness) – How are people discovering our product or company?
In the AARRR framework, acquisition refers to all the channels you use to introduce people to your
product.

Activation – Are these people taking the actions we want them to?
Activation refers to users taking the desired actions, or next steps, after their first encounter with
your company’s product, website, or content.

Retention – Are our activated users continuing to engage with the product?
After you’ve “activated” new users by persuading them to take action, you’ll want to monitor how
many of these users are continuing to show interest in your product.

Referral – Do users like the product enough to tell others about it?
This refers to users introducing your company or product to friends and coworkers. These are some
of the most difficult metrics to track because people use all sorts of ways to tell others about apps
and businesses.

Revenue - Are our personas willing to pay for this product?)

Finally, you’ll need to identify actual revenue targets for your users. It will help you understand
whether your costs for acquisition, activation, and other efforts result in profitable growth.

17
The North Star Framework
The North Star metric should provide evidence of a clear and direct relationship between your
product’s problem and the degree to which it is solving it for your target market.

It is the single metric your team or company decides will be the one that best represents how well
your product is performing in the market.

A north star metric has usually the following characteristics:

● Expresses value
● Represents vision & strategy
● A leading indicator
● Actionable
● Quantifiable

A good north star has three attributes:

● it measures the moment that a customer finds value from your product,
● it represents the core of your current product strategy and
● is a leading (not lagging) indicator of a future business outcome that your company cares
about.

The north star metric is usually measured as a multiplication of several leading indicators, most times
a combination of reach, engagement and frequency:
Reach: Number of relevant users
Engagement: A certain action
Frequency: Number of repetitions of the action taken

18
North star framework applied to Netflix:

HEART Framework
The Google team has developed a few useful methods to help select and define appropriate metrics
that reflect that:

● The quality of the user experience (the HEART framework)

● The goals of your product or project (the Goals-Signals-Metrics process)

Simply put HEART stands for:

1. Happiness: Basically, you need measures of user attitudes, which are often collected via
surveys. For example, satisfaction, perceived ease of use, and net promoter score.
2. Engagement: It measures the frequency, intensity, or depth of a user’s engagement with your
product. How many users have visited the product in the last 7 days?
3. Adoption: It is quite simple and usually refers to the number of users who use a feature or
product for the first time.
4. Retention: It measures returning users’ continuous, repeated engagement with the feature or
product over time. This allows you to track how often people use your product or feature, or
buy your new offerings, etc.
5. Task success: After onboarding, you may want to track whether the user can achieve their
goals with your product or new features. Task success refers to the efficiency, effectiveness,
and error rate of a user completing a task with your product’s workflow.

19
To use this framework, a team will identify goals, signals, and metrics for each of the five categories
of HEART, as shown in the figure below:

Testing
Although it has historically been primarily a tool of marketing and advertising, testing can also help
product managers build better products. Certain types of testing commonly used by PMs are:

1. A/B testing involves splitting your audience/user base into two groups. This can be done by
running a 50/50 split test if your user base is currently very small, or taking a sample size
from a larger user base.The two groups then receive two versions of a feature. It could be
something as small as a different call to action button color, or it could be a re-ordering of
your onboarding sequence. After a certain amount of time (which will differ depending on
the test/product/goal etc) a product manager will look at the data gathered to better
understand which version should be rolled out to the entire user base.

2. The principles of multivariate tests are similar to A/B tests, but while A/B tests only change
one variable at a time, multivariate tests experiment with many variables or multiple segments
of the user base. Multivariate tests try out different combinations of variables to determine
which is the most effective.

20
 3. In tree testing methods, users are shown a streamlined sitemap with tree-like hierarchies.
Then they're asked to complete specific tasks that test how easy it is to access the product
functionality they need and offer insights into its navigability.

4. Card sorting tests ask a group of test users to sort product or website navigation items into
the categories they think make the most sense. In closed card sorting tests, users are given
fixed categories and decide where to place each navigation item. In open card sorting tests,
users create categories that seem logical to them.

What is a PRD?
A PRD is a document that describes the purpose, features, functionality, and behavior of the product
you’re about to build.

A product requirements document (PRD) is an artifact used in the product development process to
communicate what capabilities must be included in a product release to the development and testing
teams. This document is typically used more in waterfall environments where product definition,
design, and delivery happen sequentially, but may be used in an agile setting as well.

The PRD will contain everything that must be included in a release to be considered complete,
serving as a guide for subsequent documents in the release process. While PRDs may hint at a
potential implementation to illustrate a use case, they may not dictate a specific implementation.

The following is a basic outline of what should be included in a PRD. There are no hard-and-fast
rules for this, but these items are typically present:

● Objective/Goal: Explain why are you building this and what do you hope to accomplish.
● Features: For each feature, you should include a description, goal and use case at a minimum.
Additional details may be helpful or necessary depending on the complexity of the feature,
such as out-of-scope items.
● UX Flow & Design Notes: Most organizations complete the UX design of features after the
PRD has been reviewed and accepted. However, there may be some general guidance
required at this stage to ensure the release objectives are met. This is not the place for pixel-
perfect mockups or wireframes that map out every possible scenario; instead, it can be used
to describe the overall user workflow.
● System & Environment Requirements: Which end-user environments will be supported (such
as browsers, operating systems, memory, and processing power, etc.).

21
 ● Assumptions, Constraints & Dependencies: List out what is expected of users, any limits for
the implementation to be aware of and any outside elements required for the final solution
to be functional.

To know more about how to write a PRD in detail, visit: https://plan.io/blog/one-pager-prd-product-

requirements-document/

Product Management Cases (For Interviews)

A case study interview, also known as a case interview, is a tool used by many companies to assess
a candidate’s analytical, creative, and problem-solving skills.
Quite simply, you’ll be given a situation, and asked to make suggestions or come up with a
hypothetical solution or improvement.

In product management, this can be about any number of things. The realm of product managers is
vast, and covers many different aspects of product development. As product managers sit at the
intersection of business, technology, and design, you could be asked case questions under these
umbrellas.

There are broadly three types of product management cases that are asked in interviews:

Design a Product
A product design question in an interview is mainly to judge the person’s range of view and the
aspects that they cover in a holistic manner as they should being a product manager.
Example: How would you design a bicycle renting app for tourists?

Approach:

Step 1: Business Objective

● Ask clarifying questions and define the business objective
● Outline your approach so you’re on the same page
Step 2: User Problems
● Select a user type
List the types of user personas concerned and select one with a befitting reason.
● List user problems
Once a user persona has been selected; define the goals and pain points.
● Prioritize user problems
Step 3: Solutions/Features
● List solutions
As per prioritization of the listed problems, define features or solutions that would work.
● Prioritize solutions
Use frameworks such as RICE, MoSCoW etc
Step 4: Evaluation
● Define the success criteria (metrics, KPIs) for each solution
● Mention the risks involved

22
Design Examples:
https://www.youtube.com/watch?v=Axa7gx1lKqA
https://www.youtube.com/watch?v=JPuPmywi8Ew
https://www.youtube.com/watch?v=NtMvNh0WFVM

Root Cause Analysis

Here, information is limited but the problem is clear and identified. The real challenge is to list and
narrow down the number of possibilities by elimination and interaction with the interviewer.
Example: You are the PM for a streaming video service. You come into the office and see that one
key metric has dropped by 80%. What will you do?

Approach:

1. Make sure everyone is on the same page

Before jumping on to solve a problem, make sure that all the key terms used to define the
problem are clearly understood by all stakeholders.
2. Verify the metrics defined in the problem
It is very well possible that a wrongly defined threshold value could be causing these spiked
values to show up on the user analytics report. It is also possible that the analytics being
drawn up are polling the wrong set of devices. Thus, doing a quick double-check on the
veracity of the metrics presented in the problem statement, would allow you to clearly see if
a problem actually exists and to dispel any false-positives right at the start of the RCA process
without wasting any further time or resources.
3. List out any recent changes
A good place to start identifying the problem, would be to check when the problem was first
spotted. Doing so would allow you to gain insights on the problem's origin. It would also
give you a rough timeline to potentially observe patterns that could give a clue on what
might have caused the problem. Most importantly, it will allow you to list out all the changes
that were made around that time that could have potentially impacted the product feature.
4. Cover all major endpoints
Any user interaction with a product can be broken down into the buckets of input, process
and output. Analyzing the user-flow through each of these segmented endpoints would allow
you to derive insights on the problem. Following this flow will help eliminate problem
domains in a step-by-step manner.
5. Check for the demographic being impacted
When a problem is faced, it is general good practice to understand which group of end users
the problem really impacts. Is this a problem faced by all users alike or is this something
faced only by a specific subset of people? Is there a common demography (based on age,
sex, gender, access or location) of people where this issue is observed in?
6. Check for external factors
Some problems could be caused due to changes made by external agents, new campaigns
or announcements by competitors or larger macro-economical factors. For instance, if your
video streaming product's analytics team identifies that the number of monthly subscriptions
to your service has gone down by 30% in the last few weeks, it may well be that the drop
had nothing to do with you product itself. It may be that your competition has sliced their
subscription fee causing more people to move to their product.

23
 7. Check for internal factors
After going through the above steps, it is now time to revisit each of the factors that you
CAN influence as a PM. Check where the issue is occurring exactly. Is it specific to users on
a particular device or users running a certain version of the software? If so what are the last
few changes done on that particular feature/workflow? Was there any change in user flow
that could have led to the problem?
8. Follow a top-down approach
When isolating an issue, explore all potential options and then dive down into the most likely
ones after ascertaining each level of information pertaining to the problem. Segment the
problem into subproblems and explore each of those sub-problems in further detail. When
doing so, determine which of these sub-branches can be ruled out completely, as and how
we gather more data insights. Explore down the branches that are not ruled out and
iteratively apply the process until the Root Cause is identified.

RCA Example:
https://www.youtube.com/watch?v=DSV-vuvmIro

Practice Resources
• Product Manager Interview Questions | Product Management Exercises
• Interview Questions - Exponent (tryexponent.com)
• Mock Product Management Interviews - YouTube

References:
• https://drive.google.com/file/d/1i-qms-XmNMofRgBaEOl6b3GyZd5nTqLh/view
• https://www.mindtheproduct.com/measuring-the-right-north-star-metric/
• https://uxdesign.cc/googles-heart-framework-choosing-the-right-metrics-for-your-product-
112bd7300d55
• https://www.productplan.com/glossary/product-requirements-document/
• A Root Cause Analysis Framework for Product Managers | LinkedIn

24