Master the fundamentals of product management, from user research and analytics to strategy, prioritization, communication, and execution.

Learn product management basics through practical lessons in user research, analytics, prioritization, strategy, and execution. Start on web, iOS, or Android.

Product Management Basics

Learn how to leverage AI in product management. Master AI fundamentals, prompt engineering, and practical applications for PMs.

Learn AI for product managers with practical lessons in AI fundamentals, prompt engineering, and everyday PM workflows. Start on web, iOS, or Android.

AI for Product Managers

Learn how to do competitive analysis. Master the fundamentals of competitive analysis and how to use it to make better product decisions.

Learn competitive analysis for product managers with practical lessons in market research and smarter product decisions. Start on web, iOS, or Android.

Competitive Analysis for Product Managers

## A PM’s Core Responsibilities

A PM connects what the team learns, chooses, ships, and measures. **Alignment runs through all of that work**, rather than being a final hand-off.

```productme-visual
{"asset":"resource:assets/content/b726bbe4-8a0c-4649-b9ec-489294e35076/pm-responsibilities-loop.visual.json"}
```

- **Discovery**: understand users, pain points, and the evidence behind a problem.
- **Prioritization**: choose what deserves attention now and what can wait.
- **Delivery**: clarify scope, sequence, and trade-offs while the team builds.
- **Measurement**: define success and inspect the result after release.
- **Alignment**: keep the team and stakeholders working toward the same outcome.

For an onboarding problem, the PM might investigate setup failures, prioritize the biggest obstacle, clarify a smaller release, and check completion rates. These activities overlap; the illustration is a learning loop, not a rigid process.

<h2>A PM’s Core Responsibilities</h2>
A PM connects what the team learns, chooses, ships, and measures. Alignment runs through all of that work, rather than being a final hand-off.
<pre><code class="language-productme-visual">{"asset":"/content/b726bbe4-8a0c-4649-b9ec-489294e35076/pm-responsibilities-loop.visual.json"}
</code></pre>
<ul>
<li>Discovery: understand users, pain points, and the evidence behind a problem.</li>
<li>Prioritization: choose what deserves attention now and what can wait.</li>
<li>Delivery: clarify scope, sequence, and trade-offs while the team builds.</li>
<li>Measurement: define success and inspect the result after release.</li>
<li>Alignment: keep the team and stakeholders working toward the same outcome.</li>
</ul>
For an onboarding problem, the PM might investigate setup failures, prioritize the biggest obstacle, clarify a smaller release, and check completion rates. These activities overlap; the illustration is a learning loop, not a rigid process.

Which responsibility is most directly tied to the PM role?

Which responsibility is most directly tied to the PM role?

A PM should become the bottleneck for every small decision so quality stays high.

A PM should become the bottleneck for every small decision so quality stays high.

## Discovery Responsibilities

Discovery reduces uncertainty before the team commits to a solution. Start with evidence, make the problem precise, then test what you still do not know.

```mermaid
flowchart TB
  Evidence["Evidence"] --> Problem["Clear problem"]
  Problem --> Test["Test assumptions"]
```

Ask: **Who struggles, where do they struggle, and why does it matter?** Interviews can explain the experience; behavior data can show how widespread a pattern is. Neither automatically proves which solution will work.

If users leave during setup, review the drop-off and talk to affected users before proposing a redesign. Discovery also continues after launch when results challenge the original assumptions.

<h2>Discovery Responsibilities</h2>
Discovery reduces uncertainty before the team commits to a solution. Start with evidence, make the problem precise, then test what you still do not know.
<pre><code class="language-mermaid">flowchart TB
 Evidence["Evidence"] --> Problem["Clear problem"]
 Problem --> Test["Test assumptions"]
</code></pre>
Ask: Who struggles, where do they struggle, and why does it matter? Interviews can explain the experience; behavior data can show how widespread a pattern is. Neither automatically proves which solution will work.
If users leave during setup, review the drop-off and talk to affected users before proposing a redesign. Discovery also continues after launch when results challenge the original assumptions.

{{gap}} reduces uncertainty before the team commits to a solution. {{gap}} checks whether a release improved the intended outcome.

{{gap}} reduces uncertainty before the team commits to a solution. {{gap}} checks whether a release improved the intended outcome.

A new feature shipped last month, but the target metric got worse. What should the PM do first?

A new feature shipped last month, but the target metric got worse. What should the PM do first?

Prioritization is a one-time exercise that happens only during annual planning.

Prioritization is a one-time exercise that happens only during annual planning.

## Delivery Responsibilities

During delivery, the PM turns the intended outcome into enough shared clarity for specialists to make good decisions.

```mermaid
flowchart TB
  Problem["Problem and goal"] --> Scope["Scope and trade-offs"]
  Scope --> Choices["Team decisions"]
```

Clarify the problem, agree on the useful first scope, surface risks, and keep open questions visible. Design and engineering lead the detailed design and implementation choices.

For example, a checkout improvement might start with removing one unnecessary step rather than rebuilding the whole flow. The PM explains the expected effect and the trade-off, then checks the result after release. Delivery support creates clarity without making the PM an approval bottleneck.

<h2>Delivery Responsibilities</h2>
During delivery, the PM turns the intended outcome into enough shared clarity for specialists to make good decisions.
<pre><code class="language-mermaid">flowchart TB
 Problem["Problem and goal"] --> Scope["Scope and trade-offs"]
 Scope --> Choices["Team decisions"]
</code></pre>
Clarify the problem, agree on the useful first scope, surface risks, and keep open questions visible. Design and engineering lead the detailed design and implementation choices.
For example, a checkout improvement might start with removing one unnecessary step rather than rebuilding the whole flow. The PM explains the expected effect and the trade-off, then checks the result after release. Delivery support creates clarity without making the PM an approval bottleneck.

Which roadmap item is written in the strongest product-management style?

Which roadmap item is written in the strongest product-management style?

A launch is the finish line for PM work.

## Alignment Is a Real Responsibility

A stakeholder update should give people the context to act. Combine the goal, what changed, and what needs attention into a clear decision or next step.

```mermaid
flowchart TB
  Goal["Goal"] --> Update["Useful update"]
  Change["Change"] --> Update
  Risk["Risk"] --> Update
  Update --> Decision["Next decision"]
```

Explain **what the team is trying to achieve, what changed, which risks need attention, and why priorities shifted**. Be explicit when a stakeholder needs to decide something.

For example: “Setup completion is below our target. Interviews suggest permissions are confusing. We propose testing clearer guidance before adding new setup steps.” That update connects evidence to a choice and gives stakeholders a chance to respond before they are surprised.

<h2>Alignment Is a Real Responsibility</h2>
A stakeholder update should give people the context to act. Combine the goal, what changed, and what needs attention into a clear decision or next step.
<pre><code class="language-mermaid">flowchart TB
 Goal["Goal"] --> Update["Useful update"]
 Change["Change"] --> Update
 Risk["Risk"] --> Update
 Update --> Decision["Next decision"]
</code></pre>
Explain what the team is trying to achieve, what changed, which risks need attention, and why priorities shifted. Be explicit when a stakeholder needs to decide something.
For example: “Setup completion is below our target. Interviews suggest permissions are confusing. We propose testing clearer guidance before adding new setup steps.” That update connects evidence to a choice and gives stakeholders a chance to respond before they are surprised.

Which stakeholder update is strongest?

A strong PM can explain both what the team is doing and why it matters now.

A strong PM can explain both what the team is doing and why it matters now.