Tips for becoming a product manager in health tech/digital health

It's a long way to the top, if you want to rock and roll (and ship healthcare product)

Now and again, someone reaches out to me and asks “how do I become a product manager in health tech” or “how could I get a job at your organization”. I’ve written some versions of this advice to folks on an ad hoc basis but thought it would be a good idea to put all of my thoughts down on paper.

I titled this article “tips” to become a product manager because the paths to and from product management are incredibly broad, especially so in healthcare. In my time I’ve worked alongside former programmers, marketers, analysts, salespeople, support staff, implementation, project managers, doctors, lawyers, professional musicians, fighter pilots and more. There’s no one good way to get into this field. And similarly, sometimes not a predictable way either. In fact, I didn’t do “product management” formally until about 13 years into my career. I wasn’t trying to do it faster, but that’s what it took for me. So, for me to give any advice on how you may do so in 3 years may ring hollow.

The very basic summary of advice is: “get a job, any job, at a healthcare company in digital health that has a product team and then move diagonally into product”. That’s not the only path but it’s probably the most efficient one. However, there is plenty of nuance in that advice. I’m going to split this into two sections “non-PMs trying to become PMs” and “PMs who want to get into healthcare”.

Domain, domain, domain: The key to Non-PMs trying to become PMs.

Part 1: Right Back Where We Started From

Don’t take it from me.

Like a CEO, the Product Manager must deeply understand all aspects of the business.  The Product Manager needs to ensure a business outcome, not just ensure a product gets defined. This requires a good understanding of the many inter-related parts and constraints of the business – financial, marketing, sales, legal, partnership, service, the customer environment, the technical capabilities, the user’s experience, and figure out a solution that works for the customers as well as the business.

— Marty Cagan, Behind Every Great Product

Some people may naturally intuit this mindset or be trusted to do so based upon their education, background or qualification into a given training program.¹ For the rest of us, the first step is likely to become familiar with the nuances of our industry and the product vertical within that industry. In many ways, this is easier with consumer products. You’ve been emailing for 20 years, think of how to improve email to drive growth. You like music? You can build the new AI DJ at Spotify. If anything the risk for failure within these PM verticals is overindexing on known experience and building a product for “you” and not “most users”.

However, in healthcare there are three significant barriers to this learned experience for most people →

1. The most trained caste of our healthcare profession receives 4-15 years of training with extreme degrees of sub-specialization and training. The idea that you’d replicate the entirety of that type of training in days/weeks/months is laughable.

2. Even if you wanted to, it is impractical to “learn by seeing” often. You probably can’t see doctors use ultrasound in the field or see how they talk about diabetic weight loss unannounced. Without a prior relationship you probably can’t ask the average doctor “hey, can I just sit in your practice for two weeks and watch you do stuff”. This makes Sam Walton-esque “Shop your competitors” approaches difficult.

3. There are real and immediate legal and compliance constraints to healthcare product architecture and usage that are generally table stakes for product development that are hard to intuit. At my current job I talk to our legal and compliance teams weekly and this has been relatively consistent at most jobs I’ve had in the HITECH era. Understanding the edges of organizational risk tolerance (especially your own) are part of the only way to drive good decision making forward.

As such, it’s really not such a bad thing to start somewhere else than product on the ladder in healthcare. Patient care or entry-level positions as an analyst, implementation, support or marketing/sales can teach you so much about the field. And, especially, this company’s product and way of doing things. Why, in general, do people buy your stuff? When does the company move fast? When does it move slow? How does it make decisions at impasse? Who “runs” the company… clinical, engineering or sales? How does the voice of the customer turn into software? These lessons can be learned from a variety of entry points.

It is best to do this at a company that has a well-defined Product Org with PMs. Partially for diagonal movement but also to see how people in these roles work and tick. This is much more common now in healthcare but you could still work at a variety of places which do not have PMs or where PMs operate as project managers or tool administrators. There is nothing more disheartening than interviewing someone and asking them what drives their passion for the field of healthcare technology and they tell you how much they love Smartsheets and JIRA. This isn’t unilaterally bad and any foot in the door is better than none. But if you can, find a company with an ideal product org.

