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.
Finish this sentence: g reat product strategy starts with...
...deep understanding of your users, their goals, pain points, and their why.
And their lives and finally, what's one thing you wish more
digital health startups understood?
I think that balancing patients and clinician experience while driving
business outcomes is not optional.
So you can't neglect the mission, but you also can't scale
without a sound business model.
So making sure that you're being considered of both is
really key to success in a healthcare startup environment.
So you went through quite a lot of growth at Huddle Up, including a, uh, a series
C round and a private equity investment.
Just tell us a little bit about that evolution and some of the, maybe a
few of the things you wish that you had known going into that process
that would've made it, smoother.
Yeah, I mean, I think when you're fundraising it's always an
interesting moment in a company.
It's exciting, you're excited to get additional investment to fund growth
and scale, but it's also challenging because it can be distracting as
you're managing to raise the funds.
That's almost like a full-time job sometimes, especially
as you're in diligence.
But you still gotta keep going and execute your roadmap and make
sure the business is running.
So I think just understanding the time commitment and balancing
act is really important.
As part of our process, we had a technical diligence, which is quite normal where
they really dug into our product to make sure that it was both sound from
an architecture perspective, but that we were doing what we were actually
saying that we were doing and weren't just having it down on paper, right?
Or showing them in Figma.
And so making sure that you have key and core documentation
ahead of time is, is key.
I think again, AI can likely help you there.
It's never been easier than now to document but just making sure that you
don't get behind on the documentation.
You don't underestimate the time it's going to take to fundraise.
So of course, you know the funny story about that fundraising is that Newfire
Advisory actually had to recuse ourselves from doing the due diligence on DotCom
Therapy Huddle Up, uh, because we were working with the company on engineering.
That is correct.
That is absolutely correct.
I had a funny phone call with Steven around it but it all ended up working out.
We were able to close the round and get it done.
So Alexis, thank you so much for joining us.
This was a great conversation.
Before we close out what's one piece of advice you'd offer to product
leaders who are trying to navigate today's digital health landscape?
Yeah, I would say digital health is an interesting moment in that,
again, we're shifting from access to making sure that you're really
able to differentiate yourself in the market and drive core clinical
outcomes while navigating the changing landscape of AI really taking over.
So making sure that you feel comfortable navigating the change,
you're un, you're okay with ambiguity and that you're still going back to those core
product principles of making data-driven decisions, working cross-functionally
and understanding your user and the value that you can create for them
is really key as we navigate some of these kind of uncertain changing times.
Alexis, thank you again for joining us on the podcast today.
It's been a great conversation, and again, I always love being able to tie
things back to very practical insights that hopefully will be very useful for,
other product leaders and other technology leaders who are listening to us.
So thanks so much for joining us.
Thanks all for having me.
It's been a true pleasure.
So to our listeners, I hope today's conversation sparks some new ideas how
you build products that matter, how you stay competitive even when the market
gets a little bit crowded and how to manage some clarity into organizations
that are trying to move quickly.
So thanks for joining us on Hard Problems, Smart Solutions, the Newfire Podcast.
Until next time.