What a product manager actually does
A product manager decides what a team should build next, and why, and then gets it built and measured without being anyone's boss. Engineers report to an engineering manager. Designers report to a design lead. The PM owns the outcome and has no authority over the people who produce it.
That one fact explains most of what interviewers probe. If you cannot order people around, you get work done through clarity (the problem is so well framed that the team wants to solve it), credibility (engineers trust that you understand their constraints) and evidence (your call rests on users and data, not on rank).
The three questions every product decision answers
Every feature has to be wanted by users, possible to build, and worth it for the business. Designers lean toward the first, engineers toward the second, and business teams toward the third. The PM's job is to find the option that satisfies all three, and to say plainly which one is being traded away when they conflict.
- Solves a real, frequent problem
- Evidence from research or behaviour, not opinion
- Usually argued by design and research
- Possible with this stack and team
- Fits the time we have
- Usually argued by engineering
- Moves a metric the business cares about
- Legal, safe and affordable to run
- Usually argued by business and finance
A week in the job
A typical week mixes four kinds of work. Discovery: talking to users, reading support tickets and data to find problems worth solving. Definition: writing the problem statement, the requirement and the success metric. Delivery: unblocking the team, answering questions, cutting scope when the date is at risk. Measurement: checking whether what shipped moved the number, and deciding what to do next.
Junior PMs spend more time on delivery. Senior PMs spend more on discovery and on deciding which problems the team should take on at all. Interviews at every level test all four, because a PM who only ships is a project manager, and a PM who only strategises never ships.