How Tia aims to revolutionize Healthcare Products

I am co-founder and Tia’s chief product and operating officer — a unique title that foreshadows this post, and our differentiated perspective on successfully building product in healthcare. Prior to Tia I “cut my teeth” at Bridgewater and Owler, where I worked as a “traditional” product manager in very non-traditional company cultures. These experiences shaped my entree to Tia with deep regard for the impact structure and culture of a team can have on the end product.

As the incarnating blog post, I seek to describe what Product is at Tia. For, it’s something it’s not at most other places, or it’s not something it is at most other places. ;)

Below I describe in a narrative fashion, how we’ve arrived at the product-centric approach to development at Tia. Immediately below (if you’re not prone to prose) I also summarize the key differentiators/takeaways.

In one phrase, though, we are different because we aren’t limiting the traditional product development principles to one tool kit (code) but, instead, liberally applying them across our various users and their needs in ways that healthcare has never seen before.

The Summary

Our approach is different in the following ways:

We believe that a massive contributor to the issues plaguing healthcare is the technology systems that have been incalculably thrust upon the industry, and the way we’ve operationally and technically shifted from relationships and longitudinal health and wellness to transactional, moment in time visits and care. As our core insight, we strive to build a system that is explicitly oriented around supporting the many people participating in a patient’s care community, as well as acknowledging that health and wellness are ongoing activities through life, necessitating more than just a visit.

In order to effectuate our core thesis into a system, we have taken two differentiated steps in building our products: we’ve greatly expanded our notion of “user” and we’ve greatly expanded how we think about product.

• We have multiple users, we’re building for the patient, we’re also building for the provider. This means our gynecologists, Primary Care Physicians (PCPs), Licensed Clinical Social Workers (LCSWs) — but it also means the Medical Assistant, care coordinator, the front desk associate, and the ultrasound tech (traditionally forgotten)… we’re building for each individual on our team, and for the team collectively.
  
• We view product more expansively than our tech platform, product is our service line, it is our community support, it’s our content. With this perspective, we apply the traditional “user-centered thinking” to every problem/issue we encounter (there’s many, we’ve no shortage of “TODOS”), and design solutions under traditional product management strategies (cult of WWUD, or what would the user do?”). This is surprisingly differentiated in healthcare, a space that is still run by the “bottom line”. We take the belief that, if we do what’s best for our users, the needed behavior and the right bottom line will fall into place.
  
• Expanding our view of product beyond tech alone has necessitated our “architects” to deploy more than code to stand up our differentiated systems. Our product teams use technology, process, protocols, norms, principles, and culture to build our system. The toolkit is far more expansive, but enables us to not only deploy new service lines, and do the much more challenging (and in my book innovative) which is to deploy tech features that don’t just ladder up to and support clinical processes, but actually help promote/reinforce our clinical model.
  
• In order to do this, we elevate engineers, designers, and clinical operators alike into the role of “builders”, and employ them all under the umbrella of the “product organization”. Given our platform is not just tech, it necessitates builders of all different skills and licenses to bring our interdisciplinary vision to fruition.

The story version: Our early days set up our differentiated approach

When we first set out to build Tia, we were on a journey to “de-fragmentize” healthcare, and also to “democratize” access to reliable healthcare information so that women could make better decisions. We knew that this system must leverage technology — but in our early days — we hadn’t fully found what our product needed to be. In silicon valley terms, we hadn’t arrived at product-market fit.

For the first 9 months of Tia’s life, we were really focused on building a 1-to-1 personal health assistant. It was part human and part bot, and provided personalized and largely instantaneous answers to common women’s health questions such as “I forgot my birth control pill” or “my period is late, should I be concerned?”. Our sweet spot was urgent/anxiety-provoking questions requiring more personalization than a blog post. While this experience gave us an unparalleled front-row seat to over 200,000 different conversations with women about their health, we quickly learned that we needed to supply more than just digital answers on an iPhone to meet women’s needs. Women really wanted Tia to actually deliver their healthcare, not just advice on what and where to get it. We learned that our superpower was not only providing women information but a trusted relationship — one that made women feel seen heard and cared for in outsized ways. We had cracked one of the hardest things to do in healthcare — cultivate trust.

Why then, would we refer women into the healthcare system then for actual healthcare, which they more often than not, distrusted so much? Women wanted real “hardcore” care from Tia, a place to get pelvic exams, STI tests, ultrasounds, breast exams, Pap smears, and phlebotomy. Unlike many of the virtual care platforms that were taking off that the moment, we saw that to bring our women what they needed from Tia required physical sites for care. So, like any good product organization, we bent to our users’ demands.

