Hard Problems, Smart Solutions: The Newfire Podcast

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.