Part 2: Before becoming a Product Manager, be a good Product Buddy

Ok, so you work at a digital health company now and you are settling in. In general, no one is going to allow you to move diagonally within roles if you are doing a bad or mediocre job in your current role. Do your best to be one of the best on your team. Do the dirty work. A year or two has passed and you know your business, your product, your vertical decently well. Rad.

Product Managers are generally a sociable group, and it would be good to know them both personally and professionally. After all, the first thing the PM lead is going to ask about your candidacy is whether or not the other PMs like working with you. The nature of the role is collaborative after all, so no one will want to work with an unknown entity or someone they actively loathe during interactions.

Alongside personal relationships, you then want to work on product-adjacent professional tasks within your existing role. Some examples →

• For implementation/customer success, you likely have a great pulse on voice of the customer. But taking VoC from 20 implementers sometimes can lead to bad signals from your worst customers or worst implementers. Organizing a forum to organize requests and attempt to group them based on business value and not the loudest voice/fastest ticketer would go a long way and would show your abilities as a bridge builder.

• Support can have something similar to the implementation forum and can also be a great partner in ensuring that product documentation is good. Pitching in to improve documentation quality and KBs usually has a good overlap with product work.

• Marketing/Sales and other roles likely will work closely with PMs on winning deals. Demonstrating some product thinking as to what features would help with the storytelling to win deals or drive growth would be a great PM audition.

• If your job is Clinical SME (which usually overlaps with some of these other roles), try taking a stab at refining a few requirements for features yourself when the PM comes calling. Evolve from end-user mindset to business/product owner mindset.

Also, at this point you want to be openly circulating that you are interested in product positions to your boss and the Product Lead. Probably don’t do this on day one. There’s nothing wrong in saying that your 5 year plan involves getting more involved with product but it’s a weird thing to do upon joining a company to basically indicate that you are not that interested in your current job role.² If you are trending at your current job role it is likely that your boss/bosses boss would love to keep you within their org. You’ll want to demonstrate the value of keeping you within the organization and as a voice for their company pillar within product.

Part 3: Good Will Product Manager

Ok, so you’ve got domain chops and the PMs at your company generally like you and see you as an ally in your vertical. Someone has proposed giving you a chance or has invited you to apply for a PM role at the company. Great news. At this point you think “oh my gosh, I need to learn all of these processes and formats: PRDs, PSDs, Roadmaps, Sprints, Tasks, Releases and more.”

That’s not the game.

Process is so different at each product org that it’s not worth over-indexing on. You are auditioning to determine if you are a product person and unless you are at the DMV of Product organizations people probably don’t care explicitly about your documentation formats on day one. At this point your hurdles are three fold:

1. Can I see the whole elephant? Other job divisions may have the luxury of only needing to think about and advocating for their own team’s benefit. A salesperson may want less specific SOWs, which causes friction to the implementation team that would prefer more clarity in delivering on those SOWs. The implementation team may prefer making a feature to cool customer temperatures vs. articulating the value of the existing features. The engineering team may prefer to focus on stability of the existing codebase and features vs. building new features for sales and implementation. And so on. This isn’t a bad thing! Usually decisions, good or bad, are made at the intersection of this friction. A leader of a business pillar shouldn’t be entirely devoid of concern or empathy for other business pillars, but should assume that those other pillars will figure out how to solve any second order problems created by actions that favor their org. As a PM you do not have that luxury. Understanding every business pillar concern and trade-off and making the right decisions is your job.
   
   It’s not unreasonable to get into product because you think you could do a better job actually “making” the software. It’s why I became a programmer and it’s a common PM origin story. However, unlike the person who took a job, fixed a bug and then quit you are probably in it for the long haul. As you shift from your old role to your new role, the tradeoffs inherent in product decisioning in the job may become more clear. “Oh yeah, there was no churn risk, user metrics were good and feature parity with the competing product already… of course we didn’t fix this JIRA ticket immediately just because one vocal non-KOL user complained.” However, if you do not see the tradeoffs and lean towards your previous biases you will probably not last long as a PM. You have to make all of your stakeholders happy enough.

