Product Managers

The product manager is the driving force behind each phase of the product lifecycle, ensuring that the product is successfully launched and continuously optimized. This role requires a deep understanding of how the product works, what is feasible for the company and the team, and a strategic approach to problem-solving that balances user needs with business constraints.

Core Responsibilities:

💥Product Expertise:

👀Solution Exploration:

✍Detailed Documentation:

👣Lifecycle Management:

🔥Feature Delivery and Success Tracking:

Cross-Departmental Collaboration:

Essential Skills:

👩‍🌾👵👩‍🎤Stakeholder Management:

💫Research:

🧠Critical Thinking:

Assess challenges and opportunities with a strategic mindset, identifying the best course of action for the product's success.

Understand details about the product and the limitations and own the solution.

Ownership:

Staying up to date and monitoring competitors is an ongoing process. While a product manager may set aside specific times of the year to reevaluate everything, it's crucial to stay informed continuously. Set up Google alerts and follow competitors on other platforms to stay updated on new features and press releases.

There are two key things to do when evaluating your competitors. Let's go over them!

First, assess their overall position in the market. Determine how much investment or funding they've received, who their team members are, and how much effort they put into design, quality, and innovation. Additionally, evaluate their market share. You're also trying to understand how they aim to differentiate themselves, so look into their value proposition, messaging, brand values, and mission. You can use a table to organize and compare these factors.

Next, evaluate key features, usually by rating them on a scale from 0 to 5. A rating of 0 means they lack a particular feature, 1 indicates that it's not quite the same or doesn't solve the problem effectively, while a 5 represents the best solution in the market.

This evaluation can be subjective, especially when people value functionality over design, or vice versa. These discussions may be lengthy, but it's important to assign ratings and document your reasoning - what makes each feature unique and why each brand received its rating. Notes are crucial, as your perception may change over time.

These are two essential steps in market research. It's also encouraged to consider the following:

Part of the Discovery Phase

The discovery phase is where everything starts, which is why the product manager needs to spend sufficient time thinking about the underlying problem, understanding how it affects all users and even team members, and defining the root cause and the pain it creates. It is imperative that the problem is fully understood because often, product managers are trying to validate whether the solution truly solves the problem. However, junior product managers sometimes build solutions that don't focus on the core problem and are merely "nice to have."

If you're unsure how to approach defining a problem, you can use a well-known framework called the Fishbone Diagram, or ask yourself the following questions:

Watch this video if you want to learn more.

Part of the Discovery Phase.

When the product manager has a general idea of the problem and has tried to define and understand it, they often need to lead a more facilitated discussion with stakeholders to understand their requirements, needs, and expectations. Sometimes, this also helps uncover what is truly important to stakeholders, while bringing awareness to aspects that are secondary or unrelated to the problem being solved.

These conversations often begin with open-ended questions such as, "Can you describe this problem and when it happens?" or "How do you imagine the solution?" By asking these questions, product managers often discover that stakeholders haven’t spent much time exploring the solution or understanding why they feel the way they do—sometimes revealing that the real issue may be something else. These questions are great for starting the conversation and assessing whether the product manager has misinterpreted anything, but they typically don’t help define the solution.

Once those initial questions have been asked, the product manager needs to get more specific. Sometimes, the product manager compares potential solutions by asking questions like, "Do you imagine this happening like this or like that? Why?" They may also reframe the problem to ensure they understand it correctly: "So from what I'm hearing, the issue is that... and the expectation is to... so that you can..."

Next, they should evaluate the exact expectations by identifying key features and ideas and asking stakeholders to rank how important those are. By the end of the meeting, the product manager should share their notes and ask questions like, "These seem to be the most important requirements—am I missing anything?" or "Is there any other stakeholder I should involve to ensure their perspective is considered?" and "Are we missing any use cases?" Finally, they can ask, "Is there a type of user that should be treated as an exception?"

