The value of Product in enterprise healthcare

Alex Zhang
7 min readJul 23, 2020

--

Product is never built in a vacuum — context will always play a crucial role in shaping how you drive outcomes. Having previously developed enterprise products in other industries, I anticipated the main learning curve upon joining Cedar, an enterprise health tech company, to be ramping up on healthcare.

What I did not appreciate until much later was that the intersection of healthcare and enterprise sales would create a new environment that fundamentally impacted how I thought about the value of Product as a function and the profile of PM that could succeed.

But let’s start at the beginning and first explore how healthcare influences enterprise organizations.

Is healthcare different?

Yes.

If only it were this simple…

Glib answers aside, check out the podcast by a16z called “So you want to build a software company in healthcare?” for an excellent primer on this subject. As a summary, here are some of the key points we personally experienced at Cedar:

Very few things scale — Limited data interoperability is a real challenge in healthcare and like many health tech companies, we had to invest in a services team dedicated to standing up distinct data integrations (sometimes multiple) per client.

Just as problematic was the realization that provider insights fail to scale as well. Understanding how new use cases could be addressed in a standardized way was complicated by the fact that every provider developed their own unique processes when faced with identical problems.

  • Find Subject Matter Experts (SMEs). Especially in enterprise sales, client data points are slow to arrive. As a result, it’s important to augment them through other channels (e.g., expert calls, consultants, prospects, etc…), not necessarily to stumble on the best practice, but rather to get a better understanding of the spectrum of possibility.
  • Attempt to create scale. The ideal outcome when confronted with a unique process is to converge it towards a standardized best practice. For the providers who were willing to adapt, a combination of data insights and heavy services support were necessary to operationalize the change. However, many others were either unwilling or unable to unify their willingness with execution. In those cases, the ideal is to avoid customization by identifying opportunities to make the platform configurable (i.e. provider specific variables vs. hardcoded exceptions).

It’s operationally heavy — Releasing new products or features in healthcare is rarely as simple as merging a branch to master and scheduling a release. I ended up defining three tiers of roll outs:

A true enterprise SaaS company would primarily have tier 1 features with tier 2 happening occasionally (e.g., changes to the API, contractual changes, etc…). For us, the bulk of our most valuable features were tier 2 and 3.

As a result, I had to start exploring the role of Product Operations much earlier than expected given the size of the company and the maturity of our product. I defined Product Operations as being accountable for the full roll out of tier 2 and 3 features while PMs were accountable for the performance of those features once rolled out.

Product Operations ultimately played the vital function of continuing to create scale. Inherent in the responsibility of deploying features broadly is the reduction of future customization requests once the feature is developed. At Cedar, the strategy involved close collaboration with the client facing services teams and flagging potential configuration opportunities that weren’t identified during the initial scoping.

The main viable model is tech enabled services — Great technology, on its own, fails in healthcare. Given the lack of data and process standardization, an effective services competency is required to create the necessary environments for the technology to succeed.

As a business, there are some profound implications: margins will be smaller given the higher operational costs, org structures will be strained by the large number of functions needed to take the solution to market, and capital needs will be greater to weather out the longer revenue growth timelines.

As a Product leader, the most important revelation was the fact that Product itself is a key part of the services offering: supporting other parts of the delivery chain (notably Sales and Services) ultimately yields a more, but never completely, standardized product that has a greater chance of scaling and achieving its intended outcomes.

What is the value of Product in enterprise healthcare?

While healthcare companies are inevitably tech enabled services, enterprise healthcare companies selling 8 figure contracts are also inevitably sales led. As a result, the value of the Product function is to create clear perspectives (a combination of the vision, roadmaps, product documentation, etc…) that can be used to drive future sales and streamline existing client deployments.

Put differently, the primary output of Product in enterprise healthcare is not the technology itself but rather a clear picture of what the future should be and how to get there.

There’s a lot to unpack so let’s break it up into distinct learnings:

