Review
Product School's introduction to product management, and it is exactly that: a survey aimed at someone who does not yet have the job.
It covers the territory competently. What a product manager does, how to work with engineering and design, the basics of research, roadmapping, launching and measuring. The structure follows a product lifecycle, which is a sensible way to organise an introduction, and the writing is plain.
What it lacks is a point of view. Almost every topic gets an even-handed summary of the accepted position with no argument about when it fails, and product management is a discipline where the interesting knowledge is almost entirely in the exceptions. Compare it with something like LeMay's book, which is also aimed at newcomers but is willing to say which parts of the job are genuinely unpleasant.
There is also a visible commercial purpose. It exists partly to demonstrate the depth of a course, and that shapes what it covers and how confidently. Fine as a first orientation if it is the book in front of you. If you are choosing, there are better first books.
Key Takeaways
The parts worth keeping:
The shape of the role
- Product managers are responsible for outcomes across research, definition, delivery and launch, without owning any of those functions.
- The work is coordination and judgement rather than production, which is why it is difficult to describe and easy to do badly.
- Most of the day is spent creating shared understanding between people who each hold part of the picture.
Lifecycle in order
| Phase | The question |
|---|---|
| Discover | What problem exists and for whom? |
| Define | What are we building and why this rather than that? |
| Build | How do we ship it without losing the intent? |
| Launch | How do the right people find out and adopt it? |
| Learn | Did it do what we said it would? |
- The last phase is the one most often skipped, and skipping it is what keeps organisations repeating the same mistakes confidently.
Working across functions
- Engineers want the problem and the constraints, not a specified solution handed over as a requirement.
- Designers should be present while the problem is still being framed, not brought in to render a decision already made.
- Stakeholder management is a permanent part of the role rather than an interruption to it.
Measure what you claimed
- Decide before launch what result would count as success, and write it down where it cannot be quietly revised afterwards.
- A metric chosen after the numbers arrive will always show that things went well.