At this point, the product manager (PM) has at least the initial list of requirements defined and can begin exploring potential solutions to validate whether they solve the problem. The PM can approach this in various ways, such as discussing ideas with the design and development teams, exploring new technologies, or seeking inspiration with the help of the design team.

At this stage, the PM and the rest of the team should explore at least two potential approaches and ask themselves critical questions, such as:

👉During this period, it is normal for many questions to arise, and the product manager may need to contact stakeholders to confirm and evaluate assumptions. This is completely normal. It's essential for the product manager to take notes on what each stakeholder says, so they can prioritize and weigh the importance of certain requirements.

Defining an epic is much more than just a task—it can require multiple sessions, thought processes, and evaluations. It typically starts by defining the problem, the solution, the assumptions, the potential metrics to measure success, the user stories, the limitations, the users who will be affected or excluded, the type of support and training the team will need, and the specifications for how it should work. Additionally, a user story map may be created to outline the process, requirements, and which requirements will not be prioritized this time.

This process often begins on a whiteboard for discussion, drawing, and mapping out ideas like the user story map. Once all user stories and requirements are finalized and reviewed by the development team, the product manager will input them into the platform used as the source of truth, typically Jira. In Jira, the requirements, user stories, and all related links will be accessible to the development team. We will discuss a few more details about this later.

🔥During this phase, when the product manager is working on a draft, the goal is to define all the assumptions, success metrics, requirements, and use cases with their scenarios. This allows them to share this with the design team and then to double-check the requirements with stakeholders. Essentially, this draft is used to prepare for a meeting with stakeholders to discuss any missing use cases, additional requirements, or elements that may not be important at the moment.

As mentioned earlier, sometimes the product manager wants to ensure they aren’t missing any requirements, use cases, or exceptions. To do this, they may ask the design team to create a mockup or sketch, followed by a quick conversation with stakeholders. During this discussion, they might ask questions such as:

This can be a good approach👇

Before or after the design phase begins, or even at both times, the product manager needs to evaluate the solution, considering what is feasible and what is not, what might cause delays, the potential cost of the initiative, and the return on investment. They should also consider any alternatives, such as:

Once the requirements are clear, potential alternatives have been considered, and discussions have taken place about how the changes could affect different user types and scenarios, including exceptions, the product manager will take all the notes from the whiteboard or draft document and add them to the source of truth for developers, typically Jira.

Once all the details are finalized, the designer will begin the design phase. This phase is much more than just creating designs; it involves multiple sketches, considerations, and a back-and-forth process between developers, product managers, and designers to evaluate what is most effective and easy to implement. Designers may also look for inspiration, create components, mockups, gather feedback, and even develop prototypes. They often define how the platform will work, including what they call the "happy path," and create user flows. These are shared with developers for feedback and then added to the epic.

When the team has finalized the design and requirements, and they are reasonably confident about the feasibility, it’s time to share these with stakeholders. This gives stakeholders a final opportunity to evaluate whether the solution meets their needs and allows the product manager to ensure nothing is missing. The same applies to the designer. This stakeholder meeting is essential and can be done asynchronously, but it’s key for product managers and designers to take a proactive approach—asking plenty of questions to get people thinking and to help them spot gaps they might otherwise overlook.

At this stage, it's not about presenting the solution as final. The mindset of the product team and designers should be:

"What’s wrong with it?"

"What are we missing?"

"Do we really need this now?"

"Are there any risks?"

"What do we need to succeed?"

👇This can be an approach.

When stakeholders provide their feedback and changes are made, it’s often time to get the design and requirements approved. Sometimes this step isn’t necessary, but often managers want to approve it, or clients need to approve it before moving to the development phase.

When the development phase begins, it often starts with a grooming session, followed by as many meetings as needed to go through the details and expectations. Developers then start implementing the requirements one by one. As they make progress, they frequently share updates with the product manager and designer. If any issues arise with the designs, they are discussed and resolved by the designer. Once development is completed, QA performs testing, and the designer also tests the new release to ensure it aligns with the design. It's normal for changes or bugs to surface, but once the team feels confident with the status, they proceed with the release.

