Turn Skeptics into Champions: Fostering Trust in Healthtech

Unlike in some other industries, product led growth, it doesn't mean growth without guardrails when you're working within digital health or healthcare, right? I think that's critical, but I think it's also thinking about letting the product prove value within the real world use case. You have to be really thoughtful in when you're creating a product that's impacting clinical outcomes. We have these experiences in healthcare that really rub us the wrong way.

We have a negative connotation around healthcare. So if you can create a digital experience that's a delight to use, it's easy to use, it's made your life easier, then you're likely to have people talk about and start to have that organic growth. So the product itself really becomes the driver of trust, engagement, and ultimately scale.

Hello and welcome to Hard Problems, Smart Solutions, the Newfire Podcast where we explore the toughest challenges and the smartest solutions with leaders across technology and healthcare. I'm Will Crawford, the head of advisory services at Newfire, and I'm your host for this episode. So today's episode is a deep dive into the reality of building and scaling digital platforms in an increasingly crowded market for healthcare solutions.

I'm very happy to be joined by Alexis Levine McKenna, the former chief product and technology officer at Huddle Up Care, and a product leader who's worked at the intersection of care delivery, platform strategy, and clinical innovation for over a decade.

Alexis brings a great perspective on something that's very close to my heart; how do you keep clinicians, caregivers, and patient outcomes at the heart of everything you're trying to build, while also adjusting to markets that are changing on what seems like a day-to-day basis? We'll also get to spend a little bit of time, I hope, talking about the challenges of managing both product and technology delivery at the same time. So Alexis, thanks for joining us today.

Thanks Will for having me, I'm excited to be here.

So let's start by talking about your journey. You've held leadership roles in both sort of early stage and growth stage companies but your path into product and technology, wasn't, going to school for product management. So, can you just take us back to the beginning and tell us a bit about what drew you into digital health and how did that evolve? Yeah, absolutely. So definitely didn't follow the conventional path, but joined an early-stage startup that was in the digital health field.

Digital health was sort of a new emerging term, quite frankly, in field at the time and joined when they were less than 10 people at this company. We were focused on building technology to support corporate health and wellness. And I was team member number seven asked to come in and help, jump in and help with the sales organization and help figure out how do we sell our product that was brand new at that time. It was really just a health risk assessment.

So very basic, trying to understand the health of a population and how do we scale that. And so, as you can imagine when you join an early-stage startup, um, you're wearing a lot of hats. So even though I was brought in to help on the sales side of the organization and jumped in to help you with marketing, if you're working across the organization, it's all hands on deck and quite frankly, you have to get scrappy. And so I was working very closely with our small engineering organization.

We didn't have a formal product organization at the time but we had a weekly product development meeting where the entire company, would actually sit down, go through the product, whiteboard, ideate, look at feedback we were getting from customers, from prospects, look at data that we were collecting and start to really build out the product and scale it. And I quickly realized that's what I love doing.

I love to make an impact in building out a product, building out a product that can impact lives and clinicians and that the sales part of the organization was fun. It was great to talk to customers and prospects and learn what their needs were, and it really created a foundation and appreciation for me of understanding what creates value for end users. But it was a nice foundation to jump into product eventually.

And even at that early stage, thinking about that exposure that a sales team gets to client needs, what did you learn early on about translating that sort of sales motion, into product motion? Yeah absolutely. I think listening to your potential customers, if they're leads at that point, or customers, right, is really critical and core to building a successful product.

So understanding what differentiates you in the market, what is not working, what is working well, what is keeping customers happy was critical. And being able to dilute that feedback for a technical organization to say, Hey, we need to make this iteration or adjustment was key. So I quickly learned the importance of documentation. That was one core piece that I learned is documentation is gold and important when you're working across an organization and when you're collecting feedback.

Also quickly learned one customer is one customer. So you really need to understand right across your customer base, uh, and across the market, quite frankly, what the needs are, and not just be reactive, really making sure that you're being thoughtful in your decision-making so you're not pivoting too much. But then also making sure that you are listening to the qualitative feedback, but validating it with quantitative data as well.

At a company like MediKeeper, you have, a clinical element as well. So when you were out there in the field, in that sales role and then, taking on more of that product responsibility, what were some of the first things that you learned or maybe that you wish you had known at that point around managing clinical stakeholders, both as customers, but also as part of the delivery organization for the company that you're working for.