Sales led vs. Product Led — I’ve found that there are many different interpretation for these two terms. I personally prescribe to the definition outlined in this blog post where distribution channel dictates the function that leads. In a world of 6–8 figure annual contracts and RFPs, Sales leads the way.

  • So does that mean Sales should always define the roadmap? No. They have insight into a very important input (the market) but Product has visibility to more (the effort, the analytics, the debt, the longer term strategy, the existing client needs, and their own perspective of the market).
  • Then does that mean Product should say no to all custom requests? No. Turning down an 8 figure deal to avoid a contained custom request is objectively a bad tradeoff. The challenge is that Product still needs to play the vital function of understanding the root problem, since the asks will quite frequently be misguided.

Balancing that pushback is not easy, especially when Sales input does have an outsized impact on the roadmap. The reality is that these periods are a sign of a healthy sales pipeline and an opportunity for Product to invest in identifying more forward looking perspectives.

Perspectives as the primary output— Product’s unique advantage is the perspective granted by being at the intersection of the market, the strategy, the reality (i.e. engineering) and the completely new insights generated by a live product. In an environment where distribution can only happen via Sales and delivery is contingent on Services facilitating change, proactively publishing perspectives is the highest value lever that Product can influence.

  • What is the value of perspectives? For Sales, perspectives should help drive new deals by painting a differentiated future that excites the C-suite but offers enough specifics so that expectations can be set as the conversations become more tactical. For Services, those same perspectives should drive down operational costs by arming the team with best practices they can implement with bought-in client counterparts.
  • How does this focus impact the Product function? Defining perspectives that are both forward looking and detailed enough to promote best practices takes a significant amount of time. While sacrilegious in enterprise SaaS, consulting provides a good model reference model: the primary outputs are similar, flex capacity is needed given how much market demand can fluctuate, and close partnership with those who own client relationships is necessary to share many of these perspectives directly. While the person owning product strategy should lead the way on these efforts, additional capacity will be needed by freeing up individual PM capacity or defining a role dedicated to being in-market.

The challenge is that Product is also accountable for guiding the development of the product itself. How to balance the tradeoff between establishing perspectives and guiding development will greatly depend on context. For example, hiring product minded engineers will allow them to take on more product development responsibilities. However, no good tradeoff can occur without first acknowledging where Product adds the most value and as a result, where their efforts should be prioritized.

What PM profile works well in this environment?

When I left, the Product function was 4 PMs plus 1 Product Ops. It’s possible that sourcing will need to be even more targeted if the more consultative and market focused aspects are separated from the product development responsibilities. However at this stage or earlier, these are three qualities I would consider when looking for candidates:

  • Strong product instincts. While obvious, it bears repeating that you’re still hiring for PMs. Fundamental product skills like prioritization and the ability to understand the root problem are not only important given the tricky product development environment, but are universally helpful in other domains like time management (balancing development and market research) and identifying scalable processes.
  • More senior in overall experience. To be clear, I am not necessarily saying you need to hire more senior PMs. While product seniority tends to imply stronger product instincts, I found that overall professional experience is more important, especially if some of that experience is in consulting or a field that requires talking to senior external stakeholders.
  • Prior enterprise experience > Prior healthcare experience. While the ideal candidate is someone with both, the main problem is that healthcare is massive and expertise in one aspect does not necessarily translate to another part of the ecosystem. Given healthcare’s tendency to exasperate the enterprise-y aspects of enterprise, I learned that prior experience building products in large enterprise environments won out.

One simple way to characterize the many learnings from my time at Cedar would be to say that they were all obvious in hindsight but easily forgotten in the moment. These learnings were no different: enterprise healthcare business are still enterprise businesses. Healthcare provides unique context and skews heavy on operations but in the end, enterprise playbooks still apply.

For those playing a Product role in this environment, I wish you the very best of luck. The journey is tricky to navigate, but the potential scale of your impact in healthcare, an industry that combines massive scale with a depth of humanity, is quite an attractive reward.

--

--