Right after an initiative is launched, the product manager leads a team retrospective to identify areas for improvement. Product teams maintain a mindset of continuous improvement, knowing they can learn from every initiative.

On the business side, the product manager also needs to determine when to review the results to validate whether the solution is positively impacting the company and users, and whether it solves the problem. Additionally, they must assess if the solution needs to be removed, changed, or improved based on those results.

It's important to note that a feature is never truly "done." As technology evolves, design trends shift, and users' needs change, there is always room for improvement. Therefore, it's crucial for product managers and their teams to know how to identify the core problem, define their design criteria and values, and determine when and how often improvements can be made based on available resources. This is especially challenging for designers, who often want to create the perfect solution, which may be too costly to implement.

One of the key objectives of product teams is to fully understand their user personas—their needs, wants, dreams, fears, and blockers. This understanding doesn’t develop in a day, and product managers are constantly adding to their knowledge of user personas and learning about their users.

This means that user personas are never "finished" but are always evolving and improving.

But why is this so important?

When a product manager understands their user personas, they can use empathy to better grasp what users need. More importantly, they can identify the difference between what a user says they want and the actual root problem. Solutions in any product must be defined by addressing the root problem and fully understanding the user’s need or pain, rather than accepting a user’s symptom or recommendation as the best solution.👀

It’s the product manager's responsibility to dig deeper and get to the bottom of the problem—understanding how it is created, who is affected by it, how often it occurs, how important it is to solve in relation to everything else, and which edge cases may be positively or negatively impacted by any changes.

When creating a user persona, certain elements are often the most important, but this can vary for each team and organization. Creating a user persona isn’t about simply filling out a template; it's about understanding what makes that user persona your user, while someone with almost the same characteristics might not be.

Focus on the factors that help define this distinction. Here are some key aspects to consider:

When creating a user persona, it's common for product managers to make assumptions. This is often the starting point of a user persona, and that's okay. It’s fine to have a whiteboard filled with sticky notes about your user persona based on assumptions. However, it’s crucial to differentiate between assumptions and facts, and evaluate which assumptions are too risky or important for the current initiatives you're working on.

For instance, when you talk to a user or hear insights from the sales team about a user, you can add that information to the user persona. However, use different colors to identify assumptions (what I like to call "rumors") versus facts.

Continuously add more information as you go, and use methods like user surveys, interviews, social media, and news sources to gather factual data about your users.

Both the HEART framework and the AARRR framework are popular models for measuring success, but they serve different purposes and are best used in specific contexts. Here’s a detailed explanation of how each works, when to use them, and common pitfalls to avoid.

The HEART framework, developed by Google, is designed to measure user experience and is particularly useful for products with a focus on usability and engagement.

While, the AARRR framework (also known as the Pirate Metrics) is a customer lifecycle model focused on growth and revenue generation, commonly used in startups and marketing.

Combining the Frameworks

• Use HEART to ensure a smooth, satisfying experience for users (qualitative success).

• Use AARRR to track growth and conversion metrics (quantitative success).

The HEART framework, developed by Google, is designed to measure user experience and is particularly useful for products with a focus on usability and engagement.

HEART is an acronym for five key metrics:

User-Centric Products: Ideal for digital products or services where user experience is critical.

• Feature Rollouts: Use to evaluate the impact of new features.

• UX Improvements: To identify areas for optimization in existing products.

What Not to Do

• Neglect Qualitative Data: Only focusing on numbers can miss deeper user insights.

• Overload with Metrics: Tracking too many metrics can dilute focus. Choose those most relevant to your product goals.

• Ignore Context: Metrics should align with specific product goals, not generic benchmarks.

The AARRR framework (also known as the Pirate Metrics) is a customer lifecycle model focused on growth and revenue generation, commonly used in startups and marketing.