It was at this turning point that we had to face ourselves in the mirror and say: if we are going to become a brick and mortar healthcare delivery organization, what role does technology play in our business? Are we even a tech company? Do we even need a product team? In brief, Carolyn and I would reiterate to ourselves the existential question: “Are we an app with a clinic? Or, a clinic with an app?”

I knew we didn’t want to be either. Both sounded small. Not to mention, either way of looking at our future completely missed what we surmised as the core issues in healthcare: information fragmentation, bad patient AND provider experience lacking orientation around cost, a paucity of creative design to make it easy and convenient to use, tawdry technology that belabored simple actions.

We couldn’t follow the path of least resistance

If I am being honest, it probably would’ve been easy to say that “a clinic with an app” alone would solve the problem (it at least would’ve definitely been easier to sell to investors). The problems in healthcare technology are rampant, and most everyone knows this. For example, I’ve never heard a single provider rave about their tech. The brunt of provider complaints arise from the stone-age era Electronic Medical Records (EMR) systems they’re required to use every day, systems that were designed more around the success of the medical biller than the clinician themself. These truths are best described in the poignant article, Death by 10,000 Clicks; an article that every modern-day clinician and “health tech” industry worker has imprinted into their memory.

That these technology systems inadvertently and advertently shape modern medicine is a critical vector of our problems. EMRs are no longer just data receptacles, they are actually dictating standard of care — driving, not documenting, clinical actions. And, because of the ways that the systems prevent providers from “progressing” a patient through care if they don’t tap the right button, providers focus more on clicking than actually consulting. Who could blame them, for a standard primary care checkup there can be over 400 required actions if the EMR is CMS Medicaid compliant. This impacts our patients too — provider eye contact is drawn away from the patient in the visit, focused on the buttons not explaining the recommendations. But, worst of all, these buttons distract the provider from the very reason they got into medicine and spent years obtaining a medical degree. In lieu of medical decision making, providers, via these EMRs, are shoved into a draconian technology system that takes as slim a perspective on the merits and possible vertices of human existence and disease as a 1999 version of The Sims. (like versions pre-dating rosebud!;!;!;!;)

Just as limited as you might feel like a real human in a Sim life, providers are limited in the seemingly two-dimensional matrix of common EMRs. These collections of 1’s and 0’s have uprooted the art of medicine, the practice of wellness, and healing. The art supplanted not by science, but by code. Code that has been lobbed haphazardly on top of more antiquated code, to form a “system”. With each subsequent CMS guideline, another piece falls into a previously unrecognized crack. This mass of bad tech is a very large nodule on the rhizome of the issues in healthcare (I had to go with rhizome, as the panoply of issues in the healthcare system is certainly so large as to require its own glucose supply).

So, it was clear that these issues we set out to solve: worsening outcomes, dissatisfied patients, demoralized providers, skyrocketing costs, layers and layers of institution/fragmentation could not be unearthed with a mere digital re-skinning of current tech. The Frankenstein needs to be put to rest and replaced with a new system more purposefully sewn together. This is why we couldn’t take the easy route — and couldn’t make a ‘clinic with an app’.

Everything that I’ve said over the last 4 paragraphs is trite for someone in healthcare. The real difference is how Tia addresses this. A mini digression before I get to this (now you’re understanding why I wrote a summary!)

Our society didn’t just have a break up with medicine, it lost all relationships in medicine

Long ago, art, science, medicine, pharmacology, botany, horticulture, spirituality and community were all linked, often tied to the same place, individual, or ritualistic practice. And, in more recent past (a mere decade ago), patients retained their doctor for life — allowing their care providers to amass a world of data about them, that while perhaps not all captured in a clinical note, was fertilizing the ground from which the physician drew clinical insights and took clinical decisions. While I am not insinuating we ought to return to bloodletting practices of the past, I do think that we’ve lost greatly in siloing medicine away from the acts of healing, wellness, and community. But required for those is an element that our society, and medicine, in particular, has waysided: time, continuity, cultivation, iteration, and evolution. The site of the modern medical marvel, the ER, is anything but a site for healing continuity. Instead, it’s a site of “transaction”, “one and done” and “take a pill to make it all go away”.

What is elemental to “practice medicine”? Etymologically, practice is derived from the greek and means something that is constantly worked on. Medicine, the observation of what is natural. Both rely on this idea of ‘overtime’ — practice and observe over time. We need a system that will more deeply support care for a patient through time.

