About
I go looking for what's broken, and come back with a position on it.
I'm Harry, a product manager in Manchester. I came up through marketing and customer onboarding, so my instincts were shaped by watching real people use products rather than by a roadmap.
Manchester, UK
Working as the only PM
For four years I've been the whole product function at a B2B SaaS scale-up. No product team to delegate to, and no senior PM to sense-check with.
It taught me three things. Be ruthless about where your attention goes. Treat engineering, data and commercial teams as your extended team, because those relationships set the ceiling on what's possible. And hold strategy and delivery at the same time, because nobody else is holding either end.
It also taught me to make a call, explain it clearly, and stay open to being wrong about it.
Range
A colleague once described me as a bungee jumper. I can go from the detail of a requirements document to a strategy conversation with the CEO and back again inside an hour.
That range is what I'd point to if you asked what I'm good at. Most bad product decisions I've seen in small companies come from working at only one of those levels: strategy with no grip on what's buildable, or delivery with no idea why.
How I prioritise
Less a scoring matrix than three questions. What does it cost us not to do this? Who does it unlock value for, and how much? Can we do it well, or will we have to undo it later?
The third question matters most. Half-built features create more drag on a small team than the gap they were meant to fill. That's why I use SLC (simple, lovable, complete) rather than MVP. In B2B SaaS, users have little patience for rough.
Working with people
Alignment isn't the same as agreement. I'm rarely trying to get everyone to agree with me. I'm making sure everyone understands the decision, why it was made, and their part in it.
I spent four years automating work that talented colleagues were proud of. I treated their concerns as useful signal, not obstruction. Several of the safeguards that made our AI output trustworthy came straight out of those objections.
Evidence
Numbers are for judging outcomes, not for putting off decisions. The question I ask is: what would we do differently depending on the answer, and is finding out worth the cost?
When I move on judgement, I name it as a bet, in front of leadership, and I look honestly at what happened afterwards.
Where I do my best work
I do my best work on problems I can get behind. When I care about the problem, I'm better at the unglamorous parts and at the conversations where someone needs to hear something difficult.
I thrive with autonomy: the freedom to find problems rather than be handed them, and to form a view before I'm asked for one. I'd rather be argued with than agreed with, and I'll push back, including upwards, when I think a decision is wrong.
I'm happiest in lean teams with light process, where decisions are made quickly and in the open.
What I'm looking for
A product manager or product marketing role at a startup or scale-up building something I can get invested in, where the person doing the job is trusted to find the work rather than wait for it.
I'm not chasing a bigger title. I'm looking for a problem worth years of attention, in a place where the best ideas turn up in conversations between teams rather than in a planning cycle.
Writing and talks
I write and speak about employee voice: why feedback so often fails to turn into change, and what to do about it.
Outside work
I'm a lifelong Leicester Tigers fan, and I built Meet in the Stands to help away supporters find each other on match days. I'm also a trained Mental Health First Aider.
Principles
SLC over MVP
Simple, lovable, complete. Minimum is not the same as simple.
Name the bet
Say what you don't know up front, so the result can be judged honestly.
Resistance is signal
Pushback usually points at a real risk worth understanding.
Define good first
Agree what good looks like before building, so quality can be argued about.