AARRR stands for:

1. Acquisition: Tracks how users find your product. Example: Website traffic, app installs, click-through rates.

2. Activation: Measures how many users have a meaningful first experience. Example: Completed onboarding, first purchase, or first use.

3. Retention: Tracks how many users return over time. Example: Repeat visits, returning customers.

4. Referral: Measures how many users refer others. Example: Referral links clicked, invitations sent.

5. Revenue: Tracks how the product generates income. Example: Subscriptions, in-app purchases, or upgrades.

When to Use

• Startup Growth: Ideal for early-stage companies focused on acquiring users and scaling quickly.

• Marketing Campaigns: To track funnel performance and conversions.

• Revenue Optimization: To understand where the most value is generated in the user lifecycle.

What Not to Do

• Ignore Funnel Gaps: Overlooking bottlenecks in any stage of the AARRR framework can hinder growth.

• Focus Only on Acquisition: Acquisition is important, but without activation and retention, users won’t convert to paying customers.

• Neglect Long-Term Metrics: Prioritizing short-term wins like revenue at the expense of retention can harm growth.

Validating ideas effectively involves systematically testing their viability through structured feedback, experimentation, and measurable outcomes. Here’s a step-by-step framework to validate ideas and determine their future course:

1. Clearly Define the Idea

2. Choose Validation Methods