We want to shift our perspective back towards the ‘practice of medicine’ as longitudinal, as through time. How might we do this in a day where patients now expect to similarly command clinical care as they do Ubers? Where we’re promised “cures” to incurable diseases with symptom masking pills? Where providers are cornered into singular methods of treating patients, regardless of the patient's contextual complexities? And, where quite frankly, our clinicians are so burnt out they are constantly looking for ways to minimize patient-facing care hours?

From our estimation the longitudinal shift comes down to two core elements that must be pursued: a focus on the spectrum between illness and health and cultivation of relationships as the core system in medicine. The former is at root Tia’s clinical model, our unique approach to delivering care. It is a topic for another, a stand-alone post. But the latter characterizes our perspective on the system that we need to build to enable success in medicine once again. Designing and building this system is my focus at Tia, I’ll aim to explain deeply yet tactically what we mean in the remainder of this post.

In healthcare, we often talk of the patient <> provider relationship — but, in fact that relationship barely exists today. We insinuated institutions between the patient and the provider (think: “I tried to call my doctor but I was on hold with a call center for nearly an hour”, or “I wouldn’t even know where to go to get my medical records”, or “I got a bill from someplace that I didn’t even know I went to for care”). And, of the other relationships critical to making care delivery “work”, we typically gloss them over: the relationship between the patient <> care coordinator, the provider <> care coordinator, the provider <> medical assistant, the provider <> radiologist … etc.

The premise of a relationship, and how it separates from a transaction, is its specific design to have more interactions between the parties in the future. The intention of the design is to create trust between the parties, and per Levi Strauss, even a sense of indebtedness/anticipated return of something. In order to cultivate this, we need a sense of transparency, truthfulness, reliability — a sense of memory of the interaction, and most of all, a sense of reliability.

The transactional visits of today mystify these foundational elements of relationships (that EMRs have relabeled “encounters”, so as to truly absolve us of any misconception that there should be a string of interactions between that very patient and that very provider/health system ever again). The button clicking creates the effect of “pushing patients through” a string of digital checkpoints. The operating systems make healthcare point in time, one-off, and absolve it of the human-to-human relationship. It’s our thesis that in order to redesign a successful system, we must re-insert the effect of time on health. There’s that age-old adage “it takes a village” … to raise a child. It also takes a village to ensure health and wellness continuity across that child’s lifetime, through adulthood. We seemed to have lost that part of the phrase. Our healthcare is a lifetime journey, and it’s one that must be explored in concert with a band of supporters, namely a care team.

Our deepest insight is then: in order to transform healthcare we need to reorient our systems of delivery not around a single visit in a vacuum, but the healthcare journey of a patient. That journey must be supported through transparent, ongoing, collaborative relationships between patients and providers, providers and providers, and patients and patients, or the care community.

To put relationships back in medicine, we had to put the people back in medicine; to put the people back in medicine, we had to understand our people

How to do this — my first inclination came on strong, as it would for anyone steeped in Paul Graham's product thinking: user-centric design. But, as differentiated from our compatriots in healthcare, we certainly were not going to start with the medical biller (we don’t even employ a medical biller). But, we wouldn’t end with the patient and the provider either. Each member of the care community needs to be treated as a “user”, and so did the collective community. When designing and building our system, therefore, we dually consider each role in our organization (PCPs to front desk staff) and the interactions between each role type as a “user” itself. How might a patient use this feature? How would the way they use it to impact the provider on the other side? What might the provider need to do with the information? When would they need to involve a Medical Assistant or another provider?

And, we needed to refashion the success of care away from a focus on encounters, visit duration, and button clicks towards a longitudinal care journey rooted in a relationship with the patient. Meaning, based on patient need, we should prepare the patient for multiple appointments, and how the insights about their condition would unravel across those steps; we required a choreographed understanding across the team of the various touchpoints each role would have with the patient.

But, in order to do this successfully, we could not just depend on our technology system alone. It was clear that if we fell into the same trap as those around us, of thinking tech, could devise a solution that characterized the clinical operations or medical decision making, we’d end up down the same road as so many others, death by clicks.

Clinical operations, service line design, clinical research, patient experience, provider documentation, patient registration … even down to that “breath in, breath out” moment at blood draw needed to be redesigned with this altered perspective in mind. We had a long list, to name a few:

