I didn’t plan to end up in product. I planned to be a lawyer.
Background
I studied law and worked as a law clerk (paralegal), covering personal injury, immigration, family and conveyancing matters. Real problems. Life-changing consequences if you get them wrong. Along the way I completed secondments to a law firm in the United Kingdom as part of a joint venture, and to the in-house legal team of a major Australian bank. I understood quickly that the law mattered deeply to me, but that being a lawyer probably wasn’t the right path. I ultimately completed a Bachelor of Laws (Hons) and a Bachelor of Business, majoring in Management and Leadership.
What I couldn’t ignore was the gap. Law firms, for all their expertise, were operating in ways that technology had already solved elsewhere. Around 2010, just as Richard Susskind’s The End of Lawyers was giving the industry a name for what was happening, I moved from law clerk to Legal Systems Manager at the firm I was working at. Practice management migrations, integrated web forms, document automation, data reporting. Oh, and performing the in house IT service management. It was early, and it was the right moment to be in it.
That experience led to something I hadn’t planned either: co-founding a consultancy with a colleague, taking our own firm as our first client, and spending the next several years helping other firms of all sizes, with different systems and different problems, do the same thing. It was here that I developed the deeper technical range that still shapes how I work: coding, cloud technologies and the SDLC. We built integrated platforms, client portals, and efficiency tools. We figured things out by doing them.
Looking back, both the Legal Systems Manager role and the years of consulting were product management in everything but name. Understanding users, defining problems, shaping solutions, then building and delivering them end to end. At the consultancy, this was the whole job: requirements gathering, scoping, development, testing, implementation, UAT, iteration. When the time came to step into a formal product role, I wasn’t learning a new discipline. I was finally putting a name to the one I’d been practising for a decade.
The product chapter
Eventually I made a deliberate decision to return to a larger organisation. I wanted scale, resources, and the opportunity to lead people, not just projects. The opportunity was to join a global platform and shared services team as their first dedicated Product Manager, brought in to introduce product thinking and help the platform scale.
The company happened to be a legal tech business I already knew from the other side: I’d been a customer of theirs during my years as a law clerk, and still remembered their email footer from back then, quietly noting they’d placed highly in that year’s best places to work. I was the right person at the right time, but only because I’d spent years building an unusual combination of skills that most people had developed in isolation from each other.
I’m now a Senior Product Leader with my own team spanning Product, QA, Change and Project/Program Management, with significant influence over the platform and shared services strategy and direction. The platform operates globally, supporting regional businesses who in turn serve their own local customers. It’s a multiplied kind of impact, and exactly the kind of problem that rewards breadth. Something I’ve spent my whole career building.
How I think
I’m a self-taught developer, not a software engineer. Web technologies from the ground up: HTML, CSS, and JavaScript, then into the backend with SQL and PHP, and Node as JavaScript moved server-side. Vue became my front-end framework of choice.
I sometimes describe myself as a Hackathon Developer: what I love is building something that works and solves the problem. The fun is in the problem solving: the architecture, the what ifs, the moment something clicks. The maintenance, the framework churn, the dependency upgrades. I don’t find that part enjoyable. AI has changed that equation: I can stay in the part I love, and let the rest take care of itself.
I believe in pragmatic results: being in a position to connect enough dots across law, technology, product, and people to make the safe bets that others might hesitate on. And equally: to move quickly back through the doors that are easy to return through when the signal changes.
I have an endurance mindset. Whether that’s cycling, building something late into the night, or working through a problem that probably won’t resolve the way I hoped. Knowing when to stop chasing the outcome is a skill. Leaving without the lesson is a waste.
Why I write here
I write for people building careers that don’t fit neatly into one lane. The PM who wants to understand the technical side without becoming an engineer. The developer thinking about making the move into product. The aspiring leader watching someone navigate the same road a few steps ahead.
I don’t have all the answers. I have a lot of experience, a compulsion to keep asking what if, and a genuine belief that sharing the work (including the friction, the pivots, and the what ifs) is more useful than polished retrospectives.
If something here resonates, connect with me on LinkedIn.