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.
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 what “more control” means, where users lose control today, which users experience the problem, whether it matters enough to solve now, and how success would be measured.
Product management turns that broad request into a problem the team can reason about and eventually build. A useful sequence is:
Broad idea → user problem → evidence → product decision → scope → experience → outcome
For a concrete example, Figr’s Spotify AI playlist steering project explores a broad request for more control after playlist generation and narrows it into specific product behavior such as locking tracks, swapping suggestions, and undoing changes.
Before deciding on a solution, teams need to understand what is happening today. That can involve user interviews, customer feedback, analytics, existing workflows, pain points, business goals, and technical constraints.
Not every user problem should become a feature. Teams need a product vision and product strategy to decide which problems deserve attention and how they connect to the broader direction of the product.
A product team will almost always have more possible work than it can build. Product management makes trade-offs across user value, business value, effort, risk, and urgency.
Once a team decides to pursue a problem, the idea needs enough definition for design and engineering to work on it. That can include a problem statement, user stories, acceptance criteria, user flows, edge cases, constraints, success metrics, and a PRD.
Suppose a payments product sees users abandon checkout after a card is declined.
A weak response is: “Redesign the payment failed screen.” That jumps from symptom to solution.
Product management asks what is actually happening. Do users understand why the payment failed? Do they retry? Do they switch payment methods? Did the payment sometimes succeed despite a delayed confirmation?
The team might discover a more specific problem: users cannot tell what to do after a failed payment.
Now the team can map a recovery flow, define important failure states, decide the smallest useful scope, and measure whether more users recover successfully.
Product management asks: What should we build, for whom, and why?
Project management asks: How do we organize the people, tasks, dependencies, and timelines required to deliver it?
The responsibilities can overlap, but the distinction between product direction and project execution is useful.
A product manager typically goes deepest on which problem deserves attention, why it matters, what outcome the team needs, and what should be prioritized.
A product designer typically goes deeper on how the experience should work, how users move through the flow, how information is structured, and how the interface behaves across states.
Neither role should work in isolation. Product decisions improve when product, design, and engineering share the same context.
“We need an AI assistant” is a proposed solution. The useful question is what problem the assistant is supposed to solve.
A customer asking for an export button may actually need reporting, sharing, compliance, backup, or a way to move data into another workflow.
“We shipped a new onboarding flow” is an output. “More users completed setup and reached their first useful action” is an outcome.
A PRD can document good thinking. It cannot replace it. Writing ten pages before understanding the problem only gives uncertainty nicer formatting.
Real users encounter errors, missing information, permission restrictions, unusual account states, and interruptions. Important exceptions should be visible before implementation.
Depending on the product, a PM might talk to customers, review analytics, work through a feature with design, clarify requirements with engineering, prioritize upcoming work, or evaluate a recently shipped change.
It is one part of the work. A PRD records decisions. Product management also includes discovering the problem, prioritizing it, aligning the team, defining success, and learning after launch.
No. The team still needs to understand whether the feature created the intended outcome and what to do next.
Product management turns “we should build this” into “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 team spends building the wrong thing well.
Product manager · Product strategy · Product discovery · Product roadmap · PRD · MVP
For a deeper guide, read What Is Product Management? A No-Fluff Guide for PMs.