Yeah, I mean, I think what I quickly learned with clinical stakeholders is often that they don't have a lot of time, right? So they're often busy trying to see patients or have other responsibilities. So making sure that you're very direct and to the point with them and transparent is key I have found to building trust and being able to get feedback from clinical stakeholders. One thing that I, I wish I knew was how important it was for clinical stakeholders.

They wanna hear how it's going to impact their lives, their patients' lives, and how it's ultimately gonna drive clinical outcomes. Right. And so if you can explain quickly, especially the sales process when you're showing a product that is often, in my experience, it's always been platforms or apps, I think clinicians can be a little bit wary sometimes of technology and nervous about adopting new technology. They question, is this going to make my life easier or is it going to be burdensome?

So being able to explain how it fits into their existing workflows and how it it fits into their patients' existing workflows or makes it easier for their patients to interact with the services, uh, that they're trying to get is really, really critical. So I think what I wish I would've known is that I, I knew what made clinicians tick at that time, which I just didn't have the experience to know it yet. And so after working with clinicians for quite a few years, you start to understand it.

So after MediKeeper you joined what is now Huddle Up Care? I think it was called DotCom Therapy at the time. So what did you walk into there? What brought you what, what made you go from point A to point B? Yeah, absolutely. So had built MediKeeper, we had quite a bit of success with large payers at that point.

We're working with some really impressive employer groups and felt like I had, uh, run with the company and really helped it grow to be successful and was ready to just take on a new challenge. And so when I jumped into Huddle Up, Huddle Up was at an interesting point in that they had recently introduced technology. They were scaling. Telehealth was taking off. It was right after COVID. So as we all know, telehealth was having its moment.

And I walked into an organization that again had a small engineering team, didn't have any formal product function and really needed to mature the product organization as well as assess where the current product was.

What I quickly learned was that the product was built in a scrappy way, which is quite common is we all know when you walk into a growth stage or early stage company, they're usually just trying to get a product out there to see how the market reacts and realize that, the product that they built just wasn't going to scale. It wasn't built to scale and grow as the company was scaling and growing.

And so we really needed to rethink our architecture from a technical perspective, but also rethink how were we engaging with our end-users, so all of our stakeholders. So how do those two factors combine? You're looking at the technology and the architecture, also it sounds like you had some product, feature function, engagement model. How do you thread, how did you thread those together?

So I think if we first look at the architecture, in some ways that feels easier, right, it's really kind of a technical assessment of where are we today. And so we were on a monolith where there wasn't really separation of priorities and we were already seeing bugs and things breaking, and we're starting to get negative feedback and quite frankly, starting to lose trust.

From a product perspective though, it gave me an opportunity if we were going to re-architect the platform, it was a great opportunity to rethink as well how we wanted the product to work. So began to really dig into understanding our stakeholders. again, sort of like the question you asked about clinicians, what makes them tick? How can we create value for our end-users? So at Huddle Up, we were a little bit unique in that.

We had our own set of clinicians, so we had therapists that we were working with, mental health counselors, speech therapists, occupational therapists, and school psychologists. And then we also had families and patients or students, so primarily kids and adolescents that we were working with. And then we also had the school setting we were working within.

So multiple stakeholders that we really had to consider and figure out how can we engage with them through the care process as well as differentiate ourselves in the market. And before we go any further, could you actually just for the listeners, share a little bit about Huddle Up's operating model? Yeah, absolutely. So Huddle Up started as a pediatric teletherapy company. We were focused on selling primarily into school districts and offering teletherapy services to support IEP students.

So individualized education plans. So think of that as your highest need, highest acuity kids who are required to get these services by our government. And so we would step in and help the school provide those required services. Over time, Huddle Up evolved and scaled. IEP was still at the core of our business, but then we also began to offer our services to other populations within a school, and then also started to work outside of the school with payers and extend into other communities.

And so how did the value proposition of what Huddle Up was bringing to schools and communities evolve over your time as chief product officer? Yeah, I think it's very similar to a lot of other teletherapy companies, right? Where initially it was access. It was all about how do you get access to these critical services, which was the core of teletherapy, and that was really successful at the beginning.

But as we moved through COVID and as time evolved, we realized that access wasn't enough, and so we needed to drive those clinical outcomes forward, as well as create differentiation in the market. And to do that, we wanted to light up the circle around the student. So how do we engage with their parents or caregivers? It could be grandparents, it could be foster parents. How do we engage with the school, right?

