How I went from Technical Support to Technical Product Owner in MedDev
Matthew Thomson
From Technical Support
To Technical Product Owner
In Sydney, Australia
Background
I’m the Technical Product Owner at Omniscient Neurotechnology aka “o8t” with a mission to improve the lives of billions through Connectomics.
Connectomics is the large-scale analysis “Omics” of the Connectome (connections in the brain), akin to Genomics for Genes, and we have a Product called Quicktome with two FDA & TGA clearances for Neurological planning. The typical user is a Tumour Neurosurgeon deciding where (and where not) to cut into a patient's brain, but we’re always intrigued by adjacent use cases seen in healthcare settings. The field can be daunting as our customers are using our Product to make life-changing decisions, so defining how we can provide insights through our product development is incredibly rewarding.
The fast forward of my career was;
three degrees in Maths, Physics & Electronics, then
three years working for NZ’s government research institutes utilising ultrasonics for industrial and medical imaging, followed by
6 years in a digital dentistry tech integrator in Support, Managerial and Technical Product roles.
I’ve been at Omniscient for 3 years beginning in Support Engineering and now Product.
With my set of skills, and with MedDev being a regulated industry, my compensation is towards the higher end of the market when benchmarked against the 2023 Think & Grow - Australian Tech Salary Guide.
Why I chose Product Management
I didn’t deliberately choose Product Management, it almost chose me!
I fell into PM while working in a Technical Support role in digital dentistry, as I needed to understand our customers’ practical application of the Product. In a given morning, I would help an oral surgeon with intraoral scanners (instead of putty moulds for teeth), refine dentures in CAD software and then advise an Orthodontic lab on optimal 3D printing techniques for clear aligners - and most of the time over a video call and screenshare.
This repeated embedding of myself into their workflow (virtually) was the perfect training for Product - hours a day of learning what they already did (both analogue and digital), what they won’t change (healthcare is justifiably a slow mover) and what they could change.
Without realising it I was working in Product but with a different title, and loved it!
“I love knowing a bit about everything that’s going on, rather than being siloed”
As the company expanded overseas, I became more involved in assessing vendors’ products and naturally moved into a Product role full-time. The work wasn’t traditional Product work as I didn’t have as much sway over a vendor’s personal roadmap & product development. Instead, we were focused on how we could package a variety of vendors' products to improve our customer’s workflows.
With my strong technical background, I enjoyed exposing myself to the more difficult specialities that were using the latest tech, rather than a garden variety corporate or suburban clinic. I quickly learned to communicate with highly trained people in a clinical environment.
My current product role is a great reflection of my skills & strengths. I’m primarily Technical, with Application a close second, and enough business acumen to contribute to the Commercial aspects.
I love knowing a bit about everything that’s going on, rather than being siloed. I see this as core to success in Product; being able to put the pieces together from all sides to decide what to build next. I also love the Why behind MedDev - helping medical professionals care for their patients, which is very satisfying. Knowing my work contributes to a cause greater than “next quarter’s shareholder returns” is a big part of what drives me.
How my prior professional experience affected my transition
I learnt early on that my Commercial skills and business acumen weren’t as strong as others in Product because I had no formal training and simply hadn’t been exposed to the world of purchasing and selling. My technical background partly caused this naivety - I had thought, “Oh, someone will sell it and a customer will surely just buy it because it has bells and whistles”, but exposure to the fiscal realities of business quickly baptised me.
I didn’t have time to study for a qualification, so I set about talking to the finance team to gain an understanding of how their world works.
Indirectly, I gained another skill - learning to ask for help. In a startup, I had access to everyone including leadership, which is a great opportunity to ask the all-important Why’s. Asking for help also improves interdepartmental relations as it forces people to move out of their individual siloes and consider how to explain their work to colleagues. For example, as the technical team we had to inform finance of what the product even is and why a medical specialist would need it - my naivety of selling was mirrored by their “But haven’t doctors been treating patients without this tech for years just fine?”.
Naturally, asking for help the first time is tough, as you're conscious of people's time and distractions. I’ve found that walking up to a colleague's desk with a very specific context and a clear benefit to them is a useful strategy. For example, a salesperson will always want tips to sell more, so opening with "Hey, we're hoping the value add of ‘ABC’ will be more obvious, how would your leads feel about framing ‘XYZ’ in the workflow?" which helps your colleague feel involved and valued, as well as establishing a rapport with them providing useful knowledge.
“I was advised that the hours listening to lectures and reading could be better spent learning the product inside out ”
Understanding this led to developing another skill through trial and error - context setting in common language. Communicating a universal understanding of what a company, team or product are trying to achieve is important and is vital with external facing roles such as Product.
Most of my skills were developed on the job, with colleagues and customers.
Through LinkedIn and talking to friends in larger organisations, I hear about online courses, both free and paid. However, I was advised that the hours listening to lectures and reading could be better spent learning the Product inside out - all the interview templates in the world are no substitute for subject matter expertise!
How I planned and executed my transition from Engineering
Planning my career transition was a slow burn and an organic accumulation of understanding, leading to a decision that I desired a change. I was fortunate to work closely with the Product people from our partner vendors who would visit us (as we were technically their customer). Seeing their procedures, being asked their questions and asking targeted questions regarding how they would pass on the field’s feedback internally was a great opportunity to “See One, Do One”.
I observed first-hand how a Product team’s role was to ask end users a few questions, listen more, and, if possible, be a fly on the wall to see how the end user really used it, especially when they didn’t know they were being watched!
When it came to “Teach One”, I ensured that when my employer backfilled my Support role, I would give the next person a great onboarding, including all the context that Product can provide. Having the Support team “on my side” from day one meant I could leverage the relationships they would build, as I had, and ensure regular contact with the end users was continued.
“To demonstrate that my capability matched my enthusiasm for Product, I pursued projects which I could own”
Working for two startups in a row, my inclusion in the companies was to provide technical expertise to support the founder’s deep Application and burgeoning Commercial skills. In both instances, the founders themselves had made the transition from a professional end user to supplier. They were very helpful with their time and knowledge, so shadowing them to better understand how they’d develop business plans or new offerings was invaluable.
I never interviewed for my Product roles as I was already employed, so it was informal - I had been in prior roles at both companies for 2+ years so my technical skills and application understanding were already well known. With both changes I had made my intent for growth known informally to the leadership, and framed in a mutually beneficial context - the company would retain an enthusiastic and valuable employee, I would progress my career (with an unspoken implication I would remain for longer) and as I was eager to backfill the role I was departing I’d be driving the hiring of that which reduced management’s burden.
To demonstrate my capability matched my enthusiasm for Product, I pursued projects which I could own and prove that I was already ‘Product Lite’. This part was daunting as I still had to do my day job, but horse-trading with other colleagues who might want to take on some of my existing role’s responsibilities provided them an opportunity too.
What's next with PM experience
I didn’t know Product was a role until half my career ago, and I don’t know what I’ll learn in the next half! So I will stick to what I know makes a difference and what I’m good at, whether that is at a startup in MedDev or a more established company in another industry.
My career started at the “Can we make this work once, maybe 10 times, then give it to someone else to pass Regulatory, make work 100,000 times and sell?” side of Medical Devices, then leapt across to the “Someone else made it work enough and passed Reg, can we sell it?” and now I’m in the middle at “We’ll take something that’s been proven 10 times, get it through Reg and sell it ourselves” which is where I want to be.
Advice
In hindsight I wish I’d known earlier (the age-old cry of Product) that Product is like a 3 legged chair:
Technical “What we can build”
Application “Why we should build it”
Commercial “How will we sell what we built”
Successful Product people are often strong in one, pretty good in another and the third could almost be considered a bonus - it is difficult to be great at or find the time for all three.
Product is ideally a team made up of people with complementary skills of the three - I’ve worked with a few great people who are strong in the areas I’m not, and this combination feels like it really hums.
I was fortunate to meet a great Product leader, Rune Fisker, who has lived the startup dream - being employee #1 to the SVP of an incredibly successful company 3Shape. There’s an interview with him HERE, which condenses 20 years into an hour. I draw inspiration from Rune as we both came from a technical background and learnt everything else as we went, driven by an extroverted personality and desire to see things implemented well, to the benefit of patients.
