Product Management
Product management is the practice of deciding what a product should do and in what order, balancing user needs, business goals and what is buildable.
52 resourcesintermediate
It covers discovery, strategy, prioritisation and working through delivery. The discipline is judged on outcomes rather than output, so shipping a lot of features that change nothing is not a good quarter.
How it works
- Discovery. Continuously understanding users and the market through research, behavioural data and conversations with the people who talk to customers. It never finishes.
- Strategy. Turning that into a direction. Why the product exists, who it is for, and what it should achieve.
- Prioritisation. The hardest part, because capacity is finite and every yes is several nos. The job is making trade-offs explicit rather than implicit.
- Communication. Keeping everyone aligned on the reasoning, not just the decision, so it survives new information.
- Execution. Working through the build, resolving trade-offs as they surface.
Common mistakes
- Confusing it with project management. Product decides what and why. Project decides when and how. Conflating them tends to produce work that ships on time and accomplishes nothing.
- Measuring output. Counting features shipped rewards activity over results.
- Hiding the reasoning. A decision without a visible rationale gets relitigated every time someone new asks about it.
- Specifying solutions. Arriving with the answer skips the design work and locks in the first idea anyone had.
Trade-offs
The role sits between three pressures that rarely agree, and every decision favours one at some cost to the others.
- User need against business need. The most useful thing for a user is not always the thing that funds the company. Pretending they always align is how roadmaps lose credibility.
- Speed against foundation. Shipping now often means building something you will pay to unpick later. Sometimes that is correct. It should be a choice rather than an accident.
- Focus against responsiveness. A team that says yes to everything has no strategy. A team that says no to everything stops learning from the people asking.
Key takeaways
- Judge the work by outcomes changed, not features shipped.
- Make trade-offs explicit. Unstated prioritisation becomes politics.
- Product decides what and why. Project decides when and how.
- Bring the problem, not the solution.
Learn this
Lessons and exercises mapped to this concept.
CourseProduct Management FoundationsMaster modern product leadership: root-cause problem discovery, customer-driven vision, cross-functional collaboration, agile execution, and measurable business impact.CourseUX Design FoundationsMaster the principles, cognitive ergonomics, visual hierarchy, and scientific workflows of user experience design. 100% original curriculum synthesized from authoritative interaction design literature.
Common questions
- What is the difference between product management and project management?
- Product management decides what to build and why, and owns whether the outcome was worth achieving. Project management decides when and how it gets delivered, owning schedule, coordination and risk. One person may do both, but conflating them tends to produce work that arrives punctually and achieves nothing.
- Do product managers need to be technical?
- They need enough understanding to grasp cost and constraint, such as why one approach takes a week and a similar looking one takes a quarter. Without that, roadmaps get built that engineering cannot honour. They do not need to write production code, and those who try to specify implementation usually decide worse than the engineers would have.
- Who owns UX, the product manager or the designer?
- Framing it as ownership causes most of the friction. The product manager owns which problems are worth solving and in what order. The designer owns how the solution works and feels. The failure mode is a product manager arriving with a finished solution, which skips the design work entirely.