2. Can I communicate intent to engineers and designers? “Well, my upward and outward stakeholders are satisfied. I’m doing a great job!” Perhaps, but you are only part of the way there. Unless your PM job is purely the oversight of a sales-driven feature factory, engineers and designers probably control some of your destiny as a new PM. The reason for this is relatively simple: they make software, you don’t. If you, the PM, were suddenly spirited away to Agile Valhalla…. they’d make computer software without you. Bugs would get fixed, new features designed, code would get pushed to prod.
   
   Now, would those eng/design teams do a good or efficient job at it without a PM? Probably not. But realistically they can call for your removal by stating their dissatisfaction with you as a PM. Most PM problems come from not clearly delineating or living up to the 5Ws of product management.³

   Why - Product Manager: As PM, it’s usually your job to determine why a given task is important and how it fits into the bigger picture. If it’s not important, you should de-prioritize it. This serves as an anchor to engineering and design; it also rallies your team around the mission by helping them understand a task’s importance to larger company strategy. “Hey, we have to do this data thing by March or else” is not as inspiring as “10,000 doctors will use our software and they are relying on us to finish this data feature to make patient care better every day”.

   What - Product Manager: You’ll write the initial requirements and sharpen them based on feedback from the developers and designers working on tasks. On clinical tasks you’ll work closely with your clinical owners and stakeholders to ensure these features are good to both patients and providers.

   When - Product Manager/Engineering Manager/Design Lead: As PM you’ll likely have initial input on priority of the backlog which then gets translated into actionable tasks to fit in a working period of time owned by operational owners. This responsibility is shared.

   Who - Engineering Manager/Design Lead: One of the more meddlesome things you can do as a PM is try to tamper with who does what work. Maybe you know that Steve always gets it right the first time or that Laura is an ace designer. But you as PM don’t get to control that and circumventing this to investigate bugs or do quick mockups wrecks this whole chain of trust.

   How - Engineering Manager/Design Lead: As a PM, especially if you are more technical or design focused in origin, you may have ideas as to how to approach a problem. And, you should feel free to recommend those things while planning to your counterparts. However, it’s their prerogative to do something different if they want to since they ultimately have to live with those decisions forever.

   
   If you as PM cover zero Ws, your job is just secretary to your team instead of being a core contributor. Or, conversely, you can try to own all 5 Ws and your counterparts may not want to follow your lead as a result. Either way, this is a hard road to walk back from as a PM, especially when you are fresh into the role. As a PM manager, I generally tell my PMs that I want to have an idea of when they are going to get into trouble or cause friction. Are you going to push on timelines on your engineering lead counterpart? Do you think the priorities are incorrect in the backlog with too much tech debt to fix? Do you think the software is not performing as expecting? These are all difficult conversations and I generally expect that PMs will not escape these conversations wholly unscathed. However, I do want to know so that when the VP/CTO asks “hey, why did so and so PM say that we had to change things and tip the 5Ws” that I can say “yeah, and I told them to do that or I knew they were going to do that and agreed” (and ideally, had been pre-messaging things in my 1:1s/skips).
   
   Intentional friction is good, which leads to….

