How I went from management consulting to Head of Product in MedDev
Bryan Sin
Background
My journey to my current position as VP of Product has been one full of detours. My background is in Manufacturing Engineering at the University of Cambridge. However, despite its name, the degree did not focus only on material science and factory management, it was much wider than that, focusing on innovation, entrepreneurship, business plans and generally ‘making stuff available to the world’.
Graduating from Cambridge, I felt that while I was strong on the technical side, I needed to get a lot more insight on how to work with people and more importantly, how businesses work in the real world. I ended up in a consulting role at Oliver Wyman London to fulfil this desire to be more of an all-rounder. As a consultant in Financial Services, I had exposure to a lot of companies via a mixture of short-term and long-term projects in several sectors - Retail, Corporate & Institutional Banking, Risk & Finance, and more.
It gave me a lot of perspectives on companies which deal primarily with consumers, or other small businesses or other large institutions. It gave me a lot of skills too: how to communicate internally and externally, to technical people, business people or executives, how to manage projects and teams. My mix of technical and people skills put me in the perfect position to interface between highly technical engineers and other stakeholders - executives, business, marketing or customers.
This is the position I was in when serendipity hit. We had a project which eventually evolved into my current employer, Omniscient Neurotechnology. Although I worked primarily on the analytics side, my role as the project manager required me to be across all aspects of the project and technology and making sure to communicate excellent progress from our Subject Matter Experts (who eventually became the founders of Omniscient). When they needed a Head of Product, it was an easy decision to take up the role.
How did you execute your transition to Product Management?
Through my consulting experience, I already had a lot of skills relevant to Product Management: working with customers and executives, devising product features (or project deliverables) and implementation plans for said features.
I was constantly asking myself questions like;
How does the product work?
How do the analytics fit in and support the work we’re doing on the Product?
What features are we building and why?
How do these features balance our stakeholders’ needs with our business needs?
How do we work with our engineers to deliver these features on time?
I really enjoy wrestling with these core strategic questions. However, Omniscient was an early-stage start-up at the time. Nominally, my job was product management, but I also had to get my hands dirty with parts of the business that did not even exist at the time. I did a bit of customer tech support and a bit of pure engineering and coding, but my core role remained project and product management - a coordinator role between engineering, business, executives and customers.
All of these things were really exciting and interesting but also quite intimidating. As consultants, we need to be “T-shaped” people - very broad in knowledge especially early in our careers, and then specialise in one aspect of our chosen industry. Even then, we reach a limit beyond which we simply have to consult an expert. Within a consulting business, the reasoning is simple: our time is too expensive to the client to justify doing the nitty-gritty. However, in a start-up, if I didn’t know, I needed to find out. There are no places to hide. With that, I naturally felt a lot of imposter syndrome - that I’m not good enough for the responsibilities thrust upon me.
But I was no stranger to ramping up fast and making that knowledge my own. Our head of sales had a background in Product Management, and our head of regulatory knew all the ins and outs of how to get a product cleared. Despite my lack of experience in the medical device industry, I was lucky to have access to very knowledgeable colleagues who helped me build up that knowledge quickly. I was able to learn a lot about the industry, the regulatory space and doctors (the customers) as well as have access to a network of those doctors to get a first-hand understanding of their experiences.
Product Management was not a role I considered initially, but it became evident through my background in Engineering and experience in consulting that this was the best role for me.
How has your journey in Product changed as you gained more experience?
Primarily, I gained more perspective on what Product Management is, and more specifically, I found it surprising how different it can be across companies and industries.
Today, I understand the Product Management world as a collection of sub-specialties coalescing into two main categories: Market-side product management and Technical-side product management. The sub-specialties you are expected to fulfil drastically changes the type of work that you do. Some sub-specialties are even sometimes delegated to other adjacent departments.
Market-side product management focuses on the industry, competitors, partners, customers, sales and strategies across all those entities. The questions we grapple with on this side are:
Who are our customers? Who are the buyers or stakeholders in the buying process?
What are their pain points? What are the requirements of any solution to these pain points, both in terms of hygiene factors and delighters?
How does the product address this pain point? How does it fit in the user’s current workflow? Does it introduce entirely new pain points that will impede adoption? What’s the user experience?
How do we market the product? What are we even allowed to claim? How do we encourage the sale? How do we encourage adoption?
How do we price the product? Is it profitable? If not, how do we eventually make it profitable (and sustainable)? How big is the market?
How does the product compete against other offerings? What are its unique selling points? How do we counter claims from other companies?
What other products complement our product? Who can we partner with?
A lot of these questions are not only Product Management questions, but also Commercial, Sales, Strategy and Marketing questions. So sometimes these sub-specialities get absorbed into those departments, instead of being served by a dedicated “Product Management” department.
Technical-side product management focuses on the tech, the science, the analytics, the operational questions of the product. The questions we grapple with on this side are:
What are the technical requirements that satisfy our customer requirements?
How do the features fit together? What is the detailed technical architecture and components they imply?
If these are changes to an existing product, are there features that can be tweaked or extended to solve the problem, instead of an entirely new feature that will require a complete redesign of multiple components?
How are those features communicated to the technical team? What do we need designs, process diagrams, and detailed explanations for?
How is the product monitored and maintained? What tools can we provide our service team to do their job? How do we minimise the extra work required for deployments, updates, and maintenance?
How do we control the fixed and running costs of the product to help it be profitable?
How do we explain the analytics to our users, both in training and in-app, so that they know what they are even looking at?
What features can we package together to get a release schedule that is optimised for speed, scope and the number of regulatory submissions we need to do as a result of a particular feature pack?
A lot of these questions are not only Product Management questions, but also Engineering, Customer Support, Product Design, and Regulatory questions. So sometimes, these sub-specialties are also absorbed into those departments.
All these questions are important and answers to them need to be shared and updated frequently across the business. I believe that no single person can reasonably be expected to fulfil all those roles. There is not enough time in the day. At Omniscient, the product management role tends to lie a lot more on the technical side rather than the market side, but we have bounced back and forth on these whenever required.
I would also note that Product Management also differs a lot between larger companies and start-ups. Due to limited resources, start-ups naturally require people to wear multiple hats at once, which explains why I needed to contribute across multiple departments when I originally joined. It is certainly not something I would expect every Product Manager to need to do.
At larger companies, roles are likely to be much better defined and segregated, for better or worse.
Advice for early career PMs
If you are coming into a Product Management role, you should understand how your experience, skills and interests fit into the aforementioned categories of product management. Being good at both is great, especially in a startup as you can be flexible to the changing needs of the business as they arise. However, for an early career PM you would not be expected to be great at both.
When a company is hiring they will have a strong idea of the kind of PM that they need. To work out what a company might be looking for, do your own product discovery work on the company. Do they need better product insights or design or do they need someone who is really knowledgeable about how the product works and can then communicate that to customers to ensure you’re building the right thing?
If you don’t have existing experience in their industry, do your best to learn about it in advance. While it is expected that you will require time to ramp up when joining a company, it is natural that you will have a leg up if you already know a lot about the target user, market, industry, technology of the company you are applying to.
In terms of broader qualities, I think curiosity is an essential trait to demonstrate. Curiosity is how you become more effective and knowledgeable beyond the existing training you might receive at the company. It can be about the users and market, or it could be about the product itself and specifics of how the features are built and work. Curiosity will help you ask the right questions, learn quickly and develop a unique understanding of the product.
Secondly, you should demonstrate a desire to simply get things done, and done quickly without compromising quality. As a PM, you need to quickly learn what your customers want (and I mean really want and not just say they want), define a scope that is going to be feasible in the amount of time that you’re given, convince the execs of the importance of these features, and motivate your team to get them done. Product management is a job full of compromise; you’ll almost never have time and resources to make the perfect product, with customer research covering all your bases, and compatibility with all systems that interface with your product. If you do, you should have launched months or years earlier. If you have an example of you doing that, then you’ll be a very strong product manager candidate.
Insights into the MedDev industry
The Medical Device industry (and other similarly controlled and regulated industries) can have very long development cycles. And rightly so. Whereas an e-commerce company can release every day because their biggest risk is “Customer cannot use the service”, medical device companies must go through significantly more process because the risk could be “Patient dies because of wrong treatment”. Before being snazzy, exciting, intuitive - any of the other elements that might be important in other industries - you need to make sure that your product is safe.
You can’t just develop something today and release it tomorrow. You need to:
Develop it
Write all the unit tests
Make sure that it works
Send it to Quality Assurance for formal validation
If you make any tweaks to your analytics, you need to then do clinical validation exercise to make sure that it didn’t change since last time
If it did change because you intended to improve it, then you have to prove that it is actually improved and is still safe and effective. You and your team cannot do that, the only qualified people to make that judgment are usually busy doctors.
Depending on the changes made, you may need to submit it to regulators, then wait 3-6 months before you are able to deploy it.
During the time with the regulator, that version is frozen with the regulator. Meanwhile, any changes to the existing version should ideally be small enough that it does not cause too many merge conflicts when the clearance for the new version eventually comes through.
Outside of that, you need to be able to talk to and understand doctors and other healthcare professionals, which will usually take a good enough understanding of the science, which in my case is the brain.
What’s unique about medical device work is that you really see the impact of your work for better or for worse. It’s really rewarding to hear stories about how your product was used in helping a patient survive or go through a surgery and come out with no deficits or recover from depression. It’s a really impact-driven industry and for a lot of people it’s probably their driving force.
Resources
In my case, I think I learnt a lot of it on the job and from mentors. The consulting skill set for the business context and managing stakeholders; the engineering background and coding hobby for the technical aspects.
That said, here are some resources I’ve used through over the years:
Books: The Goal (Manufacturing engineering), The Phoenix Project (IT project management)
Blogs: DicomIsEasy (Understanding the medical data format DICOM), Product management articles from BlackBoxOfPM, Product-Led Alliance, and others.
Courses: Coursera / Udemy courses on Python, Python flask, web applications
