What Product Management Is

What Product Management Is

Most companies build products through a process that has more in common with construction than discovery. Business stakeholders specify requirements, designers sketch screens, engineers build, and the result is measured against the original specification rather than against user outcomes. This process works for well-understood problems with stable requirements — houses, bridges, factories.

Software products are different. The problem space is unknown at the start. User needs are incompletely understood. The technical constraints change as building progresses. The competitive environment shifts. Trying to specify the right product before building it is not just difficult — it is conceptually wrong.

Product Management emerged to manage this reality: to translate uncertainty into a sequence of testable bets, and to represent user needs and business goals inside an organisation that would otherwise optimise for what engineers find interesting to build.

The PM's Job Description

A PM is sometimes described as "the CEO of the product." This is an overstatement — PMs rarely have authority over engineering, design, or business decisions directly. The more accurate framing: PMs have accountability without authority. They are responsible for the product's outcomes but must achieve those outcomes through influence rather than command.

What PMs actually do:

• Define the problem — understand users well enough to know what problem the product should solve
• Prioritise ruthlessly — decide what to build now versus later versus never, and defend those decisions with evidence
• Set direction — communicate a coherent vision and s`rategy that aligns the team's work
• Manage trade-offs — make calls when user needs, technical constraints, and business requirements conflict
• Measure outcomes — determine whether shipped features produced the intended results and iterate accordingly

What PMs do NOT do:

• Write code or design screens (unless they happen to have those skills — but it is not the role)
• Tell engineers how to build something (that is the engineer's domain)
• Make business decisions alone (PMs make recommendations; executives make final calls on large commitments)

The Product Triad

Modern product teams are typically structured around a triad: Product Manager, Designer, and Tech Lead. Each brings a different lens to product decisions:

• PM: Is this valuable? Is this the right problem? Does this move the business forward?
• Designer: Is this usable? Does this match user mental models? Is this experience coherent?
• Tech Lead: Is this feasible? How should we build it? What are the technical trade-offs?

Good product decisions address all three dimensions. Building something technically feasible but not valuable wastes engineering resources. Building something users love but technically impossible in the timeframe sets false expectations.

PM Levels and Archetypes

Entry-level PMs manage features within an existing product. Senior PMs manage products or product areas. Directors and VPs manage groups of PMs and set portfolio strategy. CPOs (Chief Product Officers) shape company-level product direction.

In practice, the PM role varies enormously by company type:

• B2C consumer: heavy emphasis on growth metrics, A/B testing, viral loops
• B2B enterprise: heavy emphasis on sales enablement, customer success, contract requirements
• Platform/API: heavy emphasis on developer experience, documentation, ecosystem
• Early-stage startup: PM role overlaps significantly with founder, doing customer development, writing code, running sales

Why PM Exists

Before formal product management, software companies split into two failure modes:

• Engineer-led: built technically interesting things that users did not need or could not use
• Business-led: built according to client specifications without feedback loops, accumulating technical debt and user frustration

PM emerged to bridge these failure modes — to continuously ask "are we building the right thing?" while engineering asks "are we building it right?" Neither question alone produces good products. Both together, in continuous dialogue, do.

The best products in the world — the iPhone, Slack, Airbnb, Figma — were built by teams that were excellent at both. But neither started with a complete specification. They started with a hypothesis about user needs and iterated toward product-market fit through structured learning.