This repository documents my journey through a #30DaysofPM challenge. Each day, I delve into different aspects of Product Management, from understanding user needs to collaborating with development teams.
An Octopus Connecting All Parts: I like to think of a PM as an octopus connecting all the parts of the product to make it work well.
Varied Types Depending on the Product: The type of person that better fit as a PM can differ significantly depending on the product. For instance, an API product manager needs more technical skills, whereas a consumer focused product manager for a service like Instagram needs to focus more on customer data and market.
- Research and Make a Plan: Start by understanding the problem, then gather data about the market, users, competitors, etc., and plan how to solve it.
- Design and Spec: Detail the specifications for the product to be built.
- Implement and Test: Here, engineering does their job while the PM guides the shape of the product and provides feedback.
- Release and Go To Market: In this phase, the PM gathers user feedback and analyzes data to prepare for the market launch.
Using the data and market responses, the PM takes cues on how to improve the product and what to do in the next cycle.
Today, it was covered some of the myths around Product Management, the conclusions mentioned were:
It might be different from company to company, and even from product to product. For example, in a small startup, you might be the only PM, and you will have to do everything from research to design and implementation. In a large company, you might be a PM for a specific feature, and you will have to work with other PMs to make sure the product is cohesive.
PMs are not CEOs, they don't have the final say on the product, and they don't have the power to make decisions on their own. They don't have authority over most of the things. Although, some senior PMs can hire/fire people over their direct reports.
PMs are not only managers, they are also people who do the work. Sometimes everything that nobody else wants to do or doesn't know how to do, goes to the PM. They are the ones who have to figure out how to do it.
While building the product is a big part of the job, it's not the only thing that PMs do. There are many other things that PMs do, like talking to customers, doing research, analyzing data, etc.
Although PMs can have ideas, everyone else can have ideas too. In fact, most of the time, the best ideas come from other people, not from PMs.
PMs don't have to be technical, although it might help if they are, but there are a lot of other skills needed to do the job well, like focusing on the user, understanding the market, etc.
PMs don't just release the product and then move on to the next one. They have to keep working on it, improving it, gathering feedback, making sure that it's successful, etc.
They are needed in other industries too, like healthcare, finance, etc. The real job is to solve problems, and there are problems everywhere.
It requires a lot of work, be attentive to every product meeting, have context on everything, come with solutions, understanding a lot of things, etc.
It's the process of going from knowing the user's problem to building a product that solves it.
It's when there is a clear need for the product in the market, and the product is the best solution for that need.
- Understand the problem: This can be done by talking to users, doing research, etc.
- Market Opportunity: Research if there is an opportunity in the market for the product, how big is the market, how much money can be made, etc.
- Solution: Sometimes it might come with multiple solutions, then it needs to choose the best one, considering: ROI, limitations, alignment with the company's goals, etc.
Business goals are important, some of them are:
- Increase revenue
- Increase profit
- Increase market share
- Increase market share
The PM is key in order to keep reaching and increasing them.
Although PMs are not responsible for the business goals, they are responsible for the product outcomes, which can lead to the business goals. Some examples:
- Increasing revenue by increasing the conversion rate to paid user
- Increasing profit by reducing the cost of the product
- Improving product quality
- Enhancing the user experience
etc.
Business outcomes come from product outcomes.
Many PMs don't understand the real problem that the user has, or at least all the problems.
The "Why" framework is a way to get to the root of the problem. It consists of asking "Why" multiple times until you get to the root of the problem. That number is just indicative, sometimes even 3 times is enough.
Case 1: The user often experiences the app crashing and slow performance.
1st Why? Answer: The server storage is insuficient.
2nd Why? Answer: The server is not scaled to support increasing user demands.
3rd Why? Answer: The wasn't monitorization of the server usage and perfomance optimization.
4th Why? Answer: The team didn't have visibility of the server usage.
5th Why? Answer: The didn't have the tools to monitorize the server usage.
Root Cause: The team didn't have the tools to monitorize the server usage, preventing them to know when to scale the server.
Case 2: The app crashed again.
1st Why? Answer: It was pushed a new API to the server recently.
2nd Why? Answer: Because we launched a new feature that probably didn' use the API correctly.
3rd Why? Answer: We have an engeenering who doesn't know how to use the API.
4th Why? Answer: He never was trained on how to use the API.
5th Why? Answer: The manager wanted to get him in production as soon as possible.
Root Cause: Untrained engineer was pushed to production.
- Listen more than you talk.
- Formulate open-ended 'why' questions.
- Be ready to challenge the assumptions, encourage critical thinking.
- Iterate and refine. As you encounter the root cause, re-evaluate everything to make sure you are getting the deepest root cause.
Product discovery is the process of understanding the problem, the user, and the market.
Product Thinking = A broad framework considering the entire product.
Product Discovery = it's more focused, dealing with validating the specific ideas and features, backed by data.
It's like a topic within Product Thinking.
- Empathy and Understanding: Understand the user's needs and emotions.
- Clarifying the problem: Nail down one sentence that covers the entire problem.
- Make sure you are solving the right problem: How big is the problem for the user.
- Priorating the problem: What user's problem to solve first.
- Reframing the problem: Reframe the user's problem into chunks that can be solved, then figure out a plan to solve them.
- Prototyping: Create a prototype to quick test the solution with the users.
- Verify the tests: Verify the tests with the users to analyze if the proposed solution is solving the problem.
It's a mindset approach to solve problems in a creative way focusing on the person who has the problem.
So it's a way to solve problems in a user-centric way, instead of problem-based.
- Empathize: By understanding the person affected by the problem you can find a more impactful solution. It uses also data through the research.
- Define: Once you have accumulated enough data, you can define the problem statements. There are a lot of methods to do it.
- Ideate: Brainstorming ideas to solve the problem.
- Prototype: Create a prototype to investigate the ideas.
- Test: Test the prototype with the users to see if it solves the problem. This phase is experimental, so it isn't about perfection, but seeing which parts work and which don't.
It's a framework to understand the user's needs and real motivations when using a product.
When I ... (context)
But ... (barrier)
Help me ... (goal)
So I ... (outcome)
- Clear audience definition: Narrow down the audience to a specific group of people, with clear characteristics, without risk of being too broad.
- Do market research: Understand the audience, what they currently are using to solve the problem and where they feel the most pain.
- Talk to the users: Using surveys, interviews, etc, identify the user's mindset and decision process.
- Prioritize the JTBD: Prioritize the JTBD based on the user's pain points and the business goals.
When I want to play a game
But I don't know if there are people around to play,
Help me to coordinate with other people to play,
So I can easily find a way to enjoy my favorite game.
This suggest features like making it easy to find people through the search serves and switching easily from text to voice chat.
Some benefits of doing user research (talk to users):
- save development, time and redesign costs
- increase the chances of user satisfaction
- increase conversion rates
- gets qualitative feedback
- help to understand what matters to the user
- gain competitive advantage
- help to make product easier to use, shorter learning curve for the user
- improve UI/UX
- Qualitative research: It gets direct feedback from the users. Ex.: interviews, focus groups, etc.
- Quantitative research: It gets data from the users. Ex.: surveys, analytics, etc.
- Attitudinal: listening to users' words, ex.: interviews, focus groups, etc.
- Behavioral: observing users' actions, ex.: watching users using the product, A/B testing, etc.
- Studying data: if you collect data, then you can analyze it to understand the user's behavior.
- Usability testing: watching users using the product to understand how they use it and what problems they have.
- User interviews: usually 30min to 1h, speaking to one user at a time, face to face or remotely. Misunderstandings can be clarified immediately. A downside is that it's time-consuming and expensive.
- Online surveys: some questions to a large number of users, to identify patterns. It tells an average of the user's behavior.
- Structured: You follow a list of questions. Sometimes even a script. The collected data is more quantitative.
- Semi-structured: It's more flexible, you prepare a list of questions but they can be adjusted during the interview.
- Exploratory: Open-ended questions, it flows as a natural conversation. Useful to uncover new insights.
- Define the goal and scope: What do you want to learn from the user? Plan the questions accordingly.
- Find participants: Find people who fit the target audience. Don't ask friends or family, they might be biased.
- Give participants context: Explain the purpose of the interview and scope, but don't give too much information that might bias the user.
- Analyze the data: After the interviews, analyze the data to find patterns and insights.
- Summarize in personas: Use the insights from the interviews to create personas.
- Follow up: After the interviews, follow up with the participants to thank them, let them know how their feedback will be used and keep them updated about the project.
- begin with a brief introduction: "Hi, this is _____, from ____(company)___. Is it a good time to talk?"
- thank the user for their time and tell how important it is: "First of all, I'd like to thank you for talking with me today. It's incredible valuable for me to get, to listen to you talk to me through your personal experience and how things work (and don't work) in your world, so I really appreciate it."
- ask an overview question: "Could you start by telling me a little bit about how you _____(perform general task)_____ currently?
Dividing the users into groups based on their characteristics.
it helps to understand each group needs and behaviors, so you can tailor the product to each group.
sometimes it's not possible to satisfy all the users, so it's important to know which group to focus on.
per example, if you only can add 3 new features to a community swimming pool (product example), you should focus on the group that uses the pool the most, and features that benefit also the other groups.
example of choosing the new features:
Types of user segmentation:
- Demographic: gender, location, age, income, language, etc.
- Device: mobile, desktop, etc.
- Acquisition source: how the user found the product, ex.: social media, search engine, etc.
- Usage patterns: how often the user uses the product, how long, etc.
it's a fictional character that represents a group of users.
well-defined personas help to address the user's needs and behaviors.
- who is my ideal customer?
- what are the current behaviors of my ideal customer?
- what are the goals of my users?
- what issues do my users face?
- Who is the uses? demographic data.
- What are the user's goals? what the user wants to achieve.
- What are the user's pain points and challenge? what are the user's problems.
- Activity and experiences of the user: what the user does, what the user likes, etc.
- Name: Sakshi
- Age: 23
- Location: Lives in Bangalore, India
- Profession: Works as a software engineer full-time
- Goals: Wants to migrate to Product Management role
- Pain points: Doesn't know how to get started
- Activity and experiences: Spends her time on Linkedin and Twitter interacting with people in tech.
It consists of analyzing all the data collected from the user research and finding patterns and insights.
Besides understanding the data, a PM needs to be able to communicate it to others.
Empathy map is a tool to visualize and communicate the data in a quick way.
- Says: it's what the user says directly.
- Thinks: it captures what user is thinking throughout the experience.
- Does: it's what the user does, their actions.
- Feels: it's the emotion state of the user.
- it helps to categorize and makes sense of qualitative research.
- discover gaps in the current research.
- it helps to create personas.
It's a clear and short description of the problem that the product is trying to solve.
- focus on the problem, not the solution.
- inspire the team to solve the problem.
- prevent misunderstandings.
have a clear problem: it should be clear what the problem is.
explain the relevance of the problem: needs to communicate why it matters to the business and the potential dangers if it's unsolved.
Some questions that might clarify:
- who will feel the consequences of the problem?
- what is the impact of the problem?
- does the problem affect other areas of the business?
- does the problem impact wider society?
- how solving the problem increase our understanding of the business?
back the problem with data: use data to back up the problem and make it evident to everyone.
- Problem: describe the problem in one sentence.
- Backed by data: use data to back up the problem.
- Relevance: explain why the problem matters.
- Objectives: in your conclusion, propose solutions to the problem based on your research and understanding of it.
It's the third step of the Design Thinking process.
It's not about finding the best solution, but generating as many ideas as possible.
While there are many ways to generate ideas, one of the most popular is the "How Might We" framework.
It's a way to reframe the problem into a question that can be answered with a solution.
Problem: I want to go to the supermarket.
How might we: make it easier to go to the supermarket?
Solution: I can order online and get it delivered.
Problem: Users are not engaging with the app.
How might we: increase user engagement?
Solution: Add a new feature that users will like.
It's a way to visualize the user's journey through the product.
- it helps to understand the user's journey.
- it helps to identify problems and opportunities.
- it helps to communicate the user's journey to others.
- define the user's goal: what the user wants to achieve.
- define the user's journey: what steps the user takes to achieve the goal.
- identify problems and opportunities: what problems the user faces and what opportunities there are to improve the user's journey.
It's important to validate the ideas before investing time and resources.
-
Is the idea solving the right problem?
You should think if it's a product that should be built.
Also, if it's possible to create a business around it. -
Is the idea solving the problem in the right way?
-
Is the idea solving the problem in the right time?
- Sign-up page: create a sign-up page for the product and see how many people sign up.
- Landing page: create a landing page for the product and capture the user's email, and see how many people sign up.
If you don't get enough sign-ups, it might be a sign that the idea is not good.
It's a minimal version of the product that has only the essential features.
As a PM, it's important to understand the principles of design and having a good eye for design.
Everyone can tell if something is well designed or not, but not everyone can explain or express why.
Principles of design can help to understand why something is well designed.
-
Scale: it's the size of the elements. In other words, most important elements should be bigger than less important elements.
-
Visual hierarchy: it's the order in which the user's eyes perceive what they see.
It can be implemented through scale, color, contrast, placement, etc. -
Balance: it's the distribution of the visual weight of the elements.
It can be symmetrical or asymmetrical. -
Contrast: it's the difference between the elements, ex.: light and dark colors.
-
Gestalt principles: it's a set of principles that describe how the human eye simplifies and organizes complex images.
It's a visual guide that represents the skeletal framework of a website or digital product.
It's an easy way to communicate the layout of the product.
Way better than a written description.
You still might need to explain the wireframe, but it's easier to explain a visual than a written description.
It's a way to compare two versions of a product to see which one performs better.
In this way, you can get feedback from the users even without their active knowledge.
- Color of the button: you can test if the color of the button affects the user's behavior.
- Call to action: you can test if the call to action affects the user's behavior.
- Social proof: you can test if the social proof affects the user's behavior.
- Images: you can test if the images affect the user's behavior.
- Layout: you can test if the layout affects the user's behavior.
- Pop-ups: you can test if the pop-ups affect the user's behavior.
- Pricing: you can test if the pricing affects the user's behavior.
- Badges: you can test if the badges affect the user's behavior.
- Announment bars: you can test if the announcement bars affect the user's behavior.
- Define the goal: what you want to achieve with the A/B test.
- Look at your current data: to understand the current user's behavior.
- Create the variations: create the two versions of the product.
- See the results: see which version performs better.
For testing, you can make the change for something like 20% of the users, and see how it performs.
Even if there is a good change, but still a small difference, like 5%, it might not be worth to make the change.
It's a assumption that you can test.
- State the problem: what is the problem that you are trying to solve.
- State the solution: what is the solution that you are proposing.
- State the expected outcome: what is the expected outcome of the solution.
- Problem: users are not engaging with the app.
- Solution: add a new feature that users will like.
- Expected outcome: users will engage more with the app.
It's important to define the metrics that you will use to measure the success of the product.
It's a measurable value that demonstrates how effectively a company is achieving key business objectives.
- Acquisition: how many new users are you getting.
- Activation: how many users are using the product.
- Retention: how many users are coming back each day/week/month.
- Referral: how many users are referring the product to others.
- Revenue: how much money the product is making.
- the main metric that the company uses to measure the success of the product.
- they contribute directly to the NSM.
- they contribute indirectly to the NSM.
- they indicate that the product is moving in the right direction.
- DAU (Daily Active Users): how many users are using the product each day.
- MAU (Monthly Active Users): how many users are using the product each month.
- Churn Rate: how many users are leaving the product.
- Conversion Rate: how many users are converting.
- Bounce Rate: how many users are leaving the product after visiting only one page.
- Session Duration: how long the user is using the product.
- Average Revenue Per User: how much money the product is making per user.
- Net Promoter Score: how likely the user is to recommend the product to others.
- Customer Acquisition Cost: how much money the company is spending to acquire a new user.
- Customer Lifetime Value: how much money the company is making from a user over their lifetime.
- Retention Rate: how many users are coming back to the product.
- Awareness: how many people are aware of the product.
- Acquisition: how many new users are you getting.
- Activation: how many users are using the product.
- Engagement: how many users are engaging with the product.
- Revenue: how much money the product is making.
- Referral: how many users are referring the product to others.
It's a way to understand the flow of the user through the product up to the conversion.
- Step 1: user opens an email and see your offer.
- Step 2: user clicks on the link and goes to the landing page.
- Step 3: user clicks on CTA and goes to the sign-up page.
- Step 4: user signs up and uses the product for free.
- Step 5: user becomes a paying user after the trial expires.
It's a way to understand how different groups of users behave over time.
- Cohort 1: users who have notifications enabled.
they might have a higher retention rate.
A way to define and track objectives and their outcomes.
- Objectives: what you want to achieve.
- Key Results: are how you will accomplish it.
A framework to help on prioritization, it evaluates an average rate for a feature or project.
- It's more enjoyable to work on personal favorite projects rather than on ones that benefit a lot of people.
- It’s tempting to focus on clever ideas, instead of projects that directly impact your goals.
- It's more appealing to explore new ideas than to focus on projects you're already sure about.
- It's easy to underestimate the extra effort some projects require compared to others.
- realistic estimate how many people each project will affect within a given period.
- how many impact it will have on costumer.
- it measures how much confident you are with this and your estimatives.
- estimate the total ammount of time a project will require from all members of your team.
It outlines the purpose, features, and functionality of a product to guide its development.
Different teams use the PRD to know better the product for each specific purpose.
- 1. Define the product: summarize your plan, purposes, description, target audience, the buyer person, how the product create values, etc.
- 2. Determine goals: write the objectibes for the product development process.
- 3. Identify assumptions and constraints: identifying those assumptions and constraints that you will meet during the product development process helps you to be more precise and have right expectations.
- 4. Limit the scope of work: defining boundaries will help to keep the project on track and the team focused.
- 5. List features: defining primary features helps to see how users will use the product.
- 6. Define released criteria: those are the criteria that will make the product ready to be released. It helps to make you confident that you are launching a quality project that will target audience excited to use that.
- 7. Set metrics for sucess: metrics that will let you know that you are in the correct path.
It's a way to generate growth for the product in a repetitive way.
- Step 1: user subscribes to a 30 Days of PM newsletter.
- Step 2: user reads the newsletter and shares it on Twitter daily.
- Step 3: user's followers see the tweet and subscribe to the newsletter. (back to step 1)
Loops are sustainable and scalable. It creates a compounding effect.
Not all loops are created equal, and not all loops are sustainable.
A strategy to grow the product by focusing on the product itself.
The idea is that the product by itself can generate growth by being a good product.
In a Sales-Led model, the monetization happens before the engagement.
In a PLG strategy, the engagement happens before the monetization.
- Calendly
- Slack
- Notion
- Typeform
- Acquisition: number of users who signed up for a free experience.
- Activation: number of users who have a successful first experience.
- CLV - Customer Lifetime Value: how much money the company is making from a user over their lifetime.
- TTV - Time to Value: how long it takes for a user to get value from the product, reaching his activation moment. The goal is that the time is as short as possible.
- Free to Paid Conversion Rate: the percentage of users are converting from free to paid.
- Expansion Revenue: how much money the company is making from the already existing users. It helps to compensate the cost of churn.
- Net Revenue Churn: how much money the company is losing after the expansion revenue.
- ARPU - Average Revenue Per User: how much money the product is making per user.