Fundamentals of Product Management

Mark module complete Expand all

1.1 How to read this module

Each topic is taught at three depths. Look for the coloured boxes:

1.2 What is a product?

A product is anything a person or organisation uses to achieve a goal, delivered in a repeatable way. For a PM the useful definition is:

A product is a bundle of value (the job it does for someone) and experience (how it feels to get that job done), sustained by a business model (why the organisation can afford to keep providing it).

Kinds of product you will meet

1.3 What is Product Management?

Product management is the discipline of deciding which problems are worth solving, for whom, and how the team will know the solution worked, then guiding the team to deliver it. The PM does not “own” the product alone; they own the clarity of the problem and the quality of the decisions.

1.3.1 The three circles — and the fourth risk

A good product sits where three things overlap: desirable (people want it), feasible (the team can build and run it) and viable (it works for the business). Marty Cagan frames the same idea as four risks a PM must retire before and during building: value risk, usability risk, feasibility risk and business-viability risk.

1.3.2 What a PM is responsible for

1. Problem definition — who has the problem, how often, how painful, what they do today.
2. Strategy and focus — saying “not now” so the team works on the highest-value problem.
3. Discovery — talking to users, reading data, running cheap experiments.
4. Requirements and alignment — turning understanding into artefacts the team can build from (PRDs, user stories, acceptance criteria).
5. Delivery partnership — removing blockers, making scope trade-offs, protecting quality.
6. Launch and learning — go-to-market coordination, metrics, post-launch review.
7. Stakeholder communication — keeping leadership, sales, support, legal and operations informed.

1.4 How a PM thinks: trade-offs, evidence and outcomes

PMs make decisions with incomplete information. Good ones follow a loop, not a gut feel:

Trade-offs you will make daily

1.5 PM versus adjacent roles

Role boundaries differ by company. These are typical emphases, not rules; always ask “who makes the final call on X?” in a new team.

1.6 PM specialisations and career paths

1.7 Product lifecycle versus product development lifecycle

Two different lifecycles are easy to mix up.

• Product Life Cycle (PLC) — how a product's market life evolves: introduction → growth → maturity → decline. It guides strategy: invest to find fit and acquire in introduction; scale and defend in growth; optimise margin and extend in maturity; decide to harvest, reinvent or retire in decline.
• Product Development Lifecycle (often the SDLC for software) — how a piece of work moves from idea to release: discover → plan → design → build → test (QA/UAT) → release → learn.

1.7.1 Waterfall, Agile, Scrum, Kanban, SAFe — what to know as a PM

1.8 Product operating models

An operating model is how the organisation turns ideas into shipped product: who decides, how teams are formed, how funding and priorities flow.

1.9 Vision, mission and strategy (overview)

• Mission — why the organisation exists and what it does.
• Vision — the future you want to create for users.
• Strategy — the choices about whom to serve, which problem to solve and how to win sustainably (including what not to do).
• Roadmap — a communicated plan of outcomes and likely work over time; not a promise of dates.

1.10 Product–market fit

Product–market fit (PMF) means a product satisfies a real market need strongly enough that customers keep using, paying for and recommending it. Marc Andreessen's often-quoted framing is being “in a good market with a product that can satisfy that market.”

Signals of fit (use several, never one):

• Retention curves that flatten rather than decay to zero (see Module 7).
• Growing share of new users arriving by word-of-mouth or referral.
• The “very disappointed” survey test (popularised by Sean Ellis): if roughly 40%+ of active users say they would be very disappointed if the product disappeared, that is a commonly used signal of fit. It is a heuristic, not a law.
• Customers pulling the product faster than you can serve it; sales cycles shortening.
• Unit economics that work at the margin (Module 7).

1.11 Customer value versus business value

• Customer value — benefit the customer gets relative to what it costs them (money, time, effort, risk).
• Business value — what the organisation gains: revenue, margin, retention, strategic position, cost savings, learning.

Good products create value for customers first, then capture a fair share. Both must be positive or the product is not sustainable.

1.12 Output versus outcome

• Output — what the team produces: features shipped, tickets closed, story points.
• Outcome — the change in user behaviour or business results that follows: higher checkout completion, fewer support contacts, better retention.

1.13 Product discovery versus product delivery

• Discovery — deciding what to build: understanding the problem, testing value and usability, estimating feasibility and viability.
• Delivery — building, testing and releasing it reliably.

In dual-track teams both happen continuously: discovery de-risks the next items while delivery builds the current ones.

1.14 Stakeholder management (introduction)

A stakeholder is anyone affected by or able to affect the product: leadership, sales, support, legal, compliance, finance, operations, partners, and users.

Four habits cover most of it:

1. Map them — who has influence and who has interest? (Module 6 covers the power–interest grid.)
2. Align on the goal first — agree the outcome before debating solutions.
3. Make trade-offs visible — one page: options, cost, benefit, risk, recommendation.
4. Close the loop — record the decision, the owner and a review date.

1.15 Product sense and product thinking

Product sense is the ability to quickly see a product through the user's eyes and the business's, spot what matters, and propose sensible improvements. Product thinking is the habit of starting from the user problem and outcome rather than from a feature or technology.

Build it deliberately:

• Critique products you use, writing: who is it for, what job, what works, what frustrates, what would you test, what could go wrong.
• Watch real people use something — your own app or someone else's.
• Read teardowns and case studies, then predict the metric they would have moved.
• Practise estimation and metric reasoning (Modules 3 and 7).

1.16 Growth model and customer relationship: PLG versus SLG

Most mature B2B companies blend the two (“product-led, sales-assisted”). Module 8 develops growth loops and PLG in detail.

1.17 B2B versus B2C product management

1.18 Platform products versus feature products

• A feature product solves a bounded job for end-users (a scheduling app).
• A platform provides capabilities others build on (payments API, identity service, internal developer platform). Its customers are often developers or other teams.

Platform PMs optimise developer experience (clear docs, fast integration, stable APIs, predictable pricing), reliability and ecosystem growth, and must manage backwards compatibility — breaking an API breaks someone else's product.

1.19 Common Product Management mistakes

1.20 Source-flagged misconceptions (corrected)

• A sprint is ≤ 1 month — not necessarily two weeks.
• MVP ≠ prototype ≠ public launch. An MVP is the smallest useful version or experiment that teaches you something important; it must still be safe and fit its test.
• Kanban is flow management with WIP limits, not a Scrum–XP hybrid.
• A focus group is a moderated research discussion, not another name for a target audience.
• There is no universal rule that every product has two or three personas.
• A unicorn is a private company valued at ≥ US$1 billion, not one with $1 billion revenue.
• Product–market fit is not proven by market size alone.

1.21 Practice and model answers

1.22 Interview perspective

1.23 Key takeaways

• A product is value + experience + business model.
• A PM's job is to choose and clarify the problem and be accountable for the outcome, working through influence, not authority.
• Retire the four risks — value, usability, feasibility, viability — as cheaply as possible.
• Output ≠ outcome. Define the metric and guardrails before building.
• Discovery and delivery run together in good teams.
• Role names vary; decision rights are what matter.
• Be honest: label assumptions and don't invent results.

1.24 Check your understanding

1.25 Recommended resources

• The Scrum Guide — official rules for Scrum.
• Atlassian: Product management — practical overviews (from your course reference list).
• Silicon Valley Product Group articles — Marty Cagan on empowered teams and the four risks.
• Product Talk (Teresa Torres) — continuous discovery habits.
• Lenny's Newsletter — practitioner essays and PM career guidance.