And make sure that the school nurse or teachers who were engaging with the student regularly were involved in the care as well. As well as with our own clinicians. Our clinicians were saying to us, Hey, a child or an adolescent is very different than an adult and that there's so many people around them who are helping with their growth and development. So how can we light up that circle around them?

And that's where we felt like technology could really do so by pulling in those stakeholders, creating a care ecosystem, and making sure that we were enabling their caregivers or support system to enable them to continue in their growth and development. So as you were expanding the focus from the schools to that broader care ecosystem, what were some of the new challenges? How did you have to reconfigure the company or the product team? Or the product? Yeah, absolutely.

So I think you moving away from just being a pure teletherapy company where teletherapy was still at the core of what we were doing, right? So of course we were still providing those sessions and making sure that our IEP students were getting the care they needed and any other students we were touching were getting that care they needed. But, we wanted to solve more than just the isolated problem of providing services.

And so we started to think through how do we engage with this broader ecosystem, which posed quite a few challenges. It also was a shift for the organization for Huddle Up, right. And so I think Huddle Up started really as a teletherapy, a services company.

And shifting to being more tech-focused, where tech was really playing a pivotal role in how we were differentiating ourselves in the market was a shift for the culture of the company in addition to o ur clients and customers, and so there were multiple challenges that we faced. One was figuring out how do we engage with parents, how do we engage with teachers and staff at a school? Realizing that not every parent or a caretaker has a lot of time or capacity.

And so we had to be really thoughtful and that required coordination and tight coordination with our CS counterparts and our commercial counterparts in the organization as well as marketing to make sure that we were coordinating with the school to figure out how we could engage regularly with parents, both through the product and through the schools' different mechanisms.

And then same kind of challenges with the school as well of determining how can we get engaged with key players at a school outside of just the services. And how dramatically did the underlying technology platform have to change to support that ecosystem approach?

We completely rebuilt our platform. We re-architected. So we moved from a monolith to microservices. We built a completely new front end UI/UX and we really redesigned the entire experience. We also had to rethink our clinician's experience, right?

Because now they were going to have parents engaging potentially in the care, although the parents weren't at school when the sessions were taking place generally, but our clinicians still wanted to be in the loop and be able to enable parents, right to engage in care if they wanted to. And so we had to rethink how can we better support our clinicians to make them more efficient, more effective, and keep our providers' satisfaction high as we navigated this shift.

So how did the model change when you did bring the parents more actively into the conversation? Yeah, I think it was a bit of a mindset shift for our clinicians. I think some clinicians were really excited. They wanted to be able to offer content and exercises for parents to better understand diagnosis. They also felt like the visibility was important. Other clinicians were nervous that it was going to create more work for them, right?

If they were getting questions from parents or visibility, was that going to create more work for them and they're already so busy. So really being transparent about the expectations and how we were going to build tools and evolve the technology as we saw parent engagement and how they're engaging with our platform to enable our clinicians to easily engage with parents and bring them into the care fold.

And so things we thought about and what we were considering was, for example, how do you use AI to suggest recommendations or content to parents based on what's happening in a session. One example that comes to mind is we often were hearing from schools and from families that they just didn't understand the diagnosis of their child. So if their child was diagnosed with a specific condition they often didn't really understand it.

And so something as simple as just providing them with an article or video or content was really powerful. And I know it sounds quite simple, but it made it easier for parents to consume and understand what was happening with their child. So we'll come back to talking about AI in a little, in a little bit.

But before we do that you were eventually promoted and took the sort of chief product and technology officer role. So stepping into the technology leadership side, having come from the commercialization and then product background, what was that transition like for you? Yeah, it felt a little nerve wracking, of course, the time. But I'd been collaborating incredibly closely with my technical counterparts for years at that point. It was exciting also.

So I think the big shift for me was moving from just being product focused, thinking about our product strategy and managing our product and design teams to really thinking about how do we orchestrate alignment across the entire technical org including product, right? And that meant building a truly cross-functional team and making sure that we were working as a unified organization.

