Resolving the clinico-product divide

Unlocking the promise of clinicians within product development

If your organization does anything remotely related to the delivery of clinical services: Direct care, supporting software, some combination thereof, and wishes to continually improve those products/services you are going to eventually have to tangle with how to structure all of the expensive clinical and development people (product, engineering, design, service design, etc.) to produce something valuable. What you are probably getting instead is either lots of complaining, slow output or both. This fundamental problem of a clinico-product divide usually shows up as a series of distinct, but related questions such as:

• How do I get my clinical and product people to trust each other?

• How do we get our clinical people to be more collaborative/risk tolerant?

• What is product/how do we become more product-led?

• How should I structure my executive team vis-à-vis product, technology, operations and clinical?

Honestly, having struggled with this across a few organizations this has become one of my favorite questions, because when you figure out how to combine these disciplines together for your patients (or your customers’ patients), the upside is world-changingly positive. Sadly, hasty, incomplete implementation results in pervasive underperformance, hence why this question gets asked so often. The short answer is to put clinicians ON the team as a team member and for the very special clinician, train them to product-own the team. Easy, right?

So why doesn’t this happen everywhere? Money. All clinicians are expensive and the great ones that can do this work out of the box are extremely rare. Having them not care for patients feels wasteful.

So what do we do instead? The usual pattern is to organically identify clinicians that have a knack for developing whatever you are developing (protocols, workflows, services, software, etc.) hereinafter known as “the thing.” They often self-identify through a combination of idea sharing and useful feedback (or complaints). Development teams in turn begin to trust (or abhor) these individuals but nevertheless include them in some type of pre-release conversations: looking at prototypes, beta testing features, because these clinician champions are helpful and/or their criticism reinforces skeptical executives who dislike non-deterministic development processes and already suspect that you are incompetent.

This works for a while, because the clinicians are playing the role of user in that they are giving firsthand feedback as they attempt to use “the thing” in the context of their work. Over time, there is a natural inclination to bring this clinician in as a subject matter expert (SME), who instead of using the thing themselves, begins to postulate how other users might use “the thing.” This substituted judgement can be a real accelerant before you have actual users, but after about six months of “the thing” being used, your SME begins to go native. They have responsibility for some of what has been built under their watch, so their ego causes them to defend what they have built rather than listen to users. They run the risk of discounting user feedback, obstructing progress through biasing your development process. This process accelerates if the SME stops doing their day job and is even worse if they never had a user-like day job to begin with (e.g. never saw patients).

So wait, didn’t I just suggest that we put them on the team, but here I am saying that SMEs joining the team causes them to become obstructive? Exactly! Everyone who has ever built anything has experienced the devastation of negative feedback on one’s ego or worse, the ignoring of that feedback to protect one’s ego at the expense of the product to be built. Basically all of agile was designed to defend against this ego inertia i.e. teams do not spend very long on any one part of “the thing” without getting feedback so that they do not get overly attached to what they have built. Iterations come so frequently that “the thing” really belongs to the users and not the builders. Through the empathy-killing role of “expert,” your SME evades these defenses against the IKEA effect as they exist in a nether space between user and team member. That’s why you put clinicians on the team proper (and train them), so they are compelled through disciplined product ways of working to make use of their experience as context for understanding user needs, pain points and problems to chase excellence, rather than substituting judgement for those users resulting in mediocrity.

If your organization is at a stage where clinician availability is low and/or money is tight (two universal truths), then you will likely follow the default path above. If you are unwilling to pay for clinicians to be full time team members or you cannot find any that want to give up direct care completely, then you have a few options. First, clearly define the role you’d like each clinician to play, in each interaction. For example, “today we’d like you to look at these designs as a user–how would this help/hinder your daily work.” Or, “today we’d like your subject matter expertise, can you please explain hypertension to us as we build out a ‘thing’ to help with it.” Listen closely for clinicians straying across roles from user to expert to designer, and gently keep them on track. Second, do not have clinicians give feedback on their own designs, but do have them in the room (ideally silently and invisibly) for others giving feedback on their work. A little empathy in the form of ego protection will go a long way toward peace and progress. Lastly, if you cannot fully dedicate your clinicians to development work as team members, rotate them out after 6 months. This way you keep your feedback and biases fresh, while allowing them to re-immerse themselves in clinical work so that 6 months later they can give a fresh perspective.

When these temporizing measures fail, it is time to suck up the cost and put a few clinicians as full time team members, paid on par with their clinical salaries (because markets). You should do this sooner than you think you can afford to because the gap between clinical and product knowledge is asymmetrically vast, especially when software is involved, due to the breadth of technical knowledge. Words mean different things, there are clashing tolerances for risk and the jargon is thick all around. It takes time and intentionality to cross this clinico-product divide, and given that clinical mistakes cost lives in a very personal way, clinicians are usually able to learn product development more quickly than product people can learn to become clinicians. You may think you are saving money by having part time clinician developers, when really you are just wasting time. So step 1 – Put clinicians directly on development teams to get them across the divide. Steps 2→n, next time!