Product manager interviews probe product thinking, comfort with metrics, and how you decide what not to build. Below are the most common questions with model answers. Junior: core theory, definitions, and simple practical cases.
A project has a defined end — a scope, a date, and a moment when it is delivered. A product continues, and its success is measured after delivery by whether people keep using it. The consequence is different questions: a project asks whether it shipped on time, a product asks whether shipping it changed anything.
The product manager decides what should be built and why; the project manager makes sure the agreed work gets delivered. One owns the outcome, the other owns the plan. In small teams the same person does both, which is fine until the two goals conflict — and they do, every time a deadline meets a discovery finding.
It is a statement of intent about problems and their order, useful because it lets everyone else plan around it. It is not a commitment to dates and features a year out — a roadmap treated as a contract turns discovery into theatre, because nothing found can change anything. The honest version has less certainty the further out it goes.
The smallest thing that tests whether the assumption holds. It is mistaken for a cheap version of the full product, which is why teams ship something incomplete, learn nothing, and damage the brand while doing it. The question that keeps it honest is what you would do differently depending on the result — if the answer is nothing, it is not worth building.
ARPU is average revenue per user in a period; LTV is total revenue expected from a customer over their whole relationship, minus what it costs to serve them. ARPU can look healthy while LTV is falling, because ARPU says nothing about how long people stay. LTV is the number that decides how much you may spend to acquire someone.
By deciding before launch what would count, then checking adoption, retention of that adoption, and the outcome metric it was meant to move. A feature can be widely used and still be a failure if it cannibalises a better flow or raises support volume. Choosing the metric after seeing the data is how everything looks like a success.
It is the work of finding out whether the problem is real, whether the solution addresses it, and whether it is worth doing — through interviews, prototypes, data. It comes first because building is the most expensive way to learn, and because a team that has skipped it will discover the same things after the release, having paid for them.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Junior Product Manager interview →