To do that, I had to think about, how do I look at these multiple disciplines, create OKRs, a tie to the broader business goals, and really start to manage this as one? I think I gained a much deeper appreciation working and managing the technical side of the organization for context and I realized that our engineering team was quite siloed, product has the benefit of working across the organization. Really making sure that we were working cross-functionally, so we had a lot of visibility.

I, I realized quickly that engineering didn't always have that visibility, and I think that's quite common in a lot of organizations. So I needed to figure out how do I break down those silos? And I realized that context sharing the why was really important for my technical team members.

And so I quickly started to implement sessions before we developed a feature or within my, cross-functional team meetings explaining why we were building something in the context in the business, the context across the market, as well as sharing what are the key metrics or KPIs that we're tracking when we were rolling out a feature. And I think that really changed the mindset for us of our technical organization.

Our technical team started to see how their work was tying to key clinical outcomes or metrics, how it was impacting our clinicians. They could also see how it was impacting our end users, like our patients and families, and it really was a game changer for morale and velocity.

So let's do a little more, a little more block and tackle and and talk about product roadmaps. Uh, how did you, I both at MediKeeper and at Huddle Up think about optimizing that roadmap to both sort of the engineering realities, the commercial realities and the clinical realities. Maybe some tips and tricks for the, uh, listeners. Yeah, always a fun balancing act. It's always challenging no matter the organization you're a part of.

Everyone has competing needs and wants, and you're never going to be able to satisfy everyone's wants. But I think the key is understanding, zooming out and understanding what are the broader business goals. So I always like to walk in and say, okay, what is the business trying to achieve? What are the OKRs or KPIs that we are trying to achieve as an organization? And then building a roadmap that rolls into that.

So I have found a lot of success with working with the C-Suite on using a weighted priority matrix where we we look at what are the key metrics that are critical for the business, but also for product. And so let's just take an example of, uh, most organizations are shifting away from grow, grow, grow at all costs, and instead are shifting towards profitability.

How do we actually start to shift our thinking to still growing, but being reasonable with those growth metrics while becoming profitable? So for us, for example, and if nearing my end of my time at Huddle Up, we were really thinking about NRR. We were thinking at gross margins. So really starting to filter through our roadmap of what are going to drive those metrics. And again, getting alignment at the C-suite is critical.

And then going through that exercise regularly as we're looking at our roadmap to determine what is the priority and everyone understands the why. I always say a roadmap is a living, breathing document. It is not something that you build at the beginning of the year and you revisit at the end of the year. Priorities very well may shift. Something happens in the market and acquisition.

There's so many different factors that happen, right, that can really impact your roadmap, and so making sure that your roadmap rolls up into those broader business goals, but also is accessible for the entire organization is key. I've also found creating different versions of the road roadmap is important as well, you know, for a board level, the roadmap is going to be a bit broader, more zoomed out. But for an engineering and product team, you're gonna be much more detail-oriented.

I always say as well, you wanna leave room for tech debt. There's unfortunately always technical debt, but you have to address. And so making sure that engineering is taken care of, that we have technical initiatives included on the roadmap, and that we show the why and the impact of those to the broader organization because most of the time the organization isn't as excited by those technical initiatives.

And they're typically more excited by features or cool things that they've been waiting for. But it's really a balancing act. So that roadmap flexibility is really important, but it's also culturally a challenge for a lot of organizations where, people may see that as being you made a commitment, so you're changing the commitment. How do you balance that?

How do you, How do you go and, and, and get your leadership team and get everyone else on board with the fact that, you know, like you're never gonna know less than you know right now and you just learn something so you've gotta make a change. Yeah, absolutely. I think again, transparency is key. I think also sharing the risks of not making the shift is important and the trade-offs, you're always going to have trade-offs. That's part of the development process, right?

Whether you're developing a single feature, there's going to be trade-offs. So then that feature, or you're looking at the entire roadmap. And I think really sharing again context. The why, the metrics that you're driving towards is key if you're going to shift gears. And when I say flexibility, I'm not saying you should be shifting your roadmap every week or every month but if something shifts and you need to make a change. You need to have the flexibility to do so.

And I think some of that is also just educating the leaders in the organization as to the why, holding office hours as well. I used to hold office hours where anyone could come and ask me questions about either the roadmap or the product and tech organization. I actually would get people who would come in and ask questions about why a feature wasn't wasn't happening or why that something was delayed. And it was really helpful to just have a conversation as two humans.

