Foundations of Product Management
What the product manager owns
The product manager owns the why and the what: the problem worth solving, the value proposition, the prioritization logic, and the outcome the business expects. Engineering owns the how. Questions often probe this boundary; the trap is to describe the PM as a project scheduler or as a senior engineer. A PM is accountable for outcomes (adoption, revenue, retention), not merely for shipping features on time.
Core concepts to know
- Product vs. project vs. program: a product is an ongoing offering with a lifecycle; a project is temporary; a program coordinates related projects.
- The product lifecycle (introduction, growth, maturity, decline) and how strategy shifts at each stage.
- Value proposition and positioning: who the customer is, what job they hire the product for, and why you beat the alternative (including "do nothing").
- The triple constraint and the reality that scope, time, and cost trade against quality and value.
- Stakeholder management and the product triad (product, design, engineering), plus the PM's relationship with sales, marketing, and support.
- Discovery vs. delivery: validating assumptions before committing build capacity.
Traps in exam questions
Watch for answers that conflate the PM with a project manager, treat the roadmap as a fixed contract, or equate "more features" with "more value." Also beware of answers that skip customer validation entirely or that assign pricing and go-to-market solely to engineering.
Worked rule of thumb
When a question asks what a PM should do first with a new opportunity, the defensible answer is usually to clarify the customer problem and the business outcome before selecting a solution. Rule: problem before solution, outcome before output.
Worked example
A stakeholder demands a feature because one large customer asked. The PM's first move is not to add it to the backlog but to understand the underlying need and how many customers share it, then weigh it against the strategy and evidence.