3. Are you able to push people and groups towards doing the right things, even when it’s unpopular? Conversely, a PM who gets into zero trouble is also bad! You should be breaking rules and questioning why things are as they are. You should be questioning processes! You should be challenging value propositions! You should say that a feature with feature requests on the board is done and you’ll not change it for awhile! You should say that a feature is nowhere near done and you can’t move onto the next shiny request from sales! You may not be an absolute force of nature like some PMs, but being entirely angelic is also not great. Don’t let your counterparts take your Ws either. Your stakeholders and peers may not always like your ideas at the onset, but you should be able to get a result both at the time of decision and with outcomes based on those measured decisions.

   Other job roles can allow you to entirely be a people pleaser but this one probably less so. But as Tom Morello of RATM likes to say, “embrace your limitations instead of fighting them”. Not having enough of things… time, budget, programmers, designers, alignment can be hard. But can you still ship without them? You want to be the kind of person who ships, even when it seemed impossible at the onset. This involves trade-offs and trade-offs incur friction.

Finally, product management is all about getting it done. You can read books all day, ascribe to frameworks, agonize over PSD wording and meet with people all day. But at the end of the day your job is to make software that people love; full stop. Strategy and tactics are using your arms and legs to swim at the same time; you can be strategic because you are executing on delivery and you can be tactical because your strategy is good.

Part 5: Taking the Asteroid Field - Other Less Orthodox Approaches

If you’re not an immediate super star or willing to play the semi-long game, I guess you can try some shortcuts. I think these all have major downside risk, but maybe they’d work for you.

• The Wizard of Oz. Knowledge is Power → If you have a skill that organizations require, sometimes you can dictate terms as to what your job role will be. It’s not surprising to me that plenty of my former colleagues in Implementation Services from Epic are Product Managers; we knew things about EHRs and how clinicians use them and plenty of digital health companies need someone on staff who knows something about EHRs and how clinicians use them. Of course, just knowing things about domain does not make one a good Product Manager. But, scarcity of skill may help in getting where one needs to go. How this works for you personally will vary and “Become expert in electronic medical records during their zenith” probably easier said than done. I’ve seen this work for a bunch of people but I’d note that they were by-and-large Excellent without exception at knowing the thing they knew about.

  

  Just spend all of your 20s in hospitals around the world away from home learning esoteric rules about healthcare. Easy as that!

• The Swashbuckler. Very Early Stage Company Ahoy → If you’re willing to work for sweat equity or for cheap, there’s probably no shortage of companies that would take your service in return for letting you do some “product” work. You’d likely be an assistant to the product leader founder on the team, but it would be a way to get some progress on experience. However, in this route you’re taking a bet that the startup doesn’t implode and you have something to show for your work. If you can do this as a side hustle or have some savings from another job, this may be even more appealing.

• The Tom Sawyer. Solve my problems as product lead → There’s no shortage of people who reach out to me when I post a job role directly. Other product leaders’ opinions may vary here, but by-and-large this doesn’t help much in my eyes. I mostly stick to my principles above in what I want to see from candidates: product ownership in related roles or PMs with experience who are about to jump to the next level. Mostly these candidates via outreach talk about themselves or their connection to me via some intermediary party. This is not very helpful to one’s plight. What would be helpful is if you solved my problems, even anticipatorily. This takes work, of course.⁴ But you’re trying to stand out, right? You obviously can’t do this in a shotgun approach to a job search… it wouldn’t work 100 times. But if someone wrote up something specific about Butterfly’s Compass or Mayo Clinic Platform Deploy? And it wasn’t bad? It would probably get you an interview.

• The Thunderdome. Searching for APM roles → Associate Product Manager (APM) is generally the “PM-in-apprenticeship” role to groom talent at orgs like Google, Amazon and Meta. I didn’t start as an APM, so I don’t have much experience here. But most APM roles in healthcare in search of an external candidate look sad. I did a cursory LinkedIn search and this is what I found.

  • Up to 75% Travel, starting comp low end at $90K.

    

    Oversees all aspects of Product Management? That’s not an APM. That’s an underpaid/undertitled PM or higher. 100 people applied for this.

  • I wasn’t qualified for this one, so……

    

  I think we don’t have a ton of programs to do APM in healthcare and it’s reflected here.