Let's talk about product-led growth. What does that look like in, regulated, service-heavy environment like digital health where the MVPs are pretty big. Yeah, absolutely. So I think the first thing is, unlike in some other industries product-led growth, it doesn't mean growth without guardrails when you're working within digital health or healthcare, right? I think that's critical. But I think it's also thinking about letting the product prove value within the real-world use case.

So unlike in some other industries where we hear about product-led growth or PLG all the time, you have to be really thoughtful. And when you're creating a product that's impacting clinical outcomes, so making sure that you're designing in a way that fits naturally into clinical workflows feels intuitive. And quite frankly, if you can create a delightful experience that's healthcare-oriented, you're likely to have organic growth start to happen.

And I mean that from both a clinician perspective, but also a patient perspective. I think unfortunately, the norm when we go into our traditional healthcare settings is that we have these experiences in healthcare that really rub us the wrong way. We have a negative connotation around healthcare. So if you can create a digital experience that's a delight to use, it's easy to use, it's made your life easier, then you're likely to have people talk about and start to have that organic growth.

So the product itself really becomes the driver of trust, engagement, and ultimately scale. And when you're pursuing something like that, how do you bring in, again, those, this is gonna be a theme, but those cross-functional voices, the clinicians, the customer success team, sales teams, into that process without essentially creating chaos. I always tell my product team members that cross-functional collaboration is key and core to our success, right?

Building that trust, making sure voices are heard, but that doesn't mean saying yes to everything either. And so really bringing in the cross-functional team members in a structured, intentional way, I have found to be the key. So making sure that you have an agenda and that you send out ahead of time explaining the goals of the meeting involving cross-functional team members in the discovery phase so early and often so they feel like they're heard, they're participating as you're building.

And then I like to also use clinicians as we're building to really help us pressure test, right, to make sure that we're clinically sound as we're building and designing. We also often involve cross-functional team members in testing and validation processes. So as we're nearing the end to make sure that whatever we've built is going to work in the real world.

But again, I think that the key here is that kind of structured intentional thinking so that when you're involving those team members, they know why you're involving them and what you're trying to gain out of those interactions because one thing that I always like to remind people is everyone's busy in an organization, especially in early stage and growth stage companies, everyone is busy and has competing priorities. It's not just product. It's not just engineering teams.

And so making sure that it feels like you're respecting people's times and voices is really important. So as someone who took over a technology team coming from the product side, what did that teach you about that you, what did that teach you that you think product leaders and other organizations should know? Yeah, I think again, it's making sure that you can create the synergy and alignment between product and engineering.

We always know that as being a product leader or product team member, that you need to work well with your technical counterparts, right? But really understanding how to work well with engineering teams or technical teams is key.

And so what I would say is again, sharing context, creating shared goals, making data-driven decisions is really key to finding success as you're moving from just managing product to managing product and engineering teams and making sure you're sharing success across the organization as well as understanding mistakes or fAIlures. So as a team, as a unified team, you can all grow and reset.

And for people who might be going the other way, I mean, taking on more of a product responsibility from a background that might be more on the engineering side, o r on the clinical side, what should they know? How do they need to reset? So I think again, that cross-functional collaboration is really, really important, especially if you're coming from an engineering background or even a clinical background.

I think in products, Uh, team members, it's in our DNA I don't wanna work across the organization. But I think sometimes that's a challenge for those with other types of training. And so making sure that you can create transparency and build trust is really important. I think the other piece is making sure that you feel comfortable learning how to say no. Might be a little easier for sometimes a technical team member than it is for a clinical team member.

But it's really important to be thoughtful around w hat you're committing to and making sure you're listening to feedback, but again, you're not just taking it at face value, so listening, but validating. Is saying no t he hardest part of the job? I think it's quite hard, yes. I think, uh, you wanna be gentle in those no's because you don't want to hurt morale and trust across the organization.

You want your team members to understand, again, that why I keep saying that, but it's really important that when that you're not able to commit to something that another team might want or need, you can understand, you can share with them the why. Because this is the trade off. We see that across the organization this is going to have a bigger impact. And here's the data to show that.

I really find that when you make data-driven decisions, it can be a combination of qualitative and quantitative data. People will start to understand. You just can't say no and not share the why.

