What Product Management Is

Product management is one of the most misunderstood roles in tech — engineers often see it as either a glorified project tracker or a mysterious source of demands, and PMs themselves get called "the CEO of the product," which is misleading in the opposite direction. The truth is more specific and more useful: a product manager owns what gets built and why, so that the team builds the right thing. Understanding the role — especially from an engineer's perspective — clarifies a lot about how good products actually get made.

By Pratik Dhanave · April 30, 2026 · 9 min read

#Product Management #Product #Career #Business Strategy

This series is a practical guide to product management (PM) for engineers — what the role is, what PMs do, and how to think like one, whether you work with PMs, want to become one, or are a founder doing PM yourself. This first post frames what product management actually is, what it’s not (dispelling the myths), the core responsibility (the “why” and “what,” not the “how”), and how it relates to engineering. It’s the foundation for the series on discovery, prioritization, strategy, collaboration, metrics, shipping, and practice.

What product management is

Product management is the discipline of figuring out what to build and why — ensuring a team builds a product that’s valuable (customers want it), viable (works for the business), and feasible (can be built). The product manager owns this:

The PM owns the “what” and “why.” A product manager is responsible for deciding what the product should do and why — understanding customer problems, defining what to build to solve them, and prioritizing what matters most. The PM owns the problem and the what, not the how (that’s engineering). They ensure the team builds the right thing. The PM’s core job is getting the “what” and “why” right.
Valuable, viable, feasible. Good product management sits at the intersection of three concerns: valuable (does it solve a real customer problem they’ll want/pay for?), viable (does it work for the business — economics, strategy?), and feasible (can engineering actually build it?). The PM ensures what’s built satisfies all three — balancing customer, business, and technical realities. It’s a balancing role across these dimensions. The sweet spot is where all three meet.
It’s about building the right thing. The essence of product management is ensuring the team builds the right thing — the product that solves real problems and succeeds — rather than just building things right (which is more the engineering/execution concern). A team can execute brilliantly and still fail if it builds the wrong thing; the PM’s job is to prevent that. Product management is the discipline of building the right product. Right thing, not just thing built right.

Product management is the discipline of deciding what to build and why — ensuring the product is valuable, viable, and feasible — so the team builds the right thing (not just builds things right). The PM owns the problem and the what, not the how. Understanding this is clearer when you dispel the common myths.

What product management is not

Product management is widely misunderstood — clearing up what it’s not sharpens what it is:

Not “the CEO of the product.” A common phrase — “the PM is the CEO of the product” — is misleading: PMs usually have little formal authority (they don’t command engineering, design, etc.). Unlike a CEO, a PM leads mostly through influence, not authority — persuading and aligning teams they don’t control. Calling PMs CEOs overstates their power and misses that their real skill is influence without authority (the EQ series). PMs lead by influence, not command. It’s the opposite of a CEO’s authority.
Not project management. PM (product management) is not project management (though the abbreviation collides). Project management is about executing a plan (schedules, tasks, coordination — the “how” and “when”); product management is about deciding what to build and why (the “what” and “why”). They’re different disciplines — one about execution, one about what to execute. A PM isn’t primarily a task-tracker. Product ≠ project management. Different roles, unfortunate shared initials.
Not the boss of engineers. PMs don’t manage engineers (that’s engineering management) — they’re peers who collaborate with engineering and design. The PM decides what/why; engineering decides how and builds it; design shapes the experience — as collaborating peers, not a hierarchy. A PM giving engineers orders is doing it wrong. PMs are collaborators, not bosses. It’s a partnership of peers.
Not the sole source of ideas. Good product management isn’t the PM dictating all ideas — the best ideas come from everywhere (engineers, designers, customers, data), and the PM’s job is to facilitate, decide, and prioritize among them, not to be the lone genius. PMs orchestrate and decide, not monopolize ideas. Ideas come from everywhere; the PM decides what to pursue. Facilitator, not sole ideator.

Product management is not being the CEO of the product (PMs lead by influence, not authority), not project management (deciding what to build vs executing a plan), not the boss of engineers (a collaborating peer), and not the sole source of ideas (a facilitator and decider). Dispelling these myths clarifies the real role — which centers on the “why” and “what.”

The “why” and “what,” not the “how”

The clearest way to understand product management, especially for engineers, is the division: PM owns the “why” and “what”; engineering owns the “how.”

