← Go Back

Product Manager

What is a Product Manager?

A Product Manager (PM) is the role responsible for defining product vision, strategy, and roadmap and for coordinating cross-functional teams so that the right product is built for the right users and business outcomes. PMs sit between business strategy, user needs, and technical implementation.

Use it when: you need a single point of accountability for what to build and why, and for aligning design, engineering, and business around shared goals.

Copy/paste template (PM role clarity)

  • Product/area owned: [what this PM is responsible for]
  • Success metrics: [outcomes this role is accountable for]
  • Key stakeholders: [design, engineering, business, users]
  • Decision rights: [what the PM decides vs recommends vs facilitates]
  • Rituals: [roadmap review, prioritisation, discovery, launch]

Why Product Managers matter

  • Give teams a clear "what to build and why", reducing confusion and rework.
  • Balance user needs, business goals, and technical constraints in one place.
  • Improve prioritisation so the most valuable work gets done first.
  • Create alignment across design, engineering, and business with a shared language.
  • Reduce the risk of building the wrong thing or building in silos.

What a good Product Manager role includes

Checklist

  • [ ] Clear ownership: defined product or area, not vague "everything".
  • [ ] Outcome-focused: success measured by user and business outcomes, not just delivery.
  • [ ] Discovery and delivery: time for research, strategy, and execution.
  • [ ] Stakeholder alignment: regular communication with design, engineering, and business.
  • [ ] Decisions documented: key choices (e.g. in decision records) so rationale is clear.

Common formats

  • Strategic PM: focuses on vision, roadmap, and market; often works with multiple teams.
  • Tactical PM / Product Owner: focuses on backlog, sprint goals, and delivery; often embedded in one team.

Examples

Example (the realistic one)

A PM owns the "onboarding" product area. They run discovery with users and identify that drop-off happens at step 3. They work with design on a simplified flow and with engineering on feasibility. They define success as "activation rate within 7 days" and get stakeholder agreement. They prioritise the redesign over a requested "extra feature" and track the metric post-launch to decide next steps.

Common pitfalls

  • PM as "feature waiter": saying yes to every request without prioritisation. → Do this instead: maintain a clear strategy and criteria; say no or "not now" with rationale.
  • Skipping discovery: going straight from idea to build. → Do this instead: validate problems and solutions with users and data before committing.
  • No clear success metrics: shipping without knowing how you'll measure impact. → Do this instead: define outcome metrics up front and review them after launch.
  • Confusion with Project Manager: PM (what/why) vs Project Manager (when/how, scope and timeline). → Do this instead: clarify roles; many teams use "Product Manager" for strategy and "Product Owner" or delivery lead for execution.
  • Product Manager vs Product Owner: PM is typically strategic (what and why); Product Owner is often tactical (backlog, sprint, when). In some orgs one person does both.
  • Product Manager vs Project Manager: PM owns product strategy and prioritisation; Project Manager owns schedule, budget, and delivery coordination.
  • Product Manager vs Product Designer: PM defines problems and success criteria; Designer defines how to solve them through experience and interface.

Next step

If you're defining the product direction, use product thinking and value proposition. If you're breaking work down, use user stories and MVP.

Related Terms