Brian Scalia
Director of Product Management, Patagonia Health
Join Product Director Brian Scalia as he discusses how Patagonia Health's EHR product team stays agile, prioritizes user feedback, and navigates regulations to deliver impactful updates. Gain insights on balancing innovation, staff training, and optimizing workflows for better patient care.
Introduction
Welcome to the Patagonia Health Healthcare Solutions podcast. My name is Denton, and I will be your host for today. Today's topic is how to stay updated with healthcare regulations and critical system updates. And we have a very special guest, and I'm going to go ahead and let him introduce himself and talk about his role. ,
Brian Scalia 00:56
My name is Brian Scalia. I'm our Director of Product Management here at Patagonia Health. I joined in 2025, so I'm new to the company, but not new to the space. I've worked with EHRs and healthcare technology for the last 20 years. Other than Patagonia Health, I've been with about three other EHR companies. Some prominent notices, notable ones that people know about in the industry, are very passionate about healthcare, improving healthcare, improving the systems that support healthcare, our clinicians, our patients, and product management itself, which I know we'll get into and talk about today.
How does the Product Management team ensure EHR solution updates align with user needs?
Great question. So, just to step back a bit, in product management, our role is to represent the voice of the customer. And so we work, we are kind of the middleman, if you will, between our customers, and not just our customers, but also the market. Our potential customers, and then the go-between with our development team. Okay, so, feedback comes in from numerous sources. They come directly from customers. They submit ideas through things like portals, emails, and phone calls, but conversations, user groups, things like that, that we do, and we take in all that feedback. We prioritize it, and then ultimately give that to the development team to be developed.
How do you determine which product updates are prioritized and which can wait?
Yeah, that's the secret sauce of product management, right? It is, like we said, that we all know we can't do everything, right? And so, with several 100 customers, and within those customers, 1000s of users, right? Everyone's needs are different. Yes, there's a lot of overlap between them. There's a lot of overlap between certain roles, whether a clinician, a front desk staff member, or a biller. Ultimately, we prioritize based on a couple of different factors. One of them is pervasiveness, how many users have this problem? So we do use some tools. We have a tool called AHA, which is a product management tool, and it also allows us to collect ideas, enhancement requests, and feedback directly from customers.
Other customers can see those and then vote on them, and then, working with some of our internal teams to understand that need and the customers themselves, we can get an idea of how big this problem is that we are trying to solve. That's one criterion. Another one is, how big is that problem for a particular user? Right? So, if there is a gap in a workflow, how critical is that to that particular user, and then on top of that, is solving that problem? How much delight will that bring to a customer? And so, what we do, basically, is we use some frameworks that help us score these things, and some of it is subjective. And. We try to be as objective as possible, and use data to help us prioritize these things and ultimately get a stack ranking of these areas that need to be solved. And some of them are short-term things that come in. Help me stop the bleeding, so to speak. Others are longer-term strategies. Where is public health? Where is behavioral health? Where are those markets going? What are the future challenges that we can anticipate and build longer-term strategies for? And that all goes into the prioritization.
Are there any standard goals set for each update? How do you measure success?
Generally, there are some common or generic goals that you would use from release to release, things like the kind of smoothness of delivery, right? We measure if some bugs or defects come back to us, right? We work with our development team to measure the number of those and how quickly we can, from release to release. How can we minimize those numbers? How quickly can we resolve those? How quickly can customers adopt our new functionality? We are one of the tricks in this field, along with many other products, right? But specifically in the kind of healthcare with our workflows, our users are very workflow and process driven in what they do. And so if you introduce a new piece of functionality, even if it's positive, it impacts them. So, the goal is to minimize impacts as much as possible. Those are some of the overall things that we measure.
But then within each release, a release generally, is kind of a theme of several features that we're delivering in this we use basically six month release cycles, so in that specific release, there's generally a theme around it. Still, each feature will have its own goal and its success measure, and we use what's known as KPIs, or key performance indicators, to help us measure how that feature is is improving over time. Sometimes you have a set goal. It might be that we want to have this feature adopted by 80% of our customers within 30 days, and some of them are specifically into that feature itself. So the feature may be around, decreasing time for a clinician to be able to perform a certain step, and we could use tools to time that and get feedback from them, either kind of subjective around this, this is a great feature. We love it, or even being able to measure it, by using telemetry-type tools to say we see the process speed up when the user uses that feature. So we are very much data-driven in the work that we do, but we also measure its success afterwards.
What does it take to find a healthy balance between innovation and simplicity?
It is one of the most difficult things that we face in product management in general, but again, kind of more so in healthcare, because of the very structured workflows of a lot of our users. And so again, going back to our previous question, where do we get ideas from? So we are collecting these ideas, but we don't talk. We can't talk to every single one of our users. So, we use data, we use surveys. We use different. , in both qualitative and quantitative ways, to understand if this is going to be helpful to a user. With that being said, we can't get to everyone we use, we communicate with with customers, , ideally giving them advance notice on new functionality that's coming out, will the team will analyze and assess whether certain pieces of functionality are going to be impactful, or if there are things that you can educate people on afterwards, that there is new functionality there you need to go and find it, but it will help you, other than just, , putting something right into, their their workflow, and even if it's good, , causing a disruption. One of the things that Patagonia Health does is deliver many of our features to our customers, but they're not turned on. And so what we do is, within our release notes, we will notify customers that there is new functionality available.
We'll talk to them about its benefits and value, and how it might impact them and help them. And then they can request to have that feature turned on. The benefit of that is that people can say, Yeah, I am interested in that, They can talk about it internally as an organization and then elect to turn it on, understand what the impact is, we can work on training, and leverage training guides and things like that for them. And what it does is minimize that. The downside is that customers are often unaware of those changes, right? So that's where we work closely with our marketing, support, account management, and even sales teams on new functionality that's available to ensure customers are aware. In our field, the worst thing we can do is to release quality changes and software out to customers, and then not have them even know about them and enable them. And that is kind of the magic balance, trying to get as much value out to them, to drive the benefit to them, without causing that impact. And it's tricky, and it doesn't always work, right? And we, oftentimes, have to explain to customers afterwards why we did something and what it was for. And, it's not always a smooth process, but that's what we strive to do.
Can you walk us through the rollout process of an update?
The primary tool is the release notes. And so, as we said, we follow a six week release cycle, and at the time of the the release we release release notes, or make them available to our to our customers that highlight the big changes that happen, the value kind of but but also some of the defects that were fixed, and some of the smaller enhancements that, , are nice delighters, but maybe not significant changes. The way that that works is we, over the course of the release, get releases planned so we know which features will go into a specific release. My team, a team of business analysts, will work to pull together those highlights, constantly updating them.
Then, a couple of weeks before the release, we'll do an internal review and get feedback from our subject matter experts and customer teams. We send out a draft in advance of the release to customers, giving them a chance to see what is coming so that they can have time to prepare. Then, there's a final release note that is sent out at the time of the release. And so, there are other things that we do. We will send out a semi-annual update as a reminder. If you haven't seen this, we talk to customers through user groups and things like that as well to provide those updates. One of the things I mentioned again is coming. This year, some of the changes that we're going to put into place are one of the tools from a product management standpoint, called a product roadmap, and it is what it says, right? It is where we are going. And one of the areas that we want to improve upon is providing more visibility, internally and externally to our longer term roadmap, other than what we're doing in the next six weeks or what maybe we're doing the next 12 weeks, but what is a glimpse of what we want to do over the next year? There's also this concept of being agile, and product agility is all about being able to respond quickly to changes in the market or with customers with new challenges, and being able to pivot quickly to adapt to that.
So we are both agile and trying to be more strategic at the same time. And so the balance is that things that are happening in the next couple of releases will be more defined and a little bit more in place, where things that might be happening six, eight months down the road are still at a high level, maybe conceptual, and as we get closer to that, we define them more. But the idea behind that is it gives our internal team and our customers an idea of where we are going, and then you can have those conversations around, well, I'd like to understand this, this change that you're talking about, so we can maybe provide some feedback into it, or we can understand that, because it sounds like it might be impactful, so kind of in conjunction with the roadmap and doing more kind of presentations to our customers around things that are coming. In conjunction with the release notes, we believe that it will be much more effective, again, kind of giving customers a glimpse into the future and also what they can expect in the next release.
Do these roadmaps help users see the bigger picture?
Yeah, it is a, you kind of move from a, there's a concept called a feature factory, and it's where you are moving very quickly through smaller features, reacting to things that you're hearing, to a strategy, and a roadmap is a strategy. It's a plan on how you're getting to your future vision of your product, which incorporates all of the feedback. And you're right. It's easier for customers to grasp when new changes come with just getting a set of changes all over the product, versus knowing that there is a thematic plan for where we're going. Some releases may be targeted to a specific user type, which we call a persona. Is it a clinician, and those are our nurses, our physicians, our nurse practitioners, our physician assistants, or anyone really in a clinical space? And we might have a lot of functionality around that that those users are more interested in that release. We have some that are targeted towards front desk or admin users or billing users, and some that are really specific towards our behavioral health customers. And so if you can wrap those around the theme, it certainly helps all of the users to focus on what's changed for them and what they should look at. Awesome.
What are the best practices for users to keep their internal teams trained on system updates?
Certainly a lot of lessons learned. One of the challenges is that companies do things very, very differently, and even more so, the tech industry has evolved drastically over the last 20 years. When I first got into the business, there was a 20% adoption rate of electronic health records within physician practices. Wow. Our goal at that time was to sell the value. What's the ROI for the electronic system? And physicians were very, very hesitant at that point.
So I've seen this evolution where it went from it's maybe a neat thing to try to see how it can save me some time and allow me to get to my records and safeguard my records, to being something necessary to maintain the highest level of care and efficiency and to be able to share, data across multiple, physicians and clinical sources, I think, where I would say, as far as kind of keeping community, where, how can customers stay really in the fold is leverage the release notes. Look at the communications from Patagonia Health. You and the rest of the marketing team do a fantastic job of notifying our customers. And, I think you strike the balance too of not putting too many things in front of our customers, right, so they don't get overwhelmed, but release notes and highlights.
Spend the time to look at those. Ask the questions. Reach out if you have questions about certain functionality. But also leverage some of the things we're trying to put out there. I mentioned our idea portal, where customers can submit ideas. It's a really fantastic tool that not only allows you to submit an idea but also to review the ideas that other users have suggested and see if they align with your needs. You can vote on them. You can add something. You can add a new comment. My team reviews those regularly, asks, reaches out to the customer, and gets some more understanding of them. I might ask for it and have a session to clarify something. But then we also look at that. And again, we can't do everything, so we have to be better about letting customers know we love their idea, but we're not going to do it. It does not align with where we're going.
And other feedback that we're getting, I think it's an area for us to improve, is that it's hard to say no to a customer, but the customer doesn't want their idea to sit there. They want to be notified whether they're going to do it or not. And if we say we're not going to do it, you can talk to us and maybe make us understand. But I think, dedicating and having a champion, or those people within a site that can be the champion to us, and be, you're kind of just like we are the voice to the customer, to the development team. You can be the voice of your organization to our product management team and share that I am, in this role, kind of stepping into a leadership role for product management. I am actively trying to meet our customers, our leaders, our champions, and our influencers in those organizations. I want to be that place where they can go to suggest new things, to complain about things. I am here to listen and to do what I can to help them make the product better for all users. So that's again, a newer side of things. Please reach out to me. Beascallia at Patagonia health.com, and I'm always happy to listen to your feedback.
How important is it to stay agile when it comes to new and emerging regulations in the healthcare space?
Yeah, it is. Every industry has some challenges out there, whether it be the financial sector or healthcare. There are kinds of looming regulations or things that are just part of it; it's part of signing up, right? It's your price for admission and healthcare, which certainly has many regulations. But also, these are good things for us, so we don't complain about them. They make it harder for us to work, but they are things like security and protecting data are critical. And when you hear about breaches in the industry, right, they have put many a company out of business and have jeopardized data in the past. So. We really hold, very, very close to our, to our chest, that protecting our patients data and, yeah, and so there's, there's that level of security, and a lot of that is kind of driven by things like HIPAA or high tech, which are, kind of government programs out there to protect, patients and also providers.
And as far as other regulations go, we stay close to the market. We stay close to associations that are out there that either govern some of the groups that we're a part of, or some of our customers, or that act on behalf of those, and they're out there driving change. And the changes might be things that the government needs to be preparing for, part of Medicare and Medicaid, and new regulations that are coming out there. Sometimes they help, sometimes they hurt, but they're there to serve a purpose. So we stay close to those we have, a number of internal subject matter experts that track the longer-term things that are coming out there. Many of the government programs will put out something, say a change is coming. We're going to shift a standard, and it might go into effect in 2028 so it seems like a long ways away, but what happens with those is, a draft comes out, then there's a period where you review it, then there's a feedback period, and by the time you're ready to start developing, all the sudden, you have no time to get it done. So we also, again, this is where our customers come in.
Some of the the leadership and the organizations that keep us abreast of those changes, but as part of our, agile processes and and strategic, if we know that there is a change that's coming out in advance, we can build that into our roadmap and plan accordingly, but we also leave time in our development, into our development cycle, to be to be able to take on that work. So, unfortunately, we do find out about things late, and our customers find out about things late, so we have to pivot quickly to get something done in order for them to maintain getting their funding and ensuring that they're getting paid and patients are getting the best quality of care. So again, it's a fine line between agile and strategic work, but we feel we're pretty effective at both.
Have you ever had an unexpected user reaction—either very positive or negative—to a system feature rollout? How did you handle it?
This does, unfortunately, happen a lot. And I said that in the earlier, earlier in the conversation that you do your best, we use, we use data to understand how people are using things, how users are doing things in order to make better decisions, we talk to our internal subject matter experts, to our trainers who are training the product, and this is how we effectively change it, understanding though, that users find their way, right? So even though the system is designed and trained a certain way, users will find their own path of least resistance to get their job done, and sometimes that's going around or doing things a little bit differently. It doesn't mean that they're doing it wrong. It may be that because of their workflow and their specific business, there may be an easier way for them, and therefore, when we make a change, it could have a negative impact on a set of users.
So, we again strive to minimize that as much as possible through our internal quality assurance testing team, testing that calls out some of those changes that we may not have anticipated. Our internal teams are doing what we call UAT, or user acceptance testing, or testing and thinking about something on behalf of the user, and giving us that feedback. Back. And then, last ditch, it gets out to the customers, and we get feedback. Our customers will let us know when things are not working the way they expect them to. And we need that. We get that feedback is not always the most pleasant thing on the day after a release, and it forces a scramble, but it's absolutely necessary in order to protect and serve our customers. So there are a couple of things at our disposal. Certainly, what we can do, from a communication standpoint, is reach out individually, talk to those users if we're starting to see a pattern, and if there are more users, we can put together a communication plan to get that communication out. What we want to do is explain the rationale behind our decision. What were we trying to accomplish? What were some of the challenges that we foresaw or that we saw that we were trying to solve, and then also explain how this feature can be used most effectively? We'll do webinars when we need to.
We'll put out recordings when we need to. And as a last-ditch effort, we can roll that code or roll it back partially. Sometimes there's a large change, and there are some of the features in that change that are good. Some of them disrupt a certain customer base. We can partially roll back things and maybe set up strategies to work with certain customers, to try to get them to support them in getting onto that new feature. There are times when we anticipate there being some of those, and there could be challenges. We do a kind of risk assessment to understand the potential impact, and go in with some strategies that will help, maybe some of those smaller customers, not smaller customers. This is the smaller population of users who are using the system differently to help them adapt to a new change. It's a balance of science and art in order to do that.