PM: why and what. The PM focuses on why (what problem, for whom, why it matters — the customer/business rationale) and what (what to build to solve it — the requirements, priorities, the product). This is the problem-and-definition space: understanding problems and defining what solves them. The PM’s domain is the why and the what. What to build, and why.
Engineering: how. Engineering owns the how — how to actually build what’s defined (the technical design, implementation, architecture — the domain the rest of this blog covers). Given the what and why from the PM, engineering figures out and builds the how. Engineering’s domain is the how. How to build it.
The division (and collaboration). This division — PM owns why/what, engineering owns how — is a useful model (though real work is collaborative, with overlap and mutual input). It clarifies the PM’s role for engineers: the PM isn’t telling you how to build (your domain) but what to build and why (their domain). Understanding this division reduces friction — each owns their part, collaborating across the boundary. Why/what meets how. Respect the boundary, collaborate across it.
Why this matters to engineers. For engineers, understanding that the PM owns why/what explains the relationship: the PM brings the problem and the what; you bring the how and build it; you collaborate on feasibility and tradeoffs. It reframes the PM from “person who makes demands” to “partner who ensures we build the right thing, so your excellent how is spent on the right what.” A good PM makes your engineering count by aiming it at the right thing. Good PM makes good engineering matter.

The clearest model of product management is the why/what vs how division: the PM owns why (the problem/rationale) and what (what to build), while engineering owns how (building it) — a useful (if simplified) split that clarifies the collaborative relationship. For engineers, this reframes the PM as a partner ensuring the right thing gets built, making your engineering count. That’s why understanding PM matters for engineers.

Why engineers should understand PM

Understanding product management is valuable for engineers even if you never become a PM — worth making explicit as the series’ motivation:

It explains why you’re building what you’re building. Understanding PM (the why/what behind the work) helps you see why your team is building what it is — the customer problems, priorities, and rationale — rather than just receiving requirements. This context makes your work more meaningful and lets you contribute better (feasibility input, better solutions). Understanding PM gives your work context. Know the why behind the what.
It makes you a better collaborator. Understanding the PM’s role, concerns, and constraints makes you a better partner to PMs — collaborating on tradeoffs, feasibility, and solutions productively rather than with friction. Good engineer-PM collaboration (built on mutual understanding) produces better products. Understanding PM improves the collaboration. Better partner, better products.
It’s a path (for founders and career growth). If you found a company, you’ll do PM yourself (deciding what to build — vital early). And engineers increasingly move toward product (PM roles, product-minded engineering, technical PM). Understanding PM opens paths and grows your impact beyond pure engineering. PM knowledge is career-relevant. A door to broader roles.
It makes you a product-minded engineer. Ultimately, understanding PM helps you become a product-minded engineer — one who thinks about why and what (customer value, the right thing) alongside how (building it well). Product-minded engineers are especially valuable (they build the right things well). Understanding PM elevates your engineering. Think product, not just code.

Product management is the discipline of deciding what to build and why — ensuring a valuable, viable, feasible product (the right thing) — with the PM owning why/what (leading by influence, collaborating with engineering’s how), not being a CEO, project manager, or boss. Understanding it makes engineers better collaborators, more context-aware, and more product-minded. The series explores it: discovery, prioritization, strategy, collaboration, metrics, shipping, and practice. Next: understanding the problem — the foundation of good product management.

Key takeaways

Product management is the discipline of deciding what to build and why — ensuring the product is valuable (customers want it), viable (works for the business), and feasible (can be built) — so the team builds the right thing, not just builds things right; the PM owns the problem and the “what,” not the “how.”
It’s widely misunderstood: PM is not “the CEO of the product” (PMs lead by influence, not authority — little formal power), not project management (deciding what to build vs executing a plan — despite the shared initials), not the boss of engineers (a collaborating peer), and not the sole source of ideas (a facilitator/decider — ideas come from everywhere).
The clearest model is the division: the PM owns “why” (the problem, for whom, why it matters) and “what” (what to build), while engineering owns “how” (building it) — a useful (if collaborative and overlapping) split that clarifies the relationship for engineers.
This reframes the PM from “person who makes demands” to a partner who ensures the right thing gets built — so your excellent engineering (“how”) is aimed at the right “what” — a good PM makes your engineering count by pointing it at the right problem.
Understanding PM is valuable for engineers even without becoming one: it gives context (why you’re building what you’re building), makes you a better collaborator with PMs, opens career paths (founders do PM; engineers move toward product), and helps you become a product-minded engineer who thinks about why/what alongside how.