So I promised everyone we'd get back to talking about AI. So here we are. You mentioned building some AI support into clinician guidance, uh, especially as you were bringing family members more into the mix. Of course when clinicians hear AI, a lot of them think about risk and, maybe that's job risk or maybe it's legal and liability risk. So how do you approach integrating AI into the Huddle Up platform in particular? So I think for us, the key was augmenting not replacing.

We needed to make sure that we were making it clear to our clinicians and just across the organization, because AI was scary for a lot of folks in our organization. It wasn't just the clinicians that we were approaching it as, how can we make our clinicians or our team members almost superhuman? Uh, and how can we augment their workflows and not replace?

And so I think being able to share that we're trying to free up time so that clinicians can do what they do best, which is care for patients, support patients and lessen the burden of doing administrative work. And doing the same for our internal team members really helped us create that trust. And again, it's being transparent around what you are trying to do. Clinicians in general, I have found, can be wary of technology.

So then when you introduce AI on top of that, which is just everywhere, everyone is hearing about it and reading about it, it can be tricky about to build that trust. So we involved clinical groups early and often, and were very honest about what we were trying to achieve and what we were not trying to do and listened to their pain points and what problems they wanted us to solve. And so we found that they helped become champions of the work. So what kind of AI tools did you implement?

Low hanging fruit for us was how can we first personalize our experience? So one way to do that was, as I mentioned briefly content became a core piece of our offering where we were offering families and patients access to a resource library that was highly personalized to them. So we thought that was an easy way to start to dip our toes into AI. Right? It didn't involve clinicians at all.

Although we were looking at clinical data for some of the personalizations, but it was not a scary, intimidating way to start to leverage AI. We then turned to get more predictive with it and start to begin to understand capacity and caseload, which was really core to our business model. So starting to understand when should we be discharging patients and anticipating when patients should be hitting goals.

So that does start to touch more on our clinicians because we were finding that clinicians were hanging on to patients should just far too long than was clinically sound. And so we needed to start to anticipate what were our hiring needs and how do we better support our clinicians to say, Hey, this patient's been stagnant for a month it might be time to consider discharge. And so really enabling first our clinical managers and then starting to introduce that into the product.

Those were kind of the core areas that we were using it. The other area was around automating documentation, which I think is becoming much more common, right? In terms of how can you automate these daily workflows? And we were exploring quite a bit there in terms of how can you automate scheduling and anything that they were repetitive tasks that was just taking time away from seeing patients.

So one of, one of the things that sort of differentiates AI features from more traditional product feature development is that t he answers can be a little bit fuzzy. You don't, you get a close match, you get a confidence interval, you get a, you know, some texts that may not be quite the same each time through.

So how do you adapt some of the product design and planning tools that, you know, we've all have had in our tool set for a long time, to work within that sort of greater degree of uncertainty? Yeah, I mean, I think the one thing is we when we were starting to explore AI, we had to be clear across the organization that timelines may be a little bit more fuzzy for us as well to your point, because we wanted to make sure that we are thoughtful in our rollout.

Not that we aren't thoughtful when we're doing more traditional rollout, leveraging AI, but you know, really taking smaller audiences, doing the proper beta testing and making sure that we didn't have bias as well in our. Results. And so I think you've really gotta consider timelines. You've gotta consider your data set and you need to make sure you have the right team members on board who are confident as well in helping support these AI initiatives.

That meant for us, we had to start thinking more about what our team looked like and was composed of, especially on the data and technical side of the organization. Yeah, so what did you need to find on the data side and on the technical side? What do those profiles look like? Yeah, I mean for us we needed someone with a stronger data science background. We had a data architect who was fantastic, but we needed someone who was comfortable working in a clinical environment we felt was important.

And had a stronger just data science background. On the engineering side as well um, we had some hesitancy from some engineers initially around AI. We had others who were incredibly excited to leverage AI, right? And already were using it to help them code. So it just sort of varied in personality type, but really again, having someone who could be a strong counterpart to those on the data team. And actually that's, that's interesting. So you had, engineers who were, potentially hesitant.

Why were they hesitating? I think that they felt nervous about the implications of AI in the product more than them using it. again, sort of what you were talking about, the risk of what if something goes wrong. I think that was part of the initial fear from some of our engineers, which was interesting 'cause I would've thought it would come more from the product side of things. But I think that was part of it.

