Hi, my name is Joe Market and I'm happy to be joining you today. I currently serve as a research associate with Johns Hopkins School of Medicine, Biomedical Informatics and Data Science program. Today we're going to be talking about understanding your customer. We're going to start by going into defining the customer, then we'll go to some key to success, some common mistakes and finally a couple of industry examples. So let's kick us off. Let's start by defining your customer. This is critical. You have to understand who the customer is. You have to understand what does the customer want to buy? When do they want to buy it? Where do they want to buy it? How do they pay and what price is a customer willing to pay? I know these might seem like obvious questions but they do make the difference between building a product that is going to be successful in the market and one that isn't. Sometimes you don't understand who the customer actually is and so you might be building it for customer A where truthfully customer B is your target market. So you really need to understand that. That starts by doing your research. Where does the customer want to buy? Or what does the customer want to buy rather? Well if you build something they don't want to buy, you will not get to say obviously and that's going to hurt you in the long run. When does the customer want to buy? Restart this slide. Defining your customer. Here are some key questions that you have to truly understand to build the best product that you can. So who is a customer? What do they want to buy? When do they want to buy it? Where do they buy? How do they buy? And what price are they willing to pay? Just a couple of questions that are important for you to answer to really understand who your user is or who your target customer is. So who are they? Your customer and your user are not always the same person. We'll talk about that in just a minute. What do they want to buy? You have to make sure you build the right item or the right product so that they are going to buy something. If you ultimately build something that satisfies a different need for the customer, you may end up getting a sale, but it's going to be separate from obviously what you were targeting. Let's say that you want to build a travel app. You want to do something similar to an AirBnB where you want to set up lodging and things like that. If ultimately what you're trying to do Okay defining your customer. Here are some questions that you need to answer. It's really important to understand who your persona is, whether it's your buyer or your user. Here's some key Defining your customer. Here are some key questions that you need to answer. It's really important that you understand who your persona is? So who is the customer? The customer is not always going to be the same person as the user and we'll talk about that in just a minute. What does the customer want to buy? Do you truly understand the problem? And you truly understand what the customer is looking for in a solution? When do they want to buy? Do you know how long the sale cycle is, nine months, three months. Are you starting it too early? Are they not ready to buy something at that point? That's really important to know too. One of the worst things you can do is come to market and expect the sale before they're actually ready to buy? Where does the customer buy? Are you meeting them in the right place? That's part of what's important in setting the stage as well. How do they pay? And finally what prices the customer willing to pay? It's really important to understand the pricing and what the appetite is for, what they're willing to buy and what they actually have budget for. They may love your solution about the end of day if the cost isn't right they're not going to move forward with you. So what are some keys to success? Again, you really need to understand your personas. Your customer and your user is not always the same person, especially in health care. Your customer can typically be somebody in the sea level, could be somebody like the chief financial officer, whereas your user at the end of the day could be an analyst and they are two separate people sometimes are the same. They could be, they are two different people and ultimately what you want to do is you need to make sure that whatever you build, you need to make sure you understand both your user and your customer there. You want to make sure that you have value propositions for both of them. The key success is understanding what both the user and the customer needs as I mentioned adoption. You may build something or you might sell something that the customer wants and the customer is going to purchase it but if the day to day user is going to be your analyst and it doesn't satisfy their needs, you're going to be out as soon as the contract's up if not sooner. You have to focus on one product, that one problem at a time. You could build a platform solutions for an end user, but if you don't focusing on one of their particular pain points for the problems, you might try and solve too many things at once and ultimately they're not going to find value in any one thing. If you solve something partially and another problem partially ultimately you're not going to solve what they're truly looking for and ultimately your product's going to fall flat. It's critical, I understand pain points and this kind of goes back to the problem and focusing on the problems, this is all your requirements. So what is the pain point to the actual user? It's going to be key to building something, it's going to be key to anything that you do make sure you understand what the user is, whether it's on the sales side or the actual product side. Finally, you need to research the problem up front because if you don't, you don't know what the requirements are, you don't understand the pin point and that's really important for you to be successful in this a few more. There are many ways to solve a problem. There is not one solution. So you may see something on the market already, a product may go out there and it may solve the problem for the user, but you may have a different approach. Something that has better user design or user experience and that may go a longer away with the customer because it's less clicks, it's embedded in their workflow. So there are different ways to solve the problem, you may solve it differently too, you may have different analytics to do the job. It will depend. Data can unveil previously hidden requirements. Yes, so data is important. Not only, it's not all quantitative, sorry, it's not a qualitative, but you do need to have data to back it up. How many users do they have today? How many users do they want to get to? This type of data is important. What does survey data say? What are the types of users that you're going after? What do people actually report your stories and who you talk to? Maybe one small piece of the puzzle and there may be an entire market out there that you're missing or not really understanding. So data is important because there will be some critical requirements that you might miss without it. Your customer may not always be who you think it is. So your customer, you may be going into a hospital and expecting it to be the CFO that's going to be your customer when at the end of the day it actually might be the Chief quality Officer. Maybe they're the one that's going to the budget. Might be the CFL that signs a cheque but it's actually the customer is the chief quality Officer. So it really does depend you need to understand from end to end all the major players whether it's your user, your customer etcetera. Communication is critical requirements can shift easily. So you might be building something for a particular use case but you need to make sure that you are communicating along the way One way of doing that is to build something small and fast and get it out prototype it. One way to buy prototyping, you get feedback immediately. You may ultimately have a customer or a user, who says that they think the solution is, x and for that might work. But the reality is, that may not work because you may show them exactly what they said, prototype, the exact way that they thought they wanted it. And they go to use it and it's not right. There's many examples of this throughout technology especially. What are some common mistakes. Well, not knowing your customer is probably the number one. So it's critical to understand who your customers are, in a variety of ways. Some examples of this maybe cost. What again? What will they pay for the solution? This is important because if you go out to market with something that's $200,000 as a solution, and they're only willing to pay 50,000, like you're going to miss the mark quite a bit. They're going to probably soft and they're going to continue on. It may be the perfect solution, and they may have the budget for it and you may have come down to that $50,000 mark. But because you didn't understand what they are willing to pay, you lost that sale. And so it's really important to understand this. One way of doing this is seeing who else is out there. What other solutions are charging, do a pricing comparison to see if that's there. Then talk to people at the beginning of the sales cycle, understand what they're willing to pay that's going to be important as well. It's a negotiation. Think of it like a job interview in a lot of ways. Convenience. Does the solution alleviate any pain points? Does the solution require the consumer to go out of their way to use it? This is really, really important. There might be a solution that's in place today that you end up getting a sale and replacing them. Why? Because you understood who the users were. You understood who the customer was. You understood exactly what problems you were trying to solve. And you solved it in a better way, than the previous product that. And finally, access is a solution available to all. Are there any blockers? Is there some reason that somebody can't use it? Is your product built with a particular business intelligence tool and you need a license to. And you either they didn't have it internally or nobody knew how to use the business intelligence tools. Does the libraries that you're using for whatever reason have to work on a particular browser and maybe Internet explorer 8 or 9 or 10, don't work with those libraries. And ultimately, you can't load the page. These are all software products, but there's a number of things that prevent that from happening. Is the product not built in a way that the reader can use. Or the user can use, maybe they're color blind and maybe there's no way for somebody to distinguish between the colors on the screen and the color might be a particular indicator for the end user. And so that's really important. So all digital health solutions need to factor in consumer preferences. So some common mistakes there are a couple examples out there. But not only that I mentioned, you need to know your customer. One other thing we mentioned earlier with data. There's a lot of consumer health surveys out there, a couple of examples on the screen. But Deloitte Accenture put out a couple of surveys every year and by doing a search, you can find some other ones out there, but just a couple of fun facts about it. Millennials trust health and wellness services offered by a tech company more than under other generations, 43%. Probably a little surprising, but these are the types of surveys that come out. And I'll read one or two more for you all, but these are the types of things to keep in mind when you're developing a solution for a particular generation. Again, you need to know who your end user is, is a Gen Z, is a Gen X and Millennials, is it a Baby Boomer? You need to understand who that's going to be because ultimately at the end of the day, these things matter. The largest increase in the use of virtual health among Gen X, 7% Baby Boomers, 5% those were the two biggest increases of virtual health. However, technically the highest uses Gen Z and Millennials. And so if you're building something like a virtual health platform, you need to keep that in mind. You might get more adoption from Gen X and Baby Boomers. But ultimately, at the end of the day, you're the majority of your user, your consumer is going to be the Gen Z and Millennials here. So not only do you need to see what consumer preferences are. But you need to understand the data behind it to the data might be telling a different story, the headline might be telling a different story. So all that's critical to know. So as I mentioned, it's really important to understand who your customer is. You can really need to understand them from a cost convenience and access and accessibility standpoint. Here are a couple of examples of those that didn't necessarily know their customer that well. Walgreens aim to streamline healthcare delivery by opening 400 walk in clinics at stores across the country. But in October of 2019, the company reported would close 160 of those clinics. Those that they're ran by itself saying that the clinics barely broke even. The retail giant kept open about 220 clinics at the stores that were run by local health systems. Health fault didn't offer patients much of any insight into their health problem areas, how their health was changing over time or what they could have been doing to improve it. Microsoft health vault may have been the first to market in terms of arming people with their health records, but they failed to offer people and their health care teams. They actual insights and support needed to change the health behaviors and outcomes. Health spot was a telemedicine Chiasso ultimately lost out to the likes of Teladoc an American wealth. Health spot required patients and providers to pre arrange appointments, which was truly not telemedicine on demand. You actually have to build a lot of administration around it. This one actually saddens me quite a bit because it had a pretty good use case. The downside is that Teladoc an American well figured out telemedicine on demand, rather than setting up telemedicine as a whole. So sometimes you might be first to markets. Sometimes you might have a truly good value proposition, but if somebody beats you to it, somebody has a better user interface or some way to remove some barriers to entry. Ultimately, it's going to win out. Care sink actually helped enterprise customers and consumers manage medical records for Medicare patients. Particularly those with chronic conditions, although some services were free, such as appointment planning and medication reminders cursing charges, subscription fee for keeping personal medical records upstate. It also provided technology to support annual wellness visits and traditional care management, which was good. But ultimately, like the subscription feed didn't resonate with its end users. Not to say that it couldn't, but there was a way to get the patient medical records without a cost associated with it. It might have been a few extra clicks and some phone calls, but ultimately the customer did not see a value in the subscription based service. And finally, my last example, is there a veil. So founded in 2015 the Seattle startup inspired to pioneer a new sector called scientific wellness. Essentially combining genetic testing with personal coaching to improve the health of its members. Air veil raised more than 50 million funding employed 120 people and served about 5000 members over their license program. But they failed due to the reluctance of Americans to invest in their health. Now despite success stories of their air veil members, they launched with a cost of $3500 per year, pretty steep cost for somebody that needs to then maintain their own health. And so even though air veil tried to pivot at some point and offer a $99 per month subscription, for its ongoing genetic testing and coaching. It couldn't overcome the previous history that it had had and it just missed the mark in terms of cost. And so it's really important to understand cost, convenience and inaccessibility and those five examples above and that I previously mentioned are Are a couple of examples there. I'm going to go to a specific example and I want you to walk through this with me but the example is really around no patient history. And so I'm going to give you a little bit of a case study here and then we're going to all go through it together to make sure that we understand the problem. The customer, the users and the customer versus the users and if they're the same or different. And so I'm talking to a client that is a advanced payment model client. They're actually entering into an advanced payment model called direct contracting their physician group. They rerecord side the record sideline. So now we're going to have to walk through a quick case study and I want to see if you can follow along with who the problem and what the problem is, who the customer is, who the users are and if they are the same or different in terms of customers first users. Right, because again, it's really important to understand how your users and your customers are. So picture this, you're talking to a potential customer and they approach you and say I'm enrolled in this advanced payment model called direct contract. Not only that, but they've never participated in a risk arrangement before for Medicare Beneficiaries in particular and they have to get a certain number of enrollees by a particular date and they asked if you can help with this. So in this example you and your company have a mechanisms for solving this. You have a direct contracting product. Right, and so you were talking to this physician group. This direct contracting entity, they don't have any insight. So no longitudinal claims data into the patients that they're treating. They do have the clinical data but they don't have their claims data. The physician group does not know which patients are appropriately are appropriate for voluntary alignment in particular. So what's the problem? Who is a customer? Who are your users? Are the customer and uses the same or different people? What are their needs? And can you satisfy them? I'll give you a minute start through this and we'll talk about the answers on the next slide. Okay, so back to this example. What's the problem? Well, ultimately that there's no insight into the population population that that direct contracting entity is created are treating rerecorded side. Okay, let's see how you did. So what is the problem? Its lack of insight on the patient population that this direct contract against who is treated. Who is the customer? Well, it's the administration at the in the direct contracting entity because again, they really want insight on that patient population. They do want to make sure that they're targeting the right patients for voluntary alignment because that is their mechanism for getting up to that that enrollment by a particular date. Were the users? Well, you've got several users here, you've got some who are physicians and care managers and the physician group and those are folks in particular are looking for insights into those that they're treating. Whereas the administration on the direct contracting is just making sure it's a separate user and they just want to make sure that you are hitting the appropriate number of beneficiaries by the time of the formation of the direct contract entity. And the contractor liberals are your customers or users different the same? Well, it depends on who we talked about in this case for different the customers want a way of a scalable way of saying which patients are the right patients for the DCE. So that voluntary alignment the administration the bone of the direct contract entity. Whereas the user wants insight into how they should best treat the patients. We can satisfy this via a couple of different ways, CMS Global 2.0 program. CMS state at the point of care, which we will talk about in a separate lecture. So I'm going to give you another example on the next side here. Plan shopping and let's see how you do. So in this case my parents are newly eligible for Medicare and I'd like to help them pick the best plan for them. So the plan is the most appropriate for them. They have several chronic conditions and they're on several different medications. So again, just like we did before. What's the problem? Who is my customer for? The users are the same or different people. What are their needs? And can I satisfy one? I'm going to leave this with you as a takeaway as sort of a homework session. Thank you for your time.
