Product management is the work of deciding which problems a product should solve, why they matter, what should be built next, and how the team will know if it worked. It sits between the needs of users, the goals of the business, and the constraints of actually building the product. A product manager helps bring those inputs together so design and engineering can work on the right problem, with a clear outcome in mind.
Imagine a team receives this request:
“Users need more control over AI-generated playlists.”
That is not yet a product decision.Before building anything, the team still needs to understand:
Product management is the work of turning that broad request into a problem the team can reason about and eventually build.For example, one Figr Gallery project starts with a specific problem: an AI generates a playlist, but users have limited control over it afterward. The work then narrows that problem into an MVP around post-generation steering, including locking tracks, swapping suggestions, and undoing changes.That progression matters:Broad idea → user problem → evidence → product decision → scope → experience → outcomeThe job is not simply to push the idea farther down the development pipeline.What does product management include?The exact responsibilities change between companies, but product management commonly involves several types of work.Understanding the problemBefore deciding on a solution, the team needs to understand what is happening today.That can involve:
Atlassian describes understanding customer needs as a core product-management responsibility, alongside strategy and prioritization.Setting product directionNot every user problem should become a feature.Product teams need to decide which problems matter enough to solve and how those problems connect to the broader direction of the product.That may involve defining:
A roadmap can help communicate that direction, but the roadmap is a representation of the decisions. It is not the strategy itself. Atlassian describes a product roadmap as a shared view of a product's direction, priorities, and progress over time.Prioritizing what to buildA product team will almost always have more possible work than it has time to build.Product management therefore involves making trade-offs between things such as:User valueHow important is this problem to the user?Business valueDoes solving it support an important company goal?EffortHow difficult is the change to design and build?RiskWhat assumptions could make the solution fail?UrgencyDoes the problem need to be solved now?Prioritization is not about finding a formula that makes the decision automatically. The purpose of a framework is to make the reasoning clearer.Defining what needs to happenOnce the team decides to pursue a problem, the idea needs enough definition for people to work on it.That may include:
A PRD can bring many of these decisions together. Atlassian describes a PRD as a document that captures a product's purpose, features, behavior, user needs, and success criteria so cross-functional teams can work from shared context.The document is useful only if the thinking behind it is clear.A beautifully formatted PRD describing the wrong problem is still the wrong problem.A product management exampleSuppose a payments product has this problem:Users are abandoning checkout when their card is declined.A weak product response would be:
“Let's redesign the payment-failed screen.”
That jumps directly from the symptom to a solution.Product management would first ask what is actually happening.For example:1. Understand the behaviorWhere are users dropping off?Do they retry?Do they switch payment methods?Do they understand why the payment failed?2. Identify the user problemPerhaps users see:
Payment failed.
But the product does not tell them whether they should retry the same card, use another card, contact their bank, or try again later.Now the problem is more specific:
Users cannot tell what to do after a failed payment.
3. Decide what to solve
The team might decide that the first version should provide a clear recovery path rather than redesign the entire checkout experience.
4. Map the experience
The flow could account for:Card declined → Explain what happened → Offer another payment method → Retry → SuccessBut it should also consider cases such as:
5. Define success
Instead of measuring whether the new screen shipped, the team could look at whether more users successfully recover from a failed payment.That entire chain of decisions is product management.The screen is only one output of it.Product management vs. project managementThe names sound similar, but the focus is different.Product management asks:
What should we build, for whom, and why?
Project management asks:
How do we organize the work required to deliver it?
A product manager might decide that improving failed-payment recovery is a priority.A project manager might coordinate the timeline, dependencies, people, and delivery process required to ship that change.In practice, responsibilities can overlap between companies, but the distinction between product direction and project execution is useful. Atlassian similarly distinguishes the product manager's focus on product vision and strategy from the project manager's focus on execution and timelines.Product management vs. product designProduct managers and product designers often work on the same problem, but they approach it from different responsibilities.A product manager may focus on:
A product designer may focus more deeply on:
Neither role should operate in isolation.A PM who decides the entire experience before involving design wastes design expertise.A designer who works without understanding the product problem is being asked to solve a puzzle with half the pieces missing.Product design itself also extends beyond visual appearance. Figma and Atlassian both describe it as work that connects user needs with broader product and business considerations.Common product management mistakesStarting with the feature
“We need an AI assistant.”
“We need dark mode.”
“We need a dashboard.”
These are solutions.The useful question comes first:What problem are we trying to solve?Treating every request as a requirementA customer request is evidence, not automatically a roadmap item.If a user asks for an export button, the underlying need might be sharing, reporting, compliance, backup, or moving data into another workflow.Understanding the job matters more than copying the request into the backlog.Confusing output with outcomeOutput: We shipped a new onboarding flow.Outcome: More users completed setup and reached their first useful action.Teams control outputs directly. Outcomes tell them whether those outputs created the intended change.Using the roadmap as a feature calendarA roadmap should communicate direction and priorities.When it becomes an enormous list of promised features and dates, it can stop helping the team understand why the work matters.Writing the PRD too earlyA PRD can document good thinking.It cannot replace it.Writing ten pages about a solution before understanding the problem just gives uncertainty nicer formatting.Designing only the happy pathThe ideal flow is only part of the product.Real users encounter:
Product management should make important exceptions visible before they become surprises during implementation.Frequently asked questionsWhat does a product manager do every day?There is no single daily routine.Depending on the stage of the product, a PM might talk to customers, review analytics, work through a feature with a designer, clarify requirements with engineering, prioritize upcoming work, review a prototype, or evaluate whether a recently shipped change produced the expected result.The common thread is decision-making around the product rather than one specific type of deliverable.Does a product manager need to know how to design?A PM does not need to replace a product designer.But understanding flows, usability, states, constraints, and basic UX principles makes it much easier to communicate product ideas and identify gaps before handing a problem to design.Does a product manager need to know how to code?Not necessarily.Product managers need enough technical understanding to discuss feasibility, trade-offs, dependencies, and constraints with engineering.The depth required depends heavily on the product and the team.Is writing PRDs product management?It is one part of the work.A PRD records decisions about what needs to be built and why. Product management also includes the work required to arrive at those decisions: understanding the problem, prioritizing it, aligning the team, defining success, and learning from what happens after launch.Who does a product manager work with?Product managers typically work across functions rather than operating as a standalone team.Depending on the company, that can include:
Cross-functional alignment is a recurring part of the role because no single function builds a successful software product alone.The bottom lineProduct management is not the job of having all the answers.It is the work of making the product problem clear enough that the team can make good decisions about what to build.That means moving from:“We should build this feature.”to:“This is the user problem, this is why it matters, this is the outcome we want, and this is the smallest useful version worth testing.”The clearer that reasoning becomes, the less time a product team spends building the wrong thing well.Related termsProduct manager · Product strategy · Product discovery · Product roadmap · Product requirements document (PRD) · Prioritization · User flow · Prototype · Product outcome