I also think just some hadn't used AI and so, right, if they had never leveraged AI in past roles, it was new for them as well and they felt uncomfortable with a new technology or what was new to them. Yeah. And with your other stakeholders, how did you think about the sort of the AI hype cycle? I've certainly been in board meetings where there's been a lot of demand for AI.

Yeah, I've had some really interesting conversations recently about AI as I've been working with some other organizations as well, where it feels like everyone wants to implement AI right now, thinks they can shrink their teams and replace them, and I think it is a bit of a hype cycle, quite frankly, in that we had to really ground our team, and I think the way we did it was starting small.

So saying, we know we have such great potential to leverage AI ML, but we a) need more data for some of it. But also we wanna start small and take smaller risks and kind of tiptoe in before we invest heavily in AI. Make sure we also feel confident with our strategy, can bring in the right team members and have proper investment. From that perspective, again, it was already a culture shift when we shifted from just being a teletherapy company to being tech enabled.

And so this was another shift from a culture perspective. And as you mentioned earlier, I think people just get nervous that AI is going to create job insecurity and replace them. So anything on the AI front that you're really excited about now? Anything you've seen in the last couple of months that you know will definitely play a role for you in your, in your next, big project. I mean, I think just the ability to augment humans is incredibly exciting.

So I think when I'm thinking about it from a digital health perspective, clinicians becoming superhuman, being able to surface the right data to them at the right time, insights that they would never have had when they're in with a patient I think is really compelling. Again, I think it can be transformational in terms of just driving better care outcomes, um, and creating these highly personalized experiences. I wouldn't say there's one specific technology that I'm really excited about.

I'm a strong believer in that this is gonna augment humans and not fully replace our clinicians. And that it's going to be powerful for patients as well, because I'm hoping that they'll have better interactions with clinicians because of AI.

So moving on to my other favorite topic, which is compliance. Uh, You've spent your career so far, in, in healthcare, that's highly regulated. It's HIPAA, it's compliance driven. I imagine with, with school districts and children, you have another whole layer of obligations on top of that. Um, so how did you bring, the really boring stuff that is nonetheless business critical, into the product roadmap and into the technology roadmap?

Yeah, I mean, I think compliance is forward to healthcare or digital health, right? Definitely not the sexy, exciting part of the job, but critical. Of course you don't want to have be in the news because you weren't compliant. Critical to educate the organization as well about the importance of compliance and why we needed to dedicate part of our roadmap to ensuring that we were compliant.

One core piece of that was embedding those regulatory or compliance considerations into the product development process from the beginning. So making sure that our team members, legal team members, compliance team member, team members, quite frankly, our security and IT team members as well, were involved early and often to ensure that we were embedding those pieces into the design process from the very beginning, and it wasn't an afterthought.

And so while sometimes that can create challenges because it means you have to make compromises where you may not want to. It's better than having to roll back a feature and redo it. And so we really treated those requirements as a core part of our product development process. And just looped in the key stakeholders from the beginning and until the end, so they would've final sign off as well.

So if you knew then what you know now, is there anything that you would further prioritize, even if it came at the cost of some feature momentum? Yeah, I mean, I think for us HIPAA compliance is pretty straightforward. If you work in healthcare, you know how to be HIPAA compliant. But I think for us, some of it was around, I would say working within school districts was a little bit tricky. There was some variability across regulations across states, which made it tricky.

We, we worked nationwide and so that was a little bit harder at times. And I wish that we were more aware of some of those changing requirements earlier, um, and had a better way to track it. AI, I think actually will be a great tool to leverage here as well to help you from a compliance perspective.

I think the other thing is making sure the org understands and most do, but the investment in cyber and making sure that you're really securing and minimizing any sort of cybersecurity risk in addition to just the healthcare regulatory risk.

Okay, we're gonna move on to the lightning round. Quick questions. One sentence, two sentence answers, max. One product, tool or practice that you can't live without. One product tool's Maze that I can't live without. So because I've been in budget constrained environments, experimentation is key early and often, and I found Maze to be a really effective, relatively inexpensive way to get that user feedback and validation. Biggest misconception today about AI and health tech.

AI is going to replace all clinicians. Uh, I don't think that is going to happen. As I mentioned earlier, AI is going to augment. I don't think most of our clinicians will be replaced by AI. Underrated skill for product leaders. I think really building trust with cross-functional partners. It's the foundation for real collaboration and execution. And I think, uh, some junior product team members might underestimate the importance of that.