The PM Role
Product management sits at the intersection of business, technology, and user experience. But that Venn diagram cliche undersells what PMs actually do day-to-day.
A PM's core responsibility is deciding what to build next and why. Everything else (stakeholder alignment, sprint planning, user research, metrics tracking) supports that central decision.
How the Role Varies
PM roles differ significantly across company stages:
Early-stage startup (1-50 people): You are the product team. You talk to customers, write specs, design mockups, QA builds, and handle support tickets. Breadth matters more than depth.
Growth-stage (50-500): You specialize. You own a product area, work with dedicated designers and engineers, and focus on metrics like activation, retention, or revenue. Cross-functional coordination becomes a major time investment.
Enterprise (500+): You operate within a product organization. Your scope narrows to a specific domain. You spend more time aligning with other PMs, navigating internal politics, and managing stakeholders up and across the org.
The Four Responsibilities
Regardless of company size, PMs own four things:
- Product strategy - Where are we going and why? This includes market positioning, competitive differentiation, and long-term vision. See the Strategy Guide for a deep dive.
- Prioritization - What do we build next? This means saying no to most things. The RICE Calculator helps you score features objectively.
- Execution - How do we ship it? Coordinating design, engineering, QA, and launch activities. Not managing people, but managing the process.
- Learning - What did we learn? Tracking outcomes, running experiments, and feeding insights back into strategy.
Common Misconceptions
"PMs are mini-CEOs." No. CEOs have authority. PMs have influence. You cannot fire anyone or approve budgets. You lead through evidence, relationships, and persuasion.
"PMs write requirements." Writing PRDs is maybe 10% of the job. The other 90% is research, alignment, prioritization, and iteration. Check out our guide to writing PRDs for when you do need to write them.
"PMs need a technical background." Helpful, not required. You need to understand technical constraints well enough to have productive conversations with engineers. You do not need to write code.
Key Takeaways
- PMs decide what to build and why; everything else supports that decision
- The role varies widely by company stage and culture
- Influence, not authority, is your primary tool
- Strategy, prioritization, execution, and learning are the four pillars