Julie Yoo is the co-founder of Kyruus, a medical technology company that is the developer of ProviderMatch. One of the most frustrating things about the healthcare system is the tendency for patients to be sent to the wrong type of doctor for their health issue. The industry term for this problem is patient access paradox.
ProviderMatch is software that directs patients to the proper medical specialist for their specific needs.
During today’s episode, Julie and I discuss the components that make ProviderMatch an effective tool. Some of the topics we touch on are:
- How ProviderMatch has changed the customer service side of healthcare.
- How ProviderMatch helps combat physician burnout.
- The 3 major user bases served by the application.
- The 3 types of tests Kyruus uses to test new and upgraded product features.
- The 3 levels of analytics that Kyruus uses to measure RIO and value.
Resources and Links:
- Kyruus on Facebook
- Kyruus on LinkedIn
- Kyruus on Twitter
- Julie Yoo on Twitter
- Julie Yoo on LinkedIn
Thank you for joining us for today’s episode of Experiencing Data. Keep coming back for more episodes with great conversations about the world through the lens of analytics and design.
Brian: All right so we have Julie Yoo on the podcast today from Kyruus which is based out of Boston. Julie, welcome to the podcast. How's it going?
Julie: Good, thanks Brian. Thank you so much for having me.
Brian: I'm excited for you to share some of your backgrounds with our listeners. You're currently chief product officer at Kyruus. We did some work together several years back as I recall. This is actually news to me, I don't know this—you're in the healthcare space and you oversee product and strategy for the company and hospitals. When we all call and we want to schedule an appointment with a doctor, a lot of us get a referral from a friend or whatever and we call them and it's difficult to get an appointment.
Reality, the hospitals often have tons of supply on their end that's not getting used and those doctors or service providers may be fully qualified to help out those patients if only the people on the scheduling side could help match the patients up with the service provider. Is that basically what your main software, the ProviderMatch software, does?
Julie: Yeah absolutely. We're solving what we've coined as the patient access paradox which is that fundamental mismatch between patient demands being told to wait multiple weeks or even months to get an appointment. We all assume that that’s because every slot is booked up solid in whatever market we're in. But it turns out that on the hospital side of things and the whole system side of things, that typically our customers are operating at anywhere from as low as 70% to 80% capacity utilization.
One thing I'll qualify there, it's not necessarily just empty slots that are going out completely unused which is certainly an issue. But what we also focus on in best utilizing your resources for the unique expertise and skills that they bring to the table. What we also focus on is are you getting to the right doctor the first time, and that's from a clinical lens. There's tons of subspecialties in medicine and we want to make sure you're getting to the right specialist. Or subspecialist or even within primary care there can be variants in terms of what people focus on.
Also level of care which is if you have certain types of conditions, oftentimes part of the reason why you have to wait so long is that you're sent immediately to a very scarce specialist resource who tends to be harder to book with, has more limited time. Whereas that condition may actually be treatable by a lower acuity provider. Anything from a generalist to primary care provider, maybe even a nurse practitioner, or even a walk-in clinic. This day and age, we see a lot more activity in terms of retail clinics and walk-in care. We look across that entire spectrum of possible options to interpretation and ensure that the patient is getting routed to the most effective place in the most efficient and possible way.
Brian: That's pretty cool. I didn't realize there is so much missed—I mean obviously the specialists wants to see them. I have any arm problem, I need to go to the best arm doctor in the world kind of thing. We didn’t know that there was so tax, like 70% to 80% under utilization rate is pretty interesting.
So why don’t you tell me about your background. I know you studied pre medicine at MIT and you have an MBA from Harvard, is that correct? And you went to MIT Sloan. You have quite a background. What do you do at Kyruus yourself, and can you tell us about your background a little bit?
Julie: Yeah, absolutely. It's blasphemy that you just said that I went to Harvard MBA. I went to MIT for my MBA. Actually, I came to MIT as an undergrad thinking that I wanted to be a doctor when I grew up. I started out as a biology major doing pre med. I'm happy to be in school during the initial original dot-com boom back in the late '90s and actually got influenced to get computer science and fell in love with it. Just the problem solving aspects of it, and I love coding and building things from nothing.
I ended up actually majoring in computer science while also finishing up my premed exam requirement. My first job out of college was actually as a software engineer so I totally focused on the technical side of that track. Always, however, maintaining my personal interests in the intersection of healthcare and technology. The first several years of my career was software engineering. I worked at a company called Endeca Technologies here in Boston which I think is pretty well-known locally.
They were an enterprise search technology initially focused and I think probably best known for their work in the ecommerce space. We powered the online search catalog for the major ecommerce companies across the country and even the world. I cut my fuse there and then ultimately figured out that I love being customer facing, I was kind of intrigued by the business side of things. I migrated more into product and eventually now today, I'm more of a product manager is kind of where I would identify myself.
Also at the same time about six years since my career at Endeca, that was really when the federal government started pouring resources into the digitization of healthcare and that was really when I had a lightbulb moment myself around the opportunity within healthcare to apply software and technology and data to improve efficiencies as we were talking about earlier but also [...] simple outcomes, of course.
And so I actually made a career change by way of grad school which is how I ended up at MIT Sloan. The Harvard component is that I did a dual degree program that was a collaboration between Harvard and MIT. By way of that, I got exposure to both the business side as well as the clinical side. The Harvard-MIT HST program is the collaboration between Harvard Medical School and MIT Proper. I did my masters with that program.
I initially actually focused on personalized medicine, something that’s completely unrelated to what we do here at Kyruus but it was intuitively an area where I can apply my data analytics and software expertise given that [...] where software was being applied at scale in the healthcare and life sciences area. The first couple of companies that I did were in that area of genomics and genetic sequencing and personalized medicine.
I had a couple of companies that I worked with there, especially the first employee of both companies on the product side, and both of those companies eventually got acquired. The second company was acquired in 2010, that was when myself and my current cofounder Graham Gardner decided to get together and go after the opportunity that Kyruus has focused on around patient access. I was the founding chief product officer at Kyruus.
I wrote the first version of the product with my own two hands and have shaped the road map, user engagement, definitely own design as part of the product management function and have now as the company has scaled moved into more of a strategy role. Really focused on three to five years direction of the business, new market segment, how do we fit into the broader technology ecosystem within the digital health space but really have my anchoring and foundation in product.
Brian: Cool. Thanks for sharing that background. You mentioned in there that you own the design as part of your role in product at Kyruus. If I recall correctly with ProviderMatch, the primary end users tend to be people that are scheduling appointments which may include some people with medical background like the nurse managers I believe and you're trying to provide them with the tool that lets them take in patient requests or things like language of the provider, gender of the provider, location of the provider and obviously dates of availability.
Then they are able to type in a condition like skin rash or something and then the scheduler is able to provide them with a response like, "We have these four people available on Tuesday from 11:00 to 3:00, they're all great, here's where they went to school." Is that still what it is and can you tell me about how do you go about designing that experience and how do you guys know if you're doing a good job besides the fact that the checks clear and they keep renewing. How do you guys evaluate and design for that?
Julie: Yeah. You do remember correctly that one of our major user bases is the patient after call center agent who is a front line staff member whose job is to answer the phone all day every day and help patients get matched to the right doctor and then book an appointment. That was our flagship product called ProviderMatch for access centers that we launched over five years ago at this point. That remains a major user constituent that we serve.
Since then, we've expanded our product portfolio just to make it a little bit more complicated. We actually now I would say have three major users that we serve in addition to that. One being the call center agent that you described, another actually being the patient or the consumer, him or herself. We actually have launched a patient facing product called ProviderMatch for Consumers several years ago at this point, but the idea there is to enable us consumers to self-serve.
We have a white label product that our customers will embed in their websites or their mobile apps. They're kind of public facing digital storefront, so to speak. That allows for us to do our own research on who might be the best provider for me based on my preferences and my criteria. And then also facilitate on my scheduling, being able to actually book an appointment physically online. That’s the second user-base that we serve.
Then a third major user-base is actually the physicians and the providers themselves and this has become a very powerful leverage point for us to be able to engage these organizations at scale and really provide a strong value proposition back to the physicians who I would say, traditionally in the digital health world, are sometimes viewed as optical. A lot of companies struggle to really engage with those providers and expect the value proposition that’s big enough to get those individuals to buy in, let alone to actually use product.
You may recall originally my philosophy around ProviderMatch was we need to design a product that can be deployed and go live and drive value without any reliance on physicians doing anything in our product. The primary reason for that is that physicians are extremely busy. I think the strategy to depend on the physician to come out of whatever their core workflow is, take away from the time that they're spending with a patient to learn a new thing and/or using a different app than what is core to their clinical mission through observing the patient.
We actually started with that philosophy, but as we matured and as we were demonstrating great outcomes, we were able to kind of pivot into a much more explicit physician engagement approach. Today, they are actually the majority of our users, technically speaking, in terms of the number of users who are accessing our products, that’s another dimension to it. As you can imagine, each of those user bases is extremely different. We could go on and on and I'm happy to go in whatever direction would make sense but we have a pretty distinct framework that we use for each one of those user-bases. Yes, we serve them all through the same uniform platform and there are certain elements of consistencies that we want to drive across user experience across those three user-bases.
But as you can imagine, the use cases, the stories, the scenarios that we're addressing within each of those products can be quite [...].
Brian: Can you tell us a little bit about how you design for these different constituencies, if you have like a recent anecdote about maybe a project you guys did and how do you keep all this simple and keep the scheduling time as minimal as possible which I assume would be the goal here, so that the maximum time is spent on patient care? How do you design for those experiences? How do you move through that?
Julie: I think just the basic thing we start is just a crisp definition of the actual user personas and certainly each of those user sets is using our product for a very different purpose. Take the call center agent for instance, when they answer the phone, the person on the other end of the phone clearly already has some intention of taking some action because they've gone through the work of dialing the member, waiting for someone to answer, and clearly are looking to get served.
A lot of message that around that user base is efficiency. You’ve got only a few seconds to capture the attention of that customer and essentially convert them. One of the ways that we define the job of the call center agent that might be distinct from the other users is their primary goal is conversion. They need to drive yields from every 10 calls that come in with a patient looking to get an appointment. We want the number of booked appointments that come out of that to actually be 10. Some of the sort of sad state of affairs in the healthcare industry is that many of the organizations that we engage with are starting at conversion rates as low as 20% meaning every 10 patient that call in, trying to get an appointment, maybe only 2 of them will leave that call with an actual booked appointment in hand.
There's a ton of sort of depth around how do we drive that use case for that user base, which is distinct from the consumer. The consumer, I may just be doing research and I might be early in my funnel, in my patient journey and not yet ready to book an appointment when I'm engaging with ProviderMatch. It might not even be me, I might be doing some research on behalf of someone else or certainly I might be coming with an intention to book. I would say a big challenge that we're still chipping away at and have tons to learn is how do you effectively segment those user stories and scenarios and serve all those user sets and narrative through a single product. That is a different set of problems.
Whereas physicians, on the other hand, the primary goal for them to come into our solution is to optimize the configuration of rules engines that determine which patients get referred or scheduled with them. That's much more of a personal experience in a lot of ways because the physician is looking to us, our products, to help describe to the world what it is that they do and under what circumstances should a patient be sent to me. That sort of elicits a whole different emotional experience in some ways that relies heavily on an empathy for the perspective of that physician and really a kind of, I would say, caution around making too many assumptions about what that individual is looking to accomplish or how they want to express their clinical expertise through our product. There's a whole, again, another set of narratives around that piece
Just that mere definition, hopefully it paints the picture of just the complexity that results from having to serve such user set. We do have different team that focus on different user experiences as well and that ability to have individuals specialize in certain areas just gives us a lot of depth around how we're able focus and describe a lot of insight into those varied populations versus kind of diluting it by having teams spread across those areas. Those are some of the types of framework that we use to be able to effectively address those user populations.
Brian: Do you have either your designers and/or the product managers, it sounds like you have them assigned to each of the different products that focus on the different personas, do they do any type of interviews or any type of research activities with these, I'm curious, you can like learn anything, have any cool nuggets of stuff that maybe you would have found out through the design process about talking to a doctor, like, "I would never type in that I'm an expert at this even though I totally am because X," or…
Brian: …did you find any nuggets that are kind of interesting?
Julie: Yeah, absolutely we do, I would say, three major types of testing. One is we actually are privileged to have lots of folks who are either physicians or ex-hospital administrators at our company, so we have in house team that can serve as sort of test users for a lot of our new concepts, where we do kind of an internal testing when we're developing new ideas or get designs. That’s one way we do it. We also obviously use external testers as well, whether it be sites like usertesting.com or other service that allow you to recruit ad hoc users and test various concepts. We've got a lot of that kind of work as well.
We also go observe our users at our customer site and we've done a combination of both observation of actual call center agent-type users within their dedicated setting, but also direct consumer research, we'll giveaway Starbucks cards to regular people off the street who are willing to kind of sit down and give us feedback. All of that is a source of data into our process. So many stories of things were just completely eye opening.
Everything from, I mentioned earlier, the emotion that gets elicited when you are working with a physician to try to define what their referral protocols are. Imagine sitting down with an engineer and designing a routing protocol for determining what project they get assigned to and just how personal of an experience that would be. That's kind of the same lens that we observe and experience with the physician in a period of time where you may have read this or heard this, but certainly in healthcare, one of the major topics and stories that has a lot of buzz right now is physician burnout.
We live and breathe it every single day with our users where physicians are really burned out and their job has become less about direct patient care and much more about administrative tasks and tracking of data and submission of billing information, things of that sort. Part of the line that we have to navigate is how do we introduce our solution which we believe has such a strong correlation with less burn out sensation and the ability to actually focus on the types of cases that you want to focus on and leverage your many years of training for the thing that you're uniquely qualified to do.
How do we do that in this context where people have no mental space and energy left to take on new products and new applications in the workforce, a new task. I think the emotional aspect of the finishing engagement piece is definitely something that I distinctly remember from so many of those conversations.
And then I think it's also form a consumer lens, when I think about the patients, I think we're doing a big role. A part of our role at Kyruus I believe is to really educate market about how to think about doctor appointment booking. I think too often, consumers think that whatever appointment they can get soonest is the best option for them. Obviously, they don’t necessarily realize the downstream negative impact of making a choice to go see one kind of doctor who is available tomorrow versus waiting maybe a few days or maybe a couple of weeks to see the doctor who might be better qualified for you from a clinical end.
That’s part of what our product is about, the core philosophy of our solution is, yes, get the patient in efficiently and quickly as possible but never at the expense of getting them to the right clinical provider. That’s another piece that I see come out in droves when we're doing user-testing is, "Why can't I just book this one that is the soonest," before in the workflow two steps ago and just kind of explaining, how do we present that in the user experience has been a big challenge for us. But certainly something that is a primary goal for our product.
Brian: Do you find with the service that you provide that's more doctor facing especially on where they—it sounds like they have to input a bunch of preferences which then enables them to receive more qualified bookings into their calendar so to speak. Is it hard? One of the things I talk about in my list a lot is the need to go out and have direct one-on-one conversations with the people that are going to use your solutions.
Especially with analytics products where lots of data—as the data grows, the complexity tends to go up. What one of the problems that enterprise that companies have is access to the actual, not the buyers of these platforms, maybe you're selling into a CTO or something like that in a hospital network but they're probably not the ones that are going to be using the interfaces and it's hard to get access. Do you have that problem and do you have any ways that you've worked around to entice them to participate in research?
Julie: Absolutely, that is absolutely a challenge for any company in our space with positions in particular at the audience. Even frankly with our call center agents because they have such a real time job that any interruption during the day while they're on call to answer the phone can be viewed as engagement. Yes, we absolutely deal with that.
We have the benefit of a—my cofounder's position, our CEO, we happen to have a very rich network of physicians who are friendly to Kyruus and are certainly willing to take time out of their day to come tell us what it's like on the other side and obviously their feedback on our product.
We are very careful always to balance the types of physicians. There are physicians who work in organizations like Mass General here in Boston that are highly specialized, highly academic focused, probably have a big focus on research and are really on the leading edge of novel innovative medical treatment paradigm versus many of our clients who are not that and who are just regular old community based hospitals that kind of deal with the general population and are not necessarily seeing the most [...] but have to serve millions of consumers and patients who have very basic needs. We’re always careful to balance the type of physicians that we talk to and get feedback from across those various settings.
We also, over time I would say, have taken a much more prescriptive approach with our customers around physician engagement. Certainly has to be the case from the first launch that we were tip-toeing around the clinical leadership and didn't want to bother the folks who were kind of on the clinical frontline. That became a challenge for us to really configure and validate the data within our platform to make sure that we're driving the right outcome.
Now, fast forward many years later, we actually have as part of our implementation playbook a requirement to engage with the clinical side of the business. That was a hard cultural transition to make both internally and with our customers. But now that we have so much data which we can probably talk about but, we have data that shows the benefit of doing that. Not only just data but oftentimes qualitative narrative plays a big role and just getting people to buy into that paradigm.
We pretty explicitly sort of I wouldn’t say forcefully but you know, it's highly recommend to our customers that Kyruus is employed as part of the acquisition process and directly talks to physicians. We've taken a pretty hard line on that and it certainly benefited us.
Brian: So like when they sign a deal, there's actually something in the agreement about your right to access their providers to make the service work and that type of thing?
Julie: Not contractual at all, it's part of our implementation playbook is what I'll call it. Where we lay out here are the four tracks of implementation that we need to accomplish and X number of months. One of them is just purely technical data integration, things of that sort. One might be how do we design our workflow, one might be around analytics and then one is actually physician engagement. It's really just part of our implementation methodology.
Just like almost kind of a consulting mindset. When you hire a consulting firm, they've got their recommended way of doing things and you sort of assume that in order to get the best outcomes, you want to follow their playbook. That’s kind of the approach that we’ve used with our acquisition process.
Brian: I see. That's really interesting. I like that idea of encouraging it from the outset as part of a product company. I think that’s a really great idea to bake into your product if you're on premise deployment type of situation where there's some kind of set up process and you guys obviously have to go through some level of customization probably with every new hospital network that you guys bring onboard.
Julie: We like to say configuration, not customization. But yes, absolutely.
Brian: Oh okay. And you mentioned analytics at the end. I actually did want to jump into that. So obviously if you guys are selling this product on—you're almost like a market maker. You're bringing supply and demand, you're optimizing supply and demand. What type of data, or interfaces, or maybe it's APIs of the hospital. But I imagine they want to know what their ROI is for purchasing these systems. Do you have some type of reporting or analytics dashboard that helps the administrator? Who would be those users and tell me what some of their use cases might be if you indeed have something like that.
Julie: Absolutely. Analytics is critical to the value narrative and ROI of our products. We actually do have a webpage in our analytics product, provide and match analytics that comes with our platform. There's a number of ways by which we deploy it. So first of all, a user, an end user who has the appropriate level of authorization can just log into their browser window and see the analytics dashboard at any point of any day.
We've obviously optimized it. We have a set of canned reports that we offer out of the box to represent the KPIs that we've designed as the leading indicator for the different products that we have. That’s one major component of it. We have a framework where we think about three levels of analytics. One is what I call reflective analytic which is kind of the most basic reporting where we're sort of almost leading back to the organization what kinds of activity are flowing through our products.
It is literally demand and supply. Meaning how many requests for this kind of appointment came in in the last week and then bumping that up against your provider network supply side so to speak saying did you have a sufficient supply to serve that need and what kinds of gaps do you have in that network. That’s kind of the most basic reflective analytics.
One level up from that is what we call impact metrics that say okay, of the 1,000 calls that you got for interpolation related services last week, what percentage of them converted into an actual booked appointment? What percentage didn’t convert and what was the outcome of those calls, why weren’t you able to serve those needs?
How many new patients were you able to acquire through your web based find a physician application that’s powered by ProviderMatch and how many accomplished customers returns to you, were loyal to you by coming back to you and booking a follow-up appointment. So those are some of the types of impact metrics that are kind of a level up from that requested data but demonstrates some kind of business outcome that our product is associated with.
And then the third tier is ROI, true ROI, financial ROI that says, okay, so relative to baseline historically before you can click ProviderMatch, you were able to utilize X percent of your scheduled resources. You had X number patient appointment that were booked in an X period of time of this distribution across primary care and specialty care. There's actually a benchmark dollar amount that are out there that are well accepted that represents the top line value of each booked appointment.
So maybe your specialist cases are worth $2,000 and your primary care is worth $1,000 multiply out the volume that have come through ProviderMatch relative to baseline and determine what did you get for the money that you invested in our product. That obviously is a bit of a holy grail where you're able to demonstrate what did you get back for how much you spent on Kyruus and obviously if you are willing to invest more. Those are kind of the three levels that we describe.
The first two tend to be really self service. You can log in to that web page dashboard, see it, believe it, move on. We have an account management team that has a more of a high touch engagement model with that third tier where we go to the C-level executive team essentially and present that back in an actual face to face meeting on a quarterly basis because there's a tremendous amount of depth, obviously a tremendous amount of assumption and business context that you need to be wrapped around the presentation of that kind of data. We make sure that we're doing that in a fairly high touch way versus some of our more self service analytics report.
Brian: That’s really interesting about how you called it reflective analytics and kind of moves up the value chain almost in terms of being able to quantify ROI for the investment. Is there a way to tell whether or not any ends that… I totally get hospitals there's a financial side to healthcare. Obviously it's a huge financial part of healthcare but in terms of improving patient lives and quality of healthcare and all of that, is there any way to quantify or measure from your service that healthcare is improving or it is that kind of implied from assuming more booked appointments with more qualified. We assume they got better. Is there any way to that you guys can provide that insight or is it too difficult?
Julie: Yeah, we have a couple of ways to think about it. First of all, clinical quality measurement is something that we as a society have yet to crack fully. There is no silver bullet. If anything, there are way too many quality standards out there and not yet what I would call a systematic standard for measuring the impact of a good intervention from a clinical quality lens.
We look at it from one of two ways. One is definitely a derivative by way of getting you two different doctors at first time in a timely fashion, we’re avoiding A, just making sure that you're getting the care that you need, first of all and B, if you were to not get that care at a timely manner typically [...] the delayed care can have a very detrimental impact in terms of the overall health of the patient. That’s more kind of a derivative way of qualitative learning, one way to think about it.
The actual thing that we are looking to quantify and measure and we actually have a couple of academic studies that we published on this topic that were a proof of concept of sorts, what needles we can move. A big part of what we focus on is focus. If you are an orthopedic surgeon and yes you've been trained in 40 different type of things and could technically see a lot of different type of patients, you actually might be best to see a certain handful of those things. Maybe five types of procedures that you're sort of more uniquely qualified to focus on.
If you're not using a system like ProviderMatch, let's say that you'll get referred something from that bigger bucket is pretty hard because you booked the orthopedic surgeon. They assume that you can see any of these type of cases and they end up getting pretty varied spectrum of a type of referral. By way of using ProviderMatch, we're able to deterministically narrow the focus of what gets sent to that physician.
There are many studies that show two things. One is if a physician has more experience around a certain procedure type, then they tend to be better in terms of outcome, mortality and morbidity than physicians with less experience, kind of the Malcolm Gladwell 10,000 iteration type rule. So lots of studies show that.
The second thing is let's say you and I, Brian, are both orthopedic surgeons and I do 50 hip replacement surgeries a year. That’s my practice but you do 80 hip replacement surgeries a year but you also do 30 knee replacements and 20 of some other type of procedure. Even though you do more hip replacements than me, the data shows that I'm still going to be the higher quality surgeon because I'm focused on just that procedure.
That’s what is our clinical holy grail we call it where through the use of ProviderMatch, we demonstrate that we are allowing physicians to not only drive volume around certain areas but also focus more specifically on the areas that they are uniquely qualified to serve and therefore drive better outcomes.
Brian: I could see how you guys could derive that. Someone's spending all of their time doing their kind of specialization area obviously. They're probably building more expertise on that. Do you have any advice for other product managers of data products or analytics practitioners in terms of leveraging design to bring more value to your own business, your organization, your customers. Have you seen any positive change that's come out of a particular design activity that you might have done that you're like, "I would fully recommend doing this," or, "I think that's a really good fit for the product." Any comments on that?
Julie: Sure. I think there's obviously tons of topics like the ones that I described that you can certainly use on a day-to-day to do design and kind of execute the process. But I think the more global statement I would make is that your focus on design has to be genuine and the only thing [...] as the founding head of product, I’ve always looked at design as a critical element of why our product is going to be differentiated and more successful in the market.
Part of how I know that that worked out and then played out is that our customers, we do an NPS survey with our customers periodically. The number of comments that we get back that say, "Your solution is the easiest to use that we’ve ever used in this area.” “The design is so simple. That’s what gets us to use the product and stay using the product." We get that kind of feedback every day.
I think oftentimes, I talk to a bunch of product leaders so technically there's other companies. If that’s not coming from the top, if that’s not a genuine thing and a belief that the person at the top of the totem pole doesn’t have, then I think oftentimes design becomes something that [...] and it's harder in that scenario to make design not just an element of what's being done but really a core part of the engineering process. That’s kind of the advice I would give. Design shouldn’t be another thing, it should be part of the actual engineering process.
Easier said than done but literally, if we think about our teams and how we design some teams in addition to having obviously your engineers, your POs, your project managers, your medreps, a design lead is a required element at each of those teams. That makes it a sticky and fundamental part of the day-to-day process versus someone who calls in as a consultant.
Oftentimes after the fact which is kind of the [...] after a lot of the fundamental thinking has already been done versus having that person be just part of that core team that’s doing the thinking from day one. That’s kind of how it’s played out with that. That said, I would say it's a constant struggle when you're an organization that’s growing rapidly, that has limited resources that has 100 priorities, making sure that you are always emphasizing the value of design which is sometimes very hard to measure in quantitative terms. It's always a challenge.
But I think if you do have a leader who believes in the power of design and that you have properties that make it a core component of how you execute, that you're much better set up to do that than otherwise.
Brian: Yeah. I think there's some good stuff there. Most of the clients that I work with, you can usually tell from the investment and enthusiasm and importance that's placed on the discipline at the top how well it’s going to impact, or how much if at all it’s going to impact even if they have a large amount of staff if those staff aren't properly engaged in the process, they're not inserted at the right time, they're not working upstream with business stakeholders to kind of… I always see this, helping to visualize and put the right experience in to reflect the intent of the product manager and the business.
It's the execution, even though it's a strategic role in a way, it's executing that vision for engineering so that they build the right stuff. If they're not deployed properly, then at best, you're back to maybe painting the pick or doing kind of surface level changes and that can then obviously trick all the way down to your downstream stakeholder like the data that comes out the other end and how useful are those analytics about ROI and stuff at the end. I think some people in the analytics space are still kind of learning. I kind of get this feeling in the data and analytics industry that we talk about data visualization a lot but not necessarily about user experience and what the ROI that good design can bring.
You tend to talk about just UI level details but not necessarily the strategic side of aligning the products from the needs of the users and the business to kind of get both of those positive outcomes. Because obviously, if the business is successful, you can then pump more money back into investing in a better product and experience. It’s kind of a win-win for everyone if you have that buy in from the top.
Julie: Yeah, exactly. We have the benefit of selling into typically what's labeled as patient experience budget. More and more health systems these days are realizing that historically they've been super optimized for physicians. If you look at the example that I always use is if you go to any traditional hospital website that’s not using a product like ProviderMatch, the first question that they typically ask you as a patient is what department do you need to see and how are you as a consumer supposed to know whether or not you're supposed to go to cardiology versus pulmonology versus neurology.
It's kind of ridiculous that we put that burden on the patient. Now, organizations are really thinking we can't do that anymore. We can't get away with that, consumers expect more because of the bar that has been raised during their experiences in other industries. For better or for worse we always say, "Why is it so easy to book a multi-leg international complex flight using just my thumb and 30 seconds on a mobile app, but it's so hard to get a primary care doctor appointment in healthcare? “That’s something that our customers are recognizing.
Because of that, everyone in our company has had some experience with that. We all have empathy with what difficulty and challenge exist around historical software booking process. That’s really where... it's not coming out of like what are the pixels and what color are the buttons and what does the UI look like but what does that entire experience that can be emotional and you might have some diagnosis and some crazy disease and be fearful and anxious while you're going through the experience. We always try to coach our team to remember what it’s like to be on the outside of the table when you're [...] your workflow and whatnot.
But yeah, we again have the benefit of being in a space that I think everyone understands and has to some extent experience. You know the bad side of what does it feel like if it's done poorly so that there's a lot more kind of fundamental motivation at a higher level than just the UI.
Brian: Yeah. You guys have that benefit. I think a lot of people probably don't get that as much where it's almost like you're developing a consumer product in that sense where you can relate them. Like what movie should I go see and checkout and what theatres do I pick and all of that with the whole staff. Everyone at some point is going to go see a doctor so you can empathize with the scheduling process. For listeners that aren't in that situation where maybe you're working on something very esoteric or maybe it's a complete B2B thing where your staff haven't worked in that industry and don't know that pain, it's even more important to go get that one-on-one face time.
Especially getting your engineers and designers to talk to these people and kind of start to develop that empathy. It really can change the way they approach their work. That's cool that you guys are in that space where everyone can probably relate to the pain of the hassle around picking [...]. I hate that stuff when it's like, "Go talk to this department." I don’t care what department it's in, I just need to get this thing done and I want to know what the results were of this test and I don't know who to call, it's your problem.
Brian: Well, cool. This has been super fun. It's been great to catch up with you and hear what you guys are doing at Kyruus. Can you tell people where they can learn more about you and what you guys are doing?
Julie: Absolutely. We've got a great website with a ton of resources and videos and white papers and case studies and what not around what we do as a company, kyruus.com. We have a pretty big presence on social, on Twitter, on Facebook, on LinkedIn. Follow us there. And then me personally, I think Twitter is probably the best place for folks to follow along with what I'm up to. I'm @julesyoo on Twitter.
Brian: All right, I'll put that in the show notes, the link to your Twitter account and also over to Kyruus. Julie, thanks for coming on the show. It's been great to catch up with you and I hope we get to cross paths soon.
Julie: Absolutely. Thanks so much for having me, Brian. It was good to chat.