Recognize common myths about product management and the typical mistakes newcomers make, and replace each myth with the accurate practice.
What the PM role is NOT
Busting the most persistent PM myths
Newcomers often enter product management with a picture of the role that looks nothing like the actual job. These myths create unrealistic expectations and lead to predictable first-year mistakes.
Myth 1: 'The PM is the CEO of the product.' This phrase is everywhere and is almost entirely misleading. A CEO has formal authority; a PM usually has none. The PM influences through evidence and clarity, not through command. Behaving like a 'mini-CEO' tends to alienate the people whose work you depend on.
Myth 2: 'PM work = writing tickets and attending standups.' Ticket-writing is a small, downstream part of the job. The harder, more important work is upstream: understanding which problems matter, talking to users, analysing data, and building alignment with stakeholders before a single line of code is written.
Myth 3: 'A good PM collects and ships as many feature requests as possible.' Volume of output is not the goal. A PM who ships 20 features that users don't value has failed; a PM who ships 3 features that meaningfully move a key metric has succeeded. Outcomes, not output.
Myth 4: 'I have an idea — let me spec it out and give it to engineering.' Jumping to solutions before understanding the problem is the single most common beginner mistake. It wastes engineering time and produces features that look busy but do not solve real user needs.
A beginner's week reframed: Instead of spending Monday writing specs for three requested features, an outcome-focused PM spends time identifying the one problem that, if solved, would most move the activation metric — then validates that problem with two user interviews before writing anything.
Lesson notes
Busting the most persistent PM myths
Newcomers often enter product management with a picture of the role that looks nothing like the actual job. These myths create unrealistic expectations and lead to predictable first-year mistakes.
Myth 1: 'The PM is the CEO of the product.' This phrase is everywhere and is almost entirely misleading. A CEO has formal authority; a PM usually has none. The PM influences through evidence and clarity, not through command. Behaving like a 'mini-CEO' tends to alienate the people whose work you depend on.
Myth 2: 'PM work = writing tickets and attending standups.' Ticket-writing is a small, downstream part of the job. The harder, more important work is upstream: understanding which problems matter, talking to users, analysing data, and building alignment with stakeholders before a single line of code is written.
Myth 3: 'A good PM collects and ships as many feature requests as possible.' Volume of output is not the goal. A PM who ships 20 features that users don't value has failed; a PM who ships 3 features that meaningfully move a key metric has succeeded. Outcomes, not output.
Myth 4: 'I have an idea — let me spec it out and give it to engineering.' Jumping to solutions before understanding the problem is the single most common beginner mistake. It wastes engineering time and produces features that look busy but do not solve real user needs.
A beginner's week reframed: Instead of spending Monday writing specs for three requested features, an outcome-focused PM spends time identifying the one problem that, if solved, would most move the activation metric — then validates that problem with two user interviews before writing anything.