Most product managers I know arrived through one of two doors. The first: a junior BA or PM role, someone taking a chance on them early. The second: a customer-facing role. Helpdesk, operations, customer success, manual QA. So close to the problem that fixing it eventually became their job.
Both are legitimate. Both teach you real things. Neither is how I got here.
I came in through a different door entirely. What it gave me, I couldn’t have planned.
The law years
My first professional identity was legal. I worked as a paralegal and law clerk across personal injury, immigration, family, and conveyancing. The kinds of matters where the cost of getting it wrong lands on a real person.
On the personal injury side, I worked both corners — plaintiff and defendant. Not every practitioner gets that. An early education in reading both sides of an argument at once.
But the case I remember most is an immigration matter. An agent oversight had resulted in an overstay. A carpenter, a family man, someone who had spent years working toward residency. I was central to the drafting of a submission to the immigration tribunal. Countless hours and thousands of words on extenuating circumstances, put together as carefully as I could.
Everything he’d built was on the line.
It landed, against the odds, in a highly discretionary process.
That kind of work teaches you something no framework does: what a problem actually costs the person it belongs to.
I’d figured out well before the end of my degree that being a lawyer wasn’t the right path. Carrying those sorts of problems, every day, takes its toll. I finished it anyway. Still the right domain, still worth doing. Quitting felt like the wrong lesson.
It wasn’t law I fell out of love with. It was the industry’s relationship with technology. Law firms, for all their expertise, were operating in ways that technology had already solved elsewhere. Manual processes. Disconnected systems. People doing work that didn’t require them.
Around 2010, Richard Susskind’s The End of Lawyers was giving the industry a name for what was coming. I was at a firm whose managing partner had read the book and decided to be ahead of it. I moved from law clerk to Legal Systems Manager: practice management migrations, integrated web forms, document automation, data reporting. I was building things. Figuring out what people actually needed, then making it work.
I didn’t know it yet, but I was doing product management.
A consulting business
Then came the consultancy.
A colleague and I spotted the opportunity: every firm we knew had the same problems and none of them had the internal capability to solve them. We co-founded a business, took the firm we worked at as our first client, and spent the next several years building platforms, client portals, and efficiency tools for small and medium firms across Australia.
This is where the real education happened.
The thing nobody tells you about consulting: a bad requirements conversation costs you twice. Once in the rework. Once in the client who doesn’t call back.
I learned this building a conveyancing workflow for one of our clients. We’d missed a handful of key steps in the initial scoping and underestimated the complexity buried in others. The rework was real. The scope problem I’m most honest about, though, is the one I created myself. There was an automated settlement calculator in that project. Outside the brief entirely. I built it anyway. I couldn’t leave that problem alone. It was worth it. Worth it and repeatable are different things. Scope creep you choose is still scope creep.
When you’re billing by the hour (or delivering within a fixed budget) and your next engagement depends on this one going well, the discipline that product management tries to install through frameworks and rituals becomes second nature. You learn to ask the right questions upfront because the alternative is painful. You learn to scope ruthlessly. Every unplanned hour still has to come from somewhere, and it usually comes from quality. Quality problems come back. You learn to manage expectations because a client who’s surprised is a client who’s unhappy.
You learn that the real job is understanding what someone actually needs, not just what they said they wanted.
We’d sit with a firm principal and walk through their entire client lifecycle. Where were the delays? Where did things fall through the gaps? Where were people doing repetitive manual work that made no one’s life better? Then we’d go away and build something that solved it. Implement it, train on it, iterate, support it.
Requirements gathering. Scoping. Development. Testing. Implementation. UAT. Iteration.
If you wrote that out as a job description, you’d call it product management.
The realisation moment
I remember reading the position description for my first formal product role. Running down the requirements, one by one, and realising: I tick all of these. Every one. Not in a theoretical way. I have actually done this.
I wasn’t learning a new discipline. I was finally putting a name to what I’d been doing for a decade.
The transition wasn’t difficult in the way people expected it to be. The hard parts were already familiar: ambiguity, competing priorities, stakeholders with conflicting needs, building things that actually get used. What I had to learn was the vocabulary and the scaffolding: PRD templates, sprint ceremonies, product frameworks. Those were learnable in weeks.
What couldn’t be learned in weeks was the instinct. The ability to sit in a discovery session and know where the risk was hiding. The comfort with the gap between what’s been specced and what’s actually going to get built. The understanding that shipping something is the beginning of the conversation, not the end of it.
That takes years. And for me, those years happened before anyone called me a product manager.
Product through experience
I’m not making the case that consulting is the only path, or even the best one. We didn’t scale the business. By conventional startup measures, that’s a footnote. But what I walked away with: the instincts, the scar tissue, the feel for what actually matters when a client is unhappy. That’s not something you can buy. I’m not being romantic about it.
The doing matters more than the title.
The PMs I’ve worked with who are hardest to rattle are the ones who’ve built something from scratch, delivered it to a real user, and felt the gap between what they intended and what actually landed. The ones who’ve had to explain a delay to someone whose business depended on the thing you promised. The ones who’ve worked through a problem not because it was assigned to them, but because no one else was going to.
There are a lot of ways to get that experience. A side project. A startup. A role that wasn’t called product but required product thinking. A consultancy of two people trying to keep the lights on.
The curriculum isn’t always the one with a name on it. Sometimes you’re already in it.
If you’re somewhere in the middle of an unconventional path, not sure whether it’s leading anywhere useful: it probably is. It usually just takes a while to read the map.