The job, stated plainly
Product management is deciding what to build, why, and in what order — and then being accountable for whether those decisions were right. Not scheduling the work, not writing the tickets, not running the standup. Those are real jobs and they're different ones.
The "mini CEO" description is popular and unhelpful, because it implies authority the role usually doesn't have. The more accurate version: you're accountable for the decisions and you get there by evidence and persuasion rather than instruction.
| Product | Project |
|---|---|
| Should we build this at all? | When will it be done? |
| Who is it for, and who is it not for? | Who's working on it? |
| What does success look like? | Are we on schedule? |
| What do we cut to ship this quarter? | What's blocking the current task? |
| Was that the right call? | Did we deliver what we said? |
The inputs, and how to weight them
The decisions are made from several streams of evidence, none of which is sufficient alone, and each of which fails in a characteristic way.
| Input | Good for | Fails at |
|---|---|---|
| Customer conversations | Why something is a problem | Telling you how common it is |
| Usage data | What people actually do, at scale | Telling you why they did it |
| Support tickets | Sharp, specific pain | Over-weighting your loudest users |
| Sales requests | What blocks deals today | Optimising for one prospect |
| Competitors | Table stakes and conventions | Copying decisions made for a different company |
| Your own judgement | Speed, and the parts nobody asked for | Being confidently wrong with no check |
Write the decision down
The habit that separates product management from opinion is recording the decision with its reasoning and its expected outcome, before the work starts. It costs ten minutes and it's the only way to learn anything from being wrong.
Decision: Build itinerary edit persistence before team accounts.Why: 6 of 8 interviewed agencies described losing edits on regeneration, unprompted. 2 asked for team accounts, both when prompted.Expect: Regeneration-related support tickets drop noticeably. Agencies stop keeping a parallel copy in a document.Check on: 2026-09-15Wrong if: Tickets stay flat, or edits weren't the reason people kept the parallel copy.The "wrong if" line is the one that does the work. Deciding in advance what would count as a mistake is what prevents the retrospective from becoming a reinterpretation of whatever happened.
Most of the job is saying no
Requests arrive constantly and each one is reasonable to the person asking. A product with everything built is slow, confusing, and expensive to maintain — and it got that way one reasonable decision at a time.
- "Not now" with a reason is a better answer than a vague yes that never happens
- Ask what problem the request solves before evaluating the request — you'll often solve it differently and more cheaply
- Count how many people asked unprompted, not how loudly one person asked
- A feature added is maintained forever; the cost isn't the build, it's the next five years
- Say what you're not doing publicly, so people stop waiting for it
When you're the whole company
At one or two people, nobody has this title and the work still exists. It just gets done badly by default: whatever is most interesting to build, or whatever the last customer mentioned, becomes the roadmap.
- Keep one written list of what you're not buildingIt's more useful than the roadmap and takes less maintenance.
- Write the decision note for anything over a week of workBelow that, the overhead isn't worth it. Above it, being wrong is expensive.
- Book a recurring hour to read tickets and usage togetherOtherwise the loudest recent conversation sets priorities by default.
- Revisit your "wrong if" lines on scheduleThe calendar entry is what turns decisions into learning.
Common mistakes
- Treating the role as scheduling and ticket-writing
- Building from one vivid customer conversation
- Optimising a metric without understanding the behaviour behind it
- Never recording why a decision was made, so nothing is learned from it being wrong
- Saying "maybe later" to everything, so nobody knows what's actually planned
Key takeaways
- The job is deciding what, why, and in what order — and owning whether that was right
- Qualitative evidence gives you why; quantitative gives you how many
- Write the decision, the expectation, and what would prove it wrong, before starting
- Most of the work is declining reasonable requests for stated reasons
Try it yourself
Write a decision note for the last significant thing you built — including what would have proved it wrong. If you can't fill that line, you can't yet tell whether it worked.