There are no PM secrets. Just fundamentals done well.

Nine years in product and the problems are always the same.

Different industries, different team sizes, different tech stacks — the surface changes. Underneath it's always some version of the same three things: the team isn't sure what they're building or why, the priorities keep shifting, and the tickets going into development aren't clear enough to build from confidently.

Fix those three things and everything else speeds up. That's not a secret. It's just harder to do than it sounds.

Why fundamentals are harder than they look

The fundamentals of product management aren't complicated to understand. Discovery before delivery. Clear success metrics before you write a requirement. Priorities that reflect what you actually believe, not what you said six months ago. Tickets that contain enough information for an engineer to build from without a follow-up conversation.

None of that is a surprise to anyone who's been in product for more than a year. And yet most product teams are doing at least one of them badly at any given time. Not because they don't know better — because the pressure to move fast makes it tempting to skip the setup and go straight to building.

The shortcut always costs more than the time it saves.

What good actually looks like

Good discovery means talking to users before you've decided what to build, not after. It means being genuinely willing to hear something that contradicts your assumptions — and changing course because of it. Most teams do research that confirms what they already believed. That's not discovery. That's validation shopping.

Good prioritisation means the roadmap reflects hard choices. If everything is a priority, nothing is. A good roadmap makes it obvious what you're not building and why. That clarity is what lets the team move fast — not because there's less to do, but because there's no ambiguity about what to focus on.

Good tickets mean engineers can build without the PM in the room. Acceptance criteria that are testable. Edge cases that are considered. Dependencies that are called out. The difference between a team that ships confidently and a team that ships nervously is almost always ticket quality.

The thing that separates good PMs

It's not frameworks. It's not tools.

It's judgment — knowing which problem to solve, when to move and when to wait, when the signal is strong enough to act on and when it isn't. That judgment comes from doing the fundamentals consistently enough that the patterns become obvious. You start to recognise the shape of a problem before it becomes a crisis. You stop being surprised by the things that always go wrong.

That's what nine years gets you. Not secrets. Just a better calibrated sense of what matters and what doesn't.

Do the fundamentals well. Do them consistently. The rest follows.

If you're moving from a big company into a startup, the game changes more than you think. And the five recurring problems most PMs face — and what actually helps — are covered here.