How I think about Product Management
These are the principles I find myself reaching for most. Not a framework — just things I've found to be true.
Outcomes over output
Every feature is a hypothesis. You ship it to change a metric the business cares about — not to close a ticket. If you can't say what number should move and by how much, you're not ready to build. Track it. Analyse it. Be honest when it didn't work.
Strategy is what you're not doing
If you haven't named what you're saying no to, you don't have a strategy — you have a backlog. Strategy means making real choices under constraints, and being able to explain those choices to the team so they can make good decisions without you in the room.
De-risk before you scale
The four risks that kill products are value, usability, feasibility, and business viability. The job before building is to find the biggest one and kill it cheaply. Most teams skip this and end up months in before discovering the fatal flaw that a three-day prototype would have surfaced.
Fast decisions are usually good decisions
For reversible decisions, bias hard to speed. The cost of slowness compounds quietly — slower teams, lower morale, missed windows. For irreversible decisions, raise the bar. The mistake most PMs make is treating both the same.
Enablement is a PM deliverable
If Sales can't explain it in a sentence, it isn't ready. PM owns the one-pager, the demo script, the objection handling, and the ROI proof points. Shipping the feature is the halfway point. Shipping the whole experience is the job.
Think big, start small
The best product work holds two things at once: a compelling vision that's worth orienting a team around, and ruthless pragmatism about what ships first. Vision without execution is daydreaming. Execution without vision is just churning tickets.
Accomplish everything through others
The PM's leverage isn't personal output — it's alignment. When the whole team understands the strategy and what success looks like, good decisions happen without you. That's the goal. Your job is to make everyone around you more effective, not to be the smartest person in the room.
I came to product management from engineering and research, which means I spent years thinking in systems and evidence before I thought in roadmaps. I think that background makes me a better PM — more comfortable with ambiguity, more sceptical of solutions before the problem is properly understood, and more honest about uncertainty.
I'm six months into being a PM by title. Most of what I know came from doing adjacent work badly and learning from it.