• We need a service line redesign to change the concept of a “once a year preventive healthcare check-up” to “a daily engagement with my health and wellness”. How can we help our patients translate “eat more fiber” from their digital care plan into a living and breathing action they take every day?
• We needed altered clinical operations, guidelines, and procedures to support such a longitudinal view — how might a provider dig into different questions during different visits? How might we recommend different modalities of wellness (acupuncture, nutrition, mental support) given certain conditions?
• We needed patient education initiatives to engage and explain our different ways of doing things. This education needs to extend beyond informational, to curational. It needs to break the long endured stigmas in women’s care, and building community in the experience of our bodies, of our health, of our lives — rehumanize healthcare through and through.
• We needed differentiated staff and personnel who would thrive in the high volume of communication that we are doing between our team and out to patients. We needed training modules on how to speak the language of patients, not the foreboding language of healthcare.
• We even needed alternate clinical space design to support the cross-team collaboration and make “the doctor’s office” a place women wanted to go to — not just when something was wrong but to proactively invest in their health.
• We needed to establish an organizational culture that supported our core norms, principles, and philosophies around the critical elements of success in patient-care (longitudinal thinking/the health journey and relationships). This necessitated more than just technologists working on this “product”. This essentially requires our entire organization, from software developers to clinical operators, to NPs and MDs, to designers, to the brand team. Decisions couldn’t be siloed but must be made and executed horizontally across all these functional areas.

To bring these various minds together, the right org structure became tantamount. As anyone familiar with matrixed decision making, the underbelly of the interdisciplinary team is decision paralysis. In an effort to avoid this, we took the role of the product manager, or the ambassador of the user, and said: you have many tools in your tool kit, use them all to impress your user. PMs at Tia use tech, service line design, patient education, clinical modeling, process/procedures, cultural development and training, and much more to deliver on their goal.

And, we had to revolutionize the way we organize our people to ensure the best possible collaborative outcomes.

The role of the PM is much expanded from the traditional that typically works across engineering, design, and marketing. And, as is much in vogue at the moment in technical organizations, we’re pulling the “technical design” conversations earlier into the development process. But, we’ve expanded our definition of technical design to include clinical ops, clinical research, and care. After all, we’re in a world where much of our product is actually the care, and the ops are the delivery vessel (akin to businesses where content is the product, and the platform is the delivery vessel aka Instagram). Engineers and operators are our builders, they just have different building blocks. We treat the design and implementation process across the two much the same — and most importantly, the test/iterate cycle much the same. Our operational feature performance is measured and ‘bug fixed’ in much the same way our technical features are.

One of the most important elements of how we’ve thought about this design is that we cut a PM’s responsibility not by tools in the tool kit but by the user, we don’t have operator PMs and tech PMs, just PMs. Our PMs are focused on the patients or the providers or the administrative staff. This means, in order to develop end value for the user, they may / must have to traverse all tools in the tool kit. Take a recent feature we released, an online check-in for patients which allows them to validate their insurance coverage, the card on file for copays, and complete their intakes ahead of their visit. While a substantial portion of this feature was a technical build (and quite a complex one at that), this implicated both our administrative and clinician teams. This information is critical to the workflows of both. So, before even setting out to design or build tech, we said to them, “what are the ways in which you use this information? What are your biggest pain points around it? What do you wish you could do?”. These answers factored directly into the systems that we designed — both technical and operational.

A different, more clinical example is how we redesigned the use of the patient care plan to support our longitudinal care structure. Providers traditionally document the treatments and next steps for patients in the care plan section of the EMR. Similar to others, we use this opportunity to prompt providers to think about our particular care model (eg if a patient is in for a UTI, consider immune support, not just antibiotics). Yet, we also heard from patients and care coordinators alike that a document to remind the patient post appointment of the plan would be useful, and even more useful would be to have recommendations for how they might secure items in the care plan, or have the opportunity to discuss in more detail the recommendations. While we’re still building out this feature (it’s currently in the MVP phase), this was a perfect example of insights from a trifecta of users coming together to influence both technical features (digitally displaying the care plan to a patient and provider in their respective portals) as well as operations (training our care coordination team on how to chat with patients about this document). Only when paired together does the vision become successful.

By explicitly defining the systemic principles that we believe need be upheld to deliver on clinical success, and explicitly choosing to design for how our core “users” (all of them!) must interrelate to engender success within it we believe we can avoid the Frankenstein systems all their negative tertiary consequences that balloon into the “problems of our healthcare system today” (worsening outcomes, dissatisfied patients, demoralized providers, skyrocketing costs, layers and layers of institution/fragmentation).

For details on how what, when we bring these philosophical practices into our making process, take a deeper dive into the content of this blog. I hope you’ll enjoy!