My path to working in Product

There was never a moment where I felt that destiny was pulling me towards a career in product. Though I have come to realize that those moments tend to live mostly in fiction. Despite all that, I currently find myself as Head of Product in a growing technology startup. I get asked every now and then, "How can I work in Product?" Which I'll muse about here for a moment.

In a deeply condensed version of how I personally got here, I started my adult life studying electrical engineering. Living in Australia the main option for engineers at that time was in the mining industry. I spent several summers working at mining companies, becoming disenfranchised with the idea of working in that industry forever. I would work to rapidly complete, and often automate, as much of my work as possible giving me a little bit of extra time to work on other projects.

These were work adjacent projects for the most part, I tried to find areas of the business that struck me as inefficient and craft tools to help. At the time I can confidently say that my main drive for building things was a pure love of building. How often what I build was used was a secondary concern.

Late in my undergraduate studies that began to change. I still loved to build things, but I started to see the value in choosing what to work on based on problems. At this stage, full of confidence and somewhat sparse in real world experience, those problems were more often chosen by others. I was younger and looking back I am glad I had the guidance. I see a lot of people with an abundance of talent but lacking a clear problem to solve, they either become frustrated or trick themselves into working on something.

Over time I worked through both further study and further work. I spent time outside of study either teaching or working as a developer for hire. During that time I learned that problems very often disguise themselves as solutions. What I mean by that in particular is that people tend to describe the problem they're looking to solve as a solution that needs to be built.

When you're a contract developer there's a need to be careful in not pushing too hard on direction, after all it is someone else's project. That being said, the projects I felt ended the best were those that had a little bit of flex. I spent a lot of time up front trying to understand the underlying problems however hired me was trying to solve. If I had a good mental model of how they looked at the world I could make decisions that mostly aligned with their thinking.

This also helped when decisions had to be made that didn't. Every now and then something I'd been asked to build had a meaningful flaw. Many of these projects were a combination of hardware and software, with most of the flaws being poor hardware choices. I worked on a speech detection product looking to use accelerometers on the chest rather than microphones. The idea was initially an attempt to increase privacy but the need to constant calibration far outweighed any benefit.

During these projects I learned to push back when necessary. As both an engineer or product manager, my job was to be the expert in designing solutions. Imporatntly that was different than being an expert in the problem space. There was little I could do in a three month project to surpass what was often decades of industry specific knowledge.

As my PhD came to an end I found myself in a peculiar position. I had a set of very particular skills in an extremely narrow field, medical imaging. I also had a set of skills to take problems from a broad set of fields and help form them into products.
At this stage I had mostly done both of these things alone and was now stuck determining what to do next. I knew I wanted to work with a team of people rather than continuing solo but I had to decide if I was going to double down on a niche field or try my hand at something new.

This feeling of 'something new' has come up several times throughout my subsequent career. In the early days I looked at each shift as starting over. I'd move to a different problem space, work with a different core technology or seek to help a different market segment. At the time, this feeling was mostly negative. I had the feeling that I was undoing years of hard work to start again from the beginning. What I didn't notice at the time was that along the way I was building a different set of skills.

I think a lot of this worry came from my background as an engineer. I saw technical output as the sign of success and wrapping up a project or job for a new one felt like an end to that output. I had convinced myself that making those jumps was stopping me from becoming a specialist in any one thing. After enough time however, I started to see the bigger picture.

What struck me as interesting in all of these projects was the process of digging into a problem and finding a clever solution. Here I don't mean clever in the sense of technically clever but one that felt 'good' to the user. I'd moved from working alone to working with, and eventually leading groups of people to find and solve these problems. The more my teams grew, the less I was solely responsible for the technical output and the more I could see the value in the role of product management.

Becoming a founder (technically for the second time) crystalized this for me. In the early days we had no team. Building things, marketing them, understanding the users, everything happened together and very quickly. We were working on a product using AI to look at medical data, started in 2016 at a time where there was a lot of hype around AI medical devices but limited output.

As we grew the company and the team, more of my time became focused on ensuring the product we were building solved a real problem. Given the nature of the space there were many companies diving ever deeper into technical rabbit holes looking to solve the most gnarly problem they could find.

While the company ultimately wound down, I'm proud of what we managed to accomplish. We focused on building product that had immediate applications for patients and manged to bring a product to market and help a number of people.
Staying focused on product certainly helped us get there. We tempered technical outputs with reality which helped us get something real out into the world.

That isn't to say product management is non-technical. Far from it. While my immediate role doesn't involve being an IC I still spend a lot of my time building. It might be prototypes, side projects or just learning new technologies. I've found that having both technical know how and a good sense for product helps tremendously.

My role is often bridging customers and different teams in the organization. Being able to both pitch an idea during a sales meeting and talk deeply about technical decision with the engineering team helps me be that bridge. I spend a lot of time needing to 'go wide' and and similar amount of time needing to move from the very high level down to the minute detail. Having the opportunity to contribute to so many moving pieces is its own reward. There are almost no lines of code or designs with my name against them but I can see how the work I have done has helped move things forward.

In my current role as Head of Product much of my time is spent trying to grow and align our team. A day only has so many hours and to achieve more I need to be empowering a team of people rather than attempting to take on more myself. In doing so I'm fortunate enough to work with excellent people at many stages of their product career. More than anything else it has been interesting to see the varied paths to a career in product. Mine started in engineering but I have been lucky enough to work with excellent PMs with vast and varied backgrounds.