3. Gather Data ( but don't create blockers, choose wisely )

4. Analyze Results

5. Decision Framework

6. Iteration and Feedback Loops

Include the following.

Articulate the Core Value: Clearly define the problem the idea aims to solve. Who are the beneficiaries, and how will they benefit? What potential advantages could this idea bring? Consider the scale of investment—do you view this idea as a long-term investment with sustained benefits or a short-term investment that could yield immediate results? Why is this more important than current priorities?

Define Success Criteria: Establish what success means for this idea. Success could be measured through user interest, engagement, revenue generation, or other relevant metrics.

Hypothesize Assumptions: Identify the key assumptions underlying the idea. Examples might include:

• The target audience will find value in the solution.

• The proposed implementation is technically feasible.

Choose Validation Methods. Here are a few options but there are other options.

Choose one or two that seems interesting to you. 👇

Gather Data: Define which data is key for you to track and avoid getting stuck on the unknowns. Good leaders and successful businesses strategically identify what is important and what is not while being able to make decisions despite uncertainties. Choose wisely the type of data you will track, clarify why it is important, and determine how you will use it when you obtain it.

• Quantitative Data: Track metrics like sign-ups, click-through rates, or sales.

• Qualitative Data: Analyze user feedback, interviews, or focus group insights.

• Operational Feedback: Test feasibility with stakeholders, suppliers, or technical teams.

While gathering data is important during this process, also consider how you can gain valuable experience and knowledge. Identify the specific insights and skills that will help you and your team progress effectively.

Then, analyze Results

Ask questions like:

• Are key metrics meeting success criteria?

• Do customers express enthusiasm or indifference?

• Are there consistent pain points or requests for specific changes?

Based on the analysis, decide the idea’s future:

Continue:

• Validation metrics are promising.

• Minor tweaks or optimizations are required.

• Resources are available to scale.

Shift (Pivot):

• Some parts of the idea work, but others need improvement.

• Feedback suggests alternative approaches or markets.

Continue Evaluation:

• Data is inconclusive, requiring further testing.

• Refine hypotheses or validation methods.

Close (Stop):

• Metrics fall short of expectations despite multiple iterations.

• Market feedback indicates no substantial demand.

• The opportunity cost of pursuing the idea outweighs its potential.

Now, during this process is important that the team is able to iterate and that all members go though feedback loops

• Iterate quickly: Use short cycles (e.g., agile sprints) to adapt and test changes.

• Maintain engagement: Continuously gather feedback and update your assumptions.

• Document learnings and decisions: Keep a record of what worked, what didn’t, and why, to inform future initiatives.

Discuss key decisions with the leadership team and follow the process. In a way, by systematically validating ideas and using clear criteria to evaluate progress, you can confidently decide whether to continue, pivot, reevaluate, or stop an idea.

When gathering requirements, one of the biggest challenges is engaging stakeholders effectively to ensure you gather the most relevant and valuable insights. Often, stakeholders lack the time to fully process information during meetings, resulting in superficial responses or a failure to uncover deeper needs. This happens because they require time to reflect or a well-framed question to spark deeper thought.

To address this, it’s essential for the person leading the meeting—whether synchronous or asynchronous—to define the key areas where stakeholders can contribute valuable input. Focus the conversation on those areas to avoid overwhelming stakeholders with irrelevant details. For example, the sales or customer service teams should focus on user-related requirements, not on design or technical constraints.

Preparation is critical. Develop at least two or three targeted questions to guide stakeholders in thinking beyond the surface. These questions can help uncover deeper insights and refine the requirements. Below are some examples:

Key Questions to Ask Stakeholders🙄

1. Success Factors:

• What are the top three things that need to happen for this to succeed?

• How can we better leverage our strengths and opportunities to support this and succeed?

• What resources are underutilized, or what additional skills and knowledge are needed to better support this?

• Who else can provide more context, information, or knowledge to help us uncover opportunities?

2. Consistency:

• What needs to stay the same to ensure a smooth transition and make it easier for those affected by the changes to adapt?

3. Potential Issues:

• Which use cases might be negatively impacted by this solution, and what should we eliminate, modify, or exclude?

4. Prioritization:

• What is one thing that isn’t critical now and can be parked for later so we can maintain focus and define clear goals?

5. Current Strengths:

• What’s one thing you love about how things work now?

6. Industry Inspiration:

• What are other companies or solutions doing that we should evaluate for inspiration?

7. Blockers:

• From your experience, what could become a major blocker or make things difficult?

8. Past Learnings:

• What have you tried in the past that didn’t work? What have others tried that failed?

9. Stakeholder Contribution:

• What actions can you take or influence that could help us succeed?

• What have you done, or what would you like to do about it? How important is this to you, and how would you support us?

• What have you heard or seen about this topic from others, competitors, or the market?

10. Risks and Concerns:

• Are there any fears, concerns, or risks we haven’t discussed that are worth addressing or mitigating?

11. Impact:

• How will this change affect people? Who will be impacted, and in what ways?

12. Preparation:

• How should we prepare to ensure a smooth transition and success?

By focusing on relevant areas and asking thoughtful questions, you enable stakeholders to contribute meaningfully, uncover critical requirements, and reduce the risk of missing essential insights. This approach helps ensure your project is grounded in their expertise and addresses real needs effectively.

During the development process, there are multiple phases where feedback is crucial. This could happen, for example:

• During the initial requirements phase, to evaluate if the solution is headed in the right direction and ensure all key elements are included.

• When presenting solution designs, such as mockups, sketches, or prototypes, to help the team and stakeholders visualize how the solution will work, how it fits into the intended context, and identify any potential issues.

In either case, here’s how to gather meaningful feedback effectively:

1. Avoid Vague Questions

Instead of asking generic questions like:

• “Do you have any comments?”

• “Any thoughts?”

These open-ended prompts often fail to engage stakeholders.

2. Prepare Engaging, Specific Questions

Ensure you prepare at least two targeted questions in advance. The goal is to:

• Encourage stakeholders to think critically about the solution.

• Identify gaps, mistakes, or potential issues early.

Tip: Frame your questions so that stakeholders are encouraged to challenge the solution rather than confirm it.

3. Provide Clear and Relevant Context

Stakeholders often come into feedback sessions without having thought deeply about the topic, as they are juggling other priorities. To ensure productive feedback:

• Provide enough context about the solution or concept.

• Keep the explanation specific and relevant to the stakeholder’s area of expertise.

Tip: Avoid overwhelming stakeholders with irrelevant details—tailor your explanation to their role and priorities.

4. Create a Feedback-Friendly Environment

Stakeholders are more likely to engage if:

• They feel their input is valued.

• The session is structured to encourage constructive criticism.

• They understand how their feedback will influence the outcome.

By adopting these tips, you can ensure your feedback sessions are productive, uncover critical insights, and refine solutions before moving into the development phase. Remember, feedback isn’t just about validation—it’s about discovering and addressing potential challenges early.

Here is an example.

When certain parts of a process require approval from key stakeholders, delays often occur while waiting for their responses. This is especially true when multiple stakeholders need to review and approve a proposal. To streamline this, it’s essential to have a clear, efficient process in place.

👀✔Best Practices for Getting Approvals

1. Document Stakeholder Approvals

If approvals are obtained during a meeting, ensure detailed notes are taken to record the stakeholders’ decisions and agreements. This creates a reliable reference in case decisions are questioned in the future. While this might feel excessive, it is often necessary for clarity and accountability.

2. Avoid Ineffective Communication Channels

Using tools like Slack or email to get proposals approved can lead to issues:

• Stakeholders may be left out of the conversation.

• Messages can be missed or lost in threads.

• Deadlines and expectations may not be clear.

• Stakeholders might provide feedback instead of a clear approval.

3. Use a Structured Approval Process (e.g., Nova)

Platforms like Nova can simplify and organize the approval process. Here’s how:

• Step 1: Provide Context

• Clearly explain what needs approval, and ensure stakeholders understand its importance.

• Include additional resources like videos or links to supporting documents.

• Step 2: Collect Approvals

• Set up an approval session with “Approve” or “Decline” options for clarity.

• Define a due date to keep the process moving.

4. Benefits of Using a Systematic Approach

• Transparency: All stakeholders can see each other’s notes and approvals, fostering collaboration.

• Automation: Integrate approvals into your process so they are automatically tracked and prepared.

• Accessibility: Decisions and records are easy to find when needed later.

• Change Tracking: If updates occur, you can maintain a record of changes in the same space.

By following these steps, you can streamline the approval process, reduce delays, and ensure that decisions are documented and easily accessible for future reference.

A good designer isn’t just someone who makes things look nice—it’s why the responsibilities between a product designer and a PM can sometimes be confusing. However, it's important to remember that while some actions are collaborative, each role has clear responsibilities.

So, let’s go over those key responsibilities to provide more clarity.

🦸‍♂‍In a way, the product manager is responsible for defining the requirements, setting priorities, and ensuring the product or feature gets launched. They act as the glue of the team, making sure there are no silos and that developers, designers, stakeholders, and others understand what is needed, why it is needed, and when it will be delivered.

🧑‍🎤Meanwhile, the designer is responsible for delivering the solution—not the requirements, but how the product should work to ensure the user experience meets high standards. They focus on optimizing usability, reducing costs, and ensuring the design aligns with the future vision. A product designer is, first and foremost, a problem solver.

A 🦸product manager (PM) is responsible for guiding a product's development and ensuring it delivers value to users and the business. Their role is often described as the "glue" that holds cross-functional teams together, bridging the gap between business goals, user needs, and technical feasibility.

In a way, they are responsible for delivering requirements, defining priorities, and supporting the delivery of each initiative to ensure it is launched on time.

👍So what are their main priorities?

What a Product Manager Is 📍NOT Responsible For

A product designer is responsible for designing feasible, cost-effective, intuitive, functional, and aesthetically pleasing solutions that meet user needs and business goals while keeping in mind the requirements set by the product manager. However, they still explore multiple alternatives during the ideation phase. Their role extends beyond visuals—they focus on problem-solving, usability, and the overall product experience.

👍So what are their main priorities?

🧑‍🎤What a Product Designer Is 📍NOT Responsible For

You can learn more about this here: [ ADD LINK ]