Data-Driven Product Management

Module 1 · Module 1 — The product manager's role · Lesson 1 of 1

Arbitrating between business, tech and user needs, not at random

Welcome to this course on data-driven product management. In this first module, we clarify a role that's often misunderstood: the product manager, often abbreviated PM. A product manager is neither a developer, nor a designer, nor a salesperson — but they work with all three constantly, sitting at the crossroads of three forces that often pull in different directions: the business side, meaning what's profitable and sustainable for the company; the technical side, meaning what's actually feasible with available resources and time; and the user side, meaning what genuinely meets a real need. The PM's role isn't to maximize any single one of these three dimensions, but to find the best ongoing trade-off between all three. Take a concrete example. A sales team pushes to add a feature requested by a large client, promising a major contract if it ships this month. The engineering team warns that building this feature under time pressure would destabilize a part of the system already in production. The design team points out that the feature, as requested, would only be usable by this one client, not by the product's other users. The product manager has to arbitrate — not flip a coin, nor systematically cave to the loudest or most urgent voice. A good arbitration always starts with factual questions: what is this contract's real value compared to the technical risk involved? Can a simplified version satisfy this client without destabilizing the system? What does it cost other users to delay other features in order to prioritize this one? An essential point to remember from this first module: a good product manager never says "yes" by default to every request, nor "no" on principle to every new idea. They systematically ask "why" before saying "yes" or "no." That question — why — is the most powerful tool in the job, well ahead of any software or method. In the modules ahead, you'll learn to structure this approach: defining a product vision, prioritizing objectively with data rather than instinct, writing clear specifications, measuring real usage, experimenting through testing, collaborating day to day with other teams, and finally launching a product while knowing how to iterate afterward. This module closes with a case study of a PM arbitrating between three conflicting requests — a chance to put this first, foundational reflex into practice.

Free preview, no account needed — the rest of this module and the following modules unlock after enrolling.