• The Tony Montana. Make and commercialize your own product → If you make your own software/services product and can commercialize it well you are probably ready to be a product manager. However, if you’re the type of person who finds this appealing you also are probably not also looking for guidance on how to be a product manager.

As such, I’m not sure any of these options are better. But they are options. This is the end of advice for 0-to-1 PMs. Now for experienced PMs who want to get into healthcare.

The water’s nice! PMs who want to get into healthcare.

Welcome aboard. We need you. Like many people, you are probably motivated to get into healthcare because you have seen its inequities and inefficiencies, yet believe in its opportunities. Most of the advice on learning domain still applies to you. Here’s some other recommendations specific to your situation.

1. Get into the field, now.

The 0-to-PM gets to do this gradually but you have to jump right in. This is probably good advice regardless of your vertical but this should be especially true for healthcare. If you’re being brought in to be the “product leader”, then in many regards you have to become the #2 leader on most topics at the company fast. I think it’s a red flag if you can’t. Likely the implementation/customer success teams will have some variety of ground rules for you to ensure that you make the company/product look good in external conversations… yeah first principles thinking is great but your business really doesn’t want to give off the vibe that the person making your proverbial beer has never seen proverbial hops grow. You’ll want to prep for this as tightly in advance as possible, understanding workflows, common clinician and patient journeys in your product’s specialty and the points of friction that your product intends to solve for clinicians. This leads to the next point.

2. Listen to internal experts, learn, form own opinions

It is likely that your organization will have hired a variety of clinicians and specialists in your product and company’s field to facilitate design and delivery of the product. They are great resources and it is where you should begin your learning journey. These clinicians should remain a constant sounding board to your efforts. You will quickly learn that many clinicians are extremely opinionated and likely joined your startup because they feel dogmatically so about your product’s space. As such, you should ensure that you validate these opinions with users. You are not adding much value if you solely turn internal SME opinions into JIRA tasks; you need to be editing these opinions based on your sense of what is good. You will need to hone this sense quickly.

3. It’s not the years, it’s the mileage.

You should be prepared for traction to take time. Clinicians are often cautious about new technologies and will require significant evidence before they will implement new solutions. There may be some paths to accelerate this, but for the most part your victories will be hard earned. When I installed MyChart in the late ‘00s, the idea of a patient portal let alone one which patients could freely message their doctors was foreign. And MyChart had existed for a decade at that point. It took a combination of

• adoption curve (patients who use a portal one place then want it everywhere),

• incentives (doctors mostly were paid for seeing patients in person and not sending messages until 2020) and,

• timing (there’s a pandemic! maybe send us messages vs. showing up here).

If you want to come and go after a year in a healthcare gig, it’s unlikely that you’ll see anything to fruition. And maybe that’s ok based on your goals. But if you really want to see something take impact you’ll need to have patience or recognize that the success of your product will likely not occur during your tenure at a company.

Wrapping up

What do you think? Any tips or tricks? How’d you become a product manager in healthcare? Share any stories below.

1. This perhaps goes without saying, but if have an ultra-elite program MBA, graduated CS/eng top tech school, or are a doctor you probably get to skip a lot of these steps as folks will just trust you/thrust you into situations by merits of these things. Congratulations to you, I bet you that was a rough road and you’ve earned this ladder up the game board. However, I think the advice here on how to be “good” at the job is still relevant to you.

2. I think this is where it’s worth noting that someone could tell their boss they intend to outgrow their current position and grow into PM, VP, CEO, World Leader, etc. If you’ve got the combination of vim and earnestness, you might even endure yourself closer to your boss. This is in fact one of the key intrinsics of product management; someone could convince someone of an idea in a certain way…. it may just not be you. You have to gsd based on your own strengths and limitations.

3. I read a great blog post about this once that I can’t find again, so if you know what it is let me know so I can attribute it.

4. There’s definitely a group of “no extra work” people, and there’s definitely something to that if you are a very experienced PM interviewing for a senior position. However, as someone trying to